1 serveur SSH – 1 mot de passe trivial – quelle durée de vie ?

honeypotTout le monde le sait : il ne faut jamais exposer un serveur SSH sur le net avec un mot de passe "trivial". Mais dans les faits, en combien de temps un tel serveur est-il exploité par des personnes mal intentionnées ? C'est ce que j'ai essayé de déterminer en mettant en place un petit honeypot ...

Le test  a été réalisé sur un serveur installé spécifiquement pour cette opération (Debian 7) en utilisant une adresse IP publique inexploitée depuis plusieurs années. J'ai modifié mon .bashrc pour recevoir un email lorsqu'une session SSH était active sur ce serveur (utilisateur connecté en "root"). Afin de ne pas prendre de risques, ce serveur était également paramétré pour s'éteindre automatiquement dès qu'une session SSH était active (on ne sait jamais ...). Enfin j'ai tout simplement choisi (pour le compte "root")  le mot de passe le plus utilisé en 2014 : "123456". Difficile de faire moins sécurisé 🙂

Le serveur a été mis en ligne le 27 mars à 17h20. La première connexion SSH détectée  (et réussie) a eu lieu le 28 mars à 5h40. Le serveur a donc été repéré, testé et accédé en 12h et 20mn !

Cette expérience montre que le choix d'un mot de passe complexe est particulièrement important. En matière de connexion SSH, l'usage de clés (et l'interdiction des mots de passe) me semble même être un impératif.

Yubikey : sécurisez vos accès SSH (sous Debian) avec une double authentification [HowTo]

Yubikey

C'est désormais une certitude, les simples mots de passe ne sont plus suffisants pour assurer l'accès à des services critiques. En ce qui me concerne j'utilise, dès que cette option existe, le système de double authentification ("authentification à facteurs multiples"). Le principe est d'associer un mot de passe classique avec un deuxième identifiant à usage unique. Beaucoup utilisent Google Authenticator, ou bien la réception d'un SMS pour obtenir cette information.

Il existe une solution un peu moins connue mais particulièrement intéressante :  Yubikey. Il s'agit d'une petite clé usb (cf. la photo d'illustration de ce billet) particulièrement robuste, légère et ne nécessitant pas de pile. Il suffit de l’insérer dans un port USB et d'appuyer sur le bouton central. La Yubikey se comporte alors comme un clavier (pas besoin de driver spécifique) et génère automatiquement le code à usage unique. Cette clé est vendue sur le net à un tarif abordable (environ 23€ sur Amazon). Certaines sociétés (comme OVH,  par exemple) ont adopté massivement ce dispositif afin de sécuriser l'accès à leur système d'information.

J'utilise une Yubikey depuis quelques mois et je dois reconnaître que cette dernière est particulièrement pratique (pour sécuriser l'accès à mon compte LastPass par exemple). J'ai également commencé à sécuriser l'accès SSH de certains de mes serveurs avec ce dispositif et j'ai décidé de créer ce how-to pour aider ceux qui souhaiteraient faire de même.

Comme d'habitude, ce tuto est basé sur Debian 7, mais il devrait être assez facilement utilisable avec d'autres distributions.

Avertissement important : durant toutes ces opérations ne redémarrez pas le service SSH (ni votre serveur), vous risqueriez de ne plus pouvoir vous connecter ! Une fois la configuration achevée (et le service SSH relancé) conservez votre session SSH ouverte et testez en lançant une nouvelle connexion en parallèle : si les choses tournent mal (connexion impossible) vous conserverez ainsi un accès 🙂

La première opération à réaliser est d'installer la librairie PAM pour Yubico/Ybikey

apt-get install libpam-yubico

Il faut ensuite créer le fichier qui va contenir la liste des Yubikey habilitées à se connecter avec un compte utilisateur donné

mkdir ~/.yubico
vim ~/.yubico/authorized_yubikeys

Pour mémoire le "~" représente le home directory de l'utilisateur actuellement connecté. Si vous êtes connecté en root, le fichier sera donc créé dans "/root/.yubic/authorized_yubikeys"

et d'y placer la liste des Yubikey autorisées à se connecter de la façon suivante

username:token_ID

Le username correspond à votre login Unix (root par exemple) et le token_ID peut être récupéré à cette adresse.

Rendez-vous sur cette page, insérez votre Yubikey sur un port USB, sélectionnez "OTP" (1) dans "source format" et générez une clé en appuyant sur le bouton de votre clé (2).

yubi_screen1

Vous obtiendrez en retour une "input string" composé de 12 caractères et commençant par 6 fois la lettre "c". De la forme "ccccccabcdef". Cette chaine est votre "token_ID". Ajuster le fichier "authorized_yubikeys" avec cette valeur. On obtient donc quelque chose comme "root:ccccccabcdef".

yubi_screen2

Si vous devez donner l'accès à plusieurs Yubikey pour le même login vous pouvez accumuler les Token_ID avec quelque chose du type "root:token_yubikey1:token_yubikey2..."

On édite ensuite le fichier

/etc/pam.d/sshd

Ajoutez la ligne suivante après "@include common-auth"

auth required pam_yubico.so id=16

Si vous préférez devoir générer votre code à usage unique avant d'avoir à mentionner votre mot de passe placez cette ligne avant "@include common-auth" (à vous de décider ce que vous souhaitez faire).

Éditez ensuite le fichier

/etc/ssh/sshd_config

Afin de modifier la directive suivante

ChallengeResponseAuthentication yes

Redémarrez SSH

/etc/init.d/ssh restart

Essayez d'ouvrir une nouvelle session (conservez la session en cours active - on ne sait jamais ...). Vous devriez obtenir ça

yubi_screen3

 

  • Commander une Yubikey sur Amazon : ICI
  • Plus d'information sur Yubikey : ICI

 

 

VPNBook : un VPN gratuit sans inscription !

metal_pipe

Dans pas mal de situations, l'utilisation d'un VPN peut s’avérer utile (navigation à partir d'un hot-spot public par exemple). Il existe de nombreuses offres de VPN sur le marché (payantes ou gratuites), il est également possible de mettre en place son propre serveur VPN ou bien encore d'utiliser d'autres systèmes (l'utilisation de Putty et d'un serveur SSH par exemple).

Pour ceux qui auraient un besoin ponctuel de VPN et qui n'ont pas envie de mettre les mains dans le cambouis j'ai récemment découvert un VPN gratuit (sans limite de bande passante) ne nécessitant aucune inscription : les identifiants (et les adresses des serveurs) sont communiqués directement sur la page d'accueil du site. Ces derniers étant régulièrement modifiés il convient de retourner sur le site pour actualiser ces informations. Simple et efficace !

Concernant les protocoles supportés : PPTP et OpenVPN sont disponibles. Si vous optez pour OpenVPN les fichiers de configuration ".ovpn" sont téléchargeables sur la page d'accueil. Avec OpenVPN il est possible d'utiliser les ports TCP80, UDP53, TCP443, UDP25000, autant dire qu'avec ça vous devriez pouvoir monter un tunnel VPN dans pratiquement toutes les situations !

Les débits (pour un VPN gratuit et sans limite de bande passante) sont plutôt corrects (tests réalisés avec le serveur "us1.vpnbook.com") :

  • PPTP : down -> 6.53Mbs / up -> 2.78Mbs
  • OpenVPN : down -> 3Mbs / up -> 1.67Mbs

Bref, une bonne adresse à conserver ...

 

Sécurisez facilement votre navigation avec Putty et un simple serveur SSH

wifi_zone

Les vacances arrivent et les connexions à partir de hot spot publics vont devenir de plus en plus  fréquentes. Si vous êtes sensibles aux problèmes de sécurité vous redoutez certainement ce mode de connexion. Bien sûr vous pouvez utiliser un VPN (en optant pour  une solution commerciale ou bien en installant votre propre système).

Mais si vous n'avez pas envie de vous prendre la tête il existe une méthode beaucoup plus simple basée sur l'utilisation de Putty (ou Kitty) et d'un simple serveur SSH (aucune configuration spécifique n'est nécessaire sur ce serveur).

Attention : cette technique ne remplace pas totalement un "vrai" VPN car seule la navigation sur le web (à partir de votre navigateur) sera sécurisée. Mais c'est peut être suffisant !

Voici comment procéder :

  • vous devez disposer d'un serveur SSH. Ce dernier peut être hébergé sur un serveur dédié mais aussi sur tous types d'offres de VPS (OVH Classic/Cloud, DigitalOcean, Linode, Amazon AWS ...). Encore une fois aucun paramétrage spécifique n'est nécessaire pour ce serveur. Au passage vous pouvez choisir d'opter pour un serveur hébergé à l’étranger pour utiliser cette méthode afin de contourner les limitations géographiques imposées par certains services (regarder des vidéos réservées exclusivement aux internautes US par exemple ...).
  • Vous devez paramétrer Putty de la manière suivante

putty_proxy1

  • il faut ensuite paramétrer l'utilisation d'un proxy sur votre navigateur de la manière suivante (l'exemple est donné pour Firefox mais vous devriez pourvoir facilement trouver l'équivalent pour votre navigateur favori). En effet une fois lancé/connecté Putty se comporte comme un serveur proxy Socks répondant sur le port 12345 (vous pouvez bien entendu modifier ce numéro de port...)

putty_proxy2putty_proxy3

  • Il ne vous reste plus qu'à lancer la connexion sur votre serveur SSH avec Putty (en utilisant la configuration illustrée ci-dessus) et de naviguer à l'aide de votre navigateur. C'est tout ! Vous pouvez vérifier que votre IP de connexion ( http://ippub.org ) correspond bien à celle de votre serveur. L'intégralité du trafic généré par votre navigation sur le net est désormais chiffrée au travers de la connexion SSH. Attention toutefois, seul le trafic généré par votre navigateur va bénéficier de ce chiffrement.

Crédit photo : Simon A

Debian 6 support étendu (LTS) : quelques opérations s’imposent pour en bénéficier


Logo Debian

Comme vous le savez peut être, le support (mises à jours de sécurité) de Debian 6 (Sqeeze) va prendre fin d'ici quelques jours (le 31/5/2014). Toutefois les équipes de Debian, conscientes que de très nombreux serveurs fonctionnent encore avec cette release ont décidés de mettre en place une organisation spécifique (LTS) afin d'offrir les mises à jours de sécurité pour cette version jusqu'au 6 février 2016.

Si vous gérez encore quelques machines équipées de Debian 6 et que vous souhaitez bénéficier du support étendu, quelques modifications et contrôles vont être nécessaires :

Il faut ajouter les lignes suivantes au fichier "/etc/apt/sources.list" :

deb http://http.debian.net/debian squeeze-lts main contrib non-free
deb-src http://http.debian.net/debian squeeze-lts main contrib non-free

Puis lancer :

apt-get update
apt-get upgrade

Quelques packages ne sont pas concernés par le support LTS. Pour connaître les éventuels paquets non pris en charge , il suffit d'installer "debian-security-support" ( apt-get install debian-security-support ) puis de lancer " check-support-status ".

A signaler également que ce support étendu n'est proposé que pour les architectures i386 et amd64. Pour les autres il faudra migrer vers Debian 7 !

Enfin, si vous souhaitez recevoir les avis de mise à disposition des correctifs par email n'oubliez pas de vous inscrire à la liste de diffusion spécifique : https://lists.debian.org/debian-lts-announce/ .

Plus d'infos :

Mailstore : sauvegarder facilement un compte Gmail

mailstore-logoUtilisateur de Gmail depuis pas mal d'années, j'ai longtemps cherché un moyen de sauvegarder simplement et d'une manière fiable mon compte email. En effet, j'ai pris l'habitude de centraliser l'intégralité de mes adresses sur ce compte et la perte de ces données serait quand même hyper problématique ...

Depuis peu Google permet au travers du service d'export des données "Take Out" d'exporter l'intégralité de son compte Gmail mais cette fonctionnalité ne me donne pas entière satisfaction pour les points suivants :

  • j'ai rencontré quelques erreurs lors de cette opération nécessitant de relancer l'intégralité du process ;
  • l'archive fournie intègre vos mails au format .mbox. Certes c'est standard mais pas très facile à manier ... (on peut bien entendu les réimporter dans Thunderbird par exemple mais pour ma part je ne trouve pas ça très pratique ...) ;
  • à chaque export vous récupérez l'intégralité de votre compte (pas de mode différentiel/incrémentiel). Quand comme moi, vous brassez une bonne quantité de Go c'est pas super pratique ...

Il existe pas mal d'autres solutions disponibles sur le net mais après quelques tests mon choix s'est porté sur MailStore Home, un soft gratuit (Windows uniquement) qui va vous permettre d'exporter le contenu de votre compte Gmail tout en indexant les messages archivés. Il est ainsi très facile de rechercher au sein de votre sauvegarde et d'éventuellement réimporter le contenu de votre compte sur un autre compte Gmail ou vers d'autres solutions de messagerie.

MailStore présente également l'avantage de fonctionner en mode incrémental : afin de ne récupérer que les nouveaux messages apparus dans votre mail depuis la dernière sauvegarde.

Personnellement j'ai choisi de l'utiliser en version "portable" (même s'il est déposé sur le disque dur de mon PC // j'aime pas trop les installations ...) et de le lancer régulièrement. Je dispose donc d'un dossier regroupant l'intégralité de mes mails. Ce dossier est ensuite sauvegardé dans le cadre de mes procédures d'externalisation (je devrais d'ailleurs vous en parler un de ces jours ...).

A savoir également que MailStore propose des solutions (payantes) pour les entreprises qui souhaitent sauvegarder leur serveurs de messagerie.

  • MailStore Home est téléchargeable ICI (ne cherchez pas la version portable c'est au lancement de l'installeur que vous pourrez choisir entre installation et version portable).

Comment obtenir gratuitement un certificat SSL

padlock

Quand on souhaite sécuriser l'accès à son site web en utilisant SSL il est nécessaire de configurer son serveur HTTP (Apache, Nginx ...) pour que ce dernier utilise un certificat adéquat.

Deux  solutions sont alors envisageables :

  •  générer soit même cet élément (on parle alors de certificat "auto signé") avec comme principal inconvénient de voir apparaître à la connexion sur le site, un message d'alerte du navigateur du type "Attention ce certificat n'est pas valide - vous ne devriez pas faire confiance à ce site" . Pas top pour l'image !
  • acheter un certificat émis par une autorité de certification reconnue par les principaux navigateurs. Là les prix sont très variables ...

Il n'existait (à ma connaissance) jusqu'à maintenant qu'une seule autorité de certification qui proposait des certificats gratuits ( CACert  ) mais malheureusement cette dernière n'est pas reconnue par les navigateurs du marché. Il faut donc que l'utilisateur ait déjà importé la "racine" de CACert pour ne pas voir apparaître le message d'avertissement. Autant dire qu'on se retrouve quasiment dans la même situation qu'avec un certificat "auto-signé" ...

J'ai découvert, un peu par hasard, une autorité de certification ( StartSSL ) qui propose gratuitement des certificats reconnus par la plupart des navigateurs du marché. Il s'agit de certificats "simples" (Classe 1 / "Domain Validated" / simple validation de l'URL) mais suffisant pour assurer le cryptage des données entre le client et le serveur sans avoir à subir le fameux message d'avertissement !

start_ssl_illust

Un bon plan à retrouver ICI ...

Petite précision, l'offre "gratuite" semble être réservée aux particuliers : il n'est pas possible de faire mention d'un nom de société lors de la demande de certificat.

[HowTo] Installation et configuration d’OpenVPN sous Debian 7


Photo Post OpenVPN

En bons Geeks nous avons tous besoin, à un moment ou un autre, d'un VPN (pour se connecter en sécurité depuis un hot-spot public, pour accéder à des contenus disponibles qu'à partir de certaines zones géographiques ...). Il existe bien entendu une offre commerciale assez fournie mais partant du principe qu'on est jamais aussi bien servi que par soi même il n'est en fait pas très compliqué de mettre en œuvre sa propre solution (en s'appuyant par exemple sur des offres de VPS low cost ...).


Logo OpenVPN

Il existe aujourd’hui différentes technologies permettant la mise en place d'un tunnel VPN (IPSec, PPTP, L2TP ...). Toutefois ces protocoles nécessitent tous l'ouverture de certains ports et/ou protocoles au niveau des routeurs utilisés pour la connexion à l'Internet. Malheureusement lors de vos déplacements vous ne maîtrisez pas toujours ces aspects ... OpenVPN permet de s’affranchir de ce type de problème. En effet il est capable d'utiliser un port standard (par exemple le TCP:443) qui est habituellement utilisé pour les connexions HTTPS. S'agissant là d'un port largement utilisé il est fort probable que tous les accès Internet que vous rencontrerez laisseront passer ce type de flux !

Ce how-to est destiné à vous fournir les éléments nécessaires à la mise en œuvre de ce type de VPN en toute autonomie (côtés serveur et client).

OpenVPN en quelques concepts :

  • Open VPN nécessite un client spécifique en fonction de votre matériel (téléchargements disponibles ICI )
  • L'authentification est basée sur un système de certificats. Vous devrez générer ces certificats (et les clés associées) sur votre serveur pour chaque client. Ainsi qu'un certificat propre à votre serveur (qui jouera le rôle d'Autorité de Certification). Ces fichiers seront ensuite utilisés sur le client pour s'authentifier
  • La configuration du client est réalisée au travers d'un fichier de conf spécifique

Pré-requis : vous devez disposer d'un serveur Linux fonctionnant sous Linux Debian 7 qui n'utilise pas actuellement le port TCP:443(EDIT : voir le commentaire de Denis pour les possibilités de partage de ce port). Si vous utilisez déjà des règles IPtables vous serez amené à adapter la configuration de votre Firewall ...

Vous verrez c'est un peu long 😉 mais j'ai essayé de détailler chaque opération le plus précisément possible.

C'est parti!

  • Nous allons commencer à installer le serveur OpenVPN
apt-get install openvpn
  • On place au bon endroit les fichiers nécessaires à la génération des clés et certificats (OpenVPN est fourni avec un ensemble d'outils permettant la gestion de ces éléments : Easy RSA)
cp -r /usr/share/doc/openvpn/examples/easy-rsa/2.0/ /etc/openvpn/easy-rsa/
cd /etc/openvpn/easy-rsa/
  • On édite ensuite le fichier "vars" qui intègre les paramètres par défaut pour la génération des clés et certificats (les informations à modifier se situent à la fin de ce fichier)
vim vars

et adaptez les informations en fonction de vos besoins ...

# These are the default values for fields
# which will be placed in the certificate.
# Don't leave any of these fields blank.
export KEY_COUNTRY="FR"
export KEY_PROVINCE="Auvergne"
export KEY_CITY="ClermontFerrand"
export KEY_ORG="BdX"
export KEY_EMAIL="votre@email.com"
...
  • On lance ensuite ces commandes nécessaires à l'initialisation de différents paramètres de crypto et de l'Autorité de Certification
source ./vars
./clean-all
./build-dh
./pkitool --initca
./pkitool --server server
  • Après ces différentes opérations on crée le fichier de configuration du serveur OpenVPN (openvpn.conf)
cd /etc/openvpn/
vim openvpn.conf

Votre fichier devrait ressembler à ça :

8<----------------------------
port 443
proto tcp
dev tun
comp-lzo
persist-key
persist-tun
keepalive 10 20
server 10.8.0.0 255.255.255.0

push "redirect-gateway def1 bypass-dhcp"
push "dhcp-option DNS 8.8.8.8"
push "dhcp-option DNS 8.8.4.4"

ca /etc/openvpn/easy-rsa/keys/ca.crt
cert /etc/openvpn/easy-rsa/keys/server.crt
key /etc/openvpn/easy-rsa/keys/server.key
dh /etc/openvpn/easy-rsa/keys/dh1024.pem

status openvpn-status.log

verb 3
8<----------------------------

  • On lance ensuite le serveur OpenVPN pour tester la conf ...
openvpn openvpn.conf

Vous devriez obtenir quelque chose de ce style :

root@debian:/etc/openvpn# openvpn openvpn.conf
Sun Feb 16 16:33:46 2014 OpenVPN 2.2.1 i486-linux-gnu [SSL] [LZO2] [EPOLL] [PKCS11] [eurephia] [MH] [PF_INET6] [IPv6 payload 20110424-2 (2.2RC2)] built on Jun 19 2013
Sun Feb 16 16:33:46 2014 NOTE: OpenVPN 2.1 requires &#039;--script-security 2&#039; or higher to call user-defined scripts or executables
Sun Feb 16 16:33:46 2014 Diffie-Hellman initialized with 1024 bit key
Sun Feb 16 16:33:46 2014 TLS-Auth MTU parms [ L:1544 D:140 EF:40 EB:0 ET:0 EL:0 ]
Sun Feb 16 16:33:46 2014 Socket Buffers: R=[87380-&gt;131072] S=[16384-&gt;131072]
Sun Feb 16 16:33:46 2014 ROUTE default_gateway=xxx.xxx.xxx.xxx
Sun Feb 16 16:33:46 2014 TUN/TAP device tun0 opened
Sun Feb 16 16:33:46 2014 TUN/TAP TX queue length set to 100
Sun Feb 16 16:33:46 2014 do_ifconfig, tt-&gt;ipv6=0, tt-&gt;did_ifconfig_ipv6_setup=0
Sun Feb 16 16:33:46 2014 /sbin/ifconfig tun0 10.8.0.1 pointopoint 10.8.0.2 mtu 1500
Sun Feb 16 16:33:46 2014 /sbin/route add -net 10.8.0.0 netmask 255.255.255.0 gw 10.8.0.2
Sun Feb 16 16:33:46 2014 Data Channel MTU parms [ L:1544 D:1450 EF:44 EB:135 ET:0 EL:0 AF:3/1 ]
Sun Feb 16 16:33:46 2014 Listening for incoming TCP connection on [undef]
Sun Feb 16 16:33:46 2014 TCPv4_SERVER link local (bound): [undef]
Sun Feb 16 16:33:46 2014 TCPv4_SERVER link remote: [undef]
Sun Feb 16 16:33:46 2014 MULTI: multi_init called, r=256 v=256
Sun Feb 16 16:33:46 2014 IFCONFIG POOL: base=10.8.0.4 size=62, ipv6=0
Sun Feb 16 16:33:46 2014 MULTI: TCP INIT maxclients=1024 maxevents=1028
Sun Feb 16 16:33:46 2014 Initialization Sequence Completed
  • Il est ensuite souhaitable de modifier le paramétrage de votre système afin qu'il autorise le forward des paquets au travers du serveur :
vim /etc/sysctl.conf

On dé-commente (vers la ligne 28) :

net.ipv4.ip_forward=1

et on lance les deux commandes suivantes

sysctl -p
/etc/init.d/networking reload
  • Il est désormais nécessaire de modifier les règles Iptables afin de permettre aux paquets de transiter au travers de votre passerelle VPN (pour vous servir de votre serveur VPN comme d'une passerelle vers d'autres réseaux). Pour ce faire on crée puis on édite un fichier "firewall.rules" que l'on place dans "/etc". Afin de faciliter la mise en œuvre du système j'ai créé un fichier qui laisse entrer tous les flux ( :INPUT ACCEPT dans la section "Filter"). Vous devez bien entendu l'adapter en fonction de vos besoins ...
vim /etc/firewall.rules

Voici le contenu du fichier

*nat
:PREROUTING ACCEPT
:INPUT ACCEPT
:OUTPUT ACCEPT
:POSTROUTING ACCEPT
-A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE
-A POSTROUTING -o eth0 -j MASQUERADE
COMMIT

*filter

:INPUT ACCEPT
:FORWARD DROP
:OUTPUT ACCEPT

-A FORWARD -i eth0 -o tun0 -m state --state RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -i tun0 -o eth0 -j ACCEPT

COMMIT
  • On crée ensuite le fichier d'initialisation du firewall (qui va utiliser les directives données au sein de /etc/firewall.rules)
vim /etc/init.d/firewall

Voici le contenu du fichier

#!/bin/sh
/sbin/iptables-restore /etc/firewall.rules

On donne les droits d’exécution à ce script

chmod 755 /etc/init.d/firewall

On lance une première fois manuellement ce script

/etc/init.d/firewall

Et on indique au système que ce script doit être lancé automatiquement au démarrage du système

update-rc.d firewall defaults
  • et pour finir côté serveur on lance le service "OpenVPN"
service openvpn start
  • On passe ensuite à la génération des certificats et des clés destinés aux clients : remplacez nom_du_user par le nom de l'utilisateur (pas d'espace, pas de caractères spéciaux ...)
cd /etc/openvpn/easy-rsa
source vars
./build-key nom_du_user

Répondez aux questions (pour le CN - Common Name - utilisez la même chaine que pour nom_du_user)

  • A l'issue de cette opération on récupère les fichiers suivants dans le répertoire /etc/openvpn/easy-rsa/keys (ces derniers devront être déposés sur votre client)
Nom du fichier Contenu
nom_du_user.crt Certificat de l'utilisateur
nom_du_user.key Clé privée associée au certificat de l'utilisateur
ca.crt Certificat de l'autorité de certification
  • Il faut ensuite créer le fichier de conf (côté client) qui sera fourni au logiciel OpenVPN pour se connecter. Vous pouvez utiliser n'importe quel éditeur de texte sur votre OS habituel. Voici ce qu'on doit trouver dans ce fichier (extension .conf pour Linux/MacOS ou .ovpn pour les clients Windows et Android). Respectez l'extension c'est important ! Sous Windows le fichier de conf doit être déposé au sein du répertoire "C:\Program Files\OpenVPN\config\". N'oubliez pas de placer également les 3 fichiers cités ci-dessus (.crt/.key) au sein de ce répertoire de configuration de votre client.

Voici le contenu du fichier de configuration du client :

client
dev tun
proto tcp
remote INDIQUEZ_ICI_L_IP_DE_VOTRE_SERVEUR 443
resolv-retry infinite
nobind

ca ca.crt
cert nom_du_user.crt
key nom_du_user.key

persist-key
persist-tun

comp-lzo

verb 3
  • Si vous utilisez Windows voici deux points importants à vérifier (qui vous feront gagner du temps 😉 ) :

  • que votre fichier de configuration porte bien l'extension ".ovpn" (Windows à souvent la bonne idée d’ajouter un .txt derrière ... on se retrouve alors un .ovpn.txt le .txt étant bien entendu masqué ...).

  • que OpnVpn GUI soit bien lancé avec les droits d'administrateur (autrement ça ne fonctionne pas !)

Sous Windows il ne vous reste plus qu'à cliquer-droit sur l'icone OpenVPN GUI dans la barre de tâche et de choisir "connecter" !

Pour les autres plateformes je vous laisse vous reporter à la documentation fournie avec votre client Open VPN en sachant que le fichier de conf ainsi que les certificats et clés sont compatibles sur tous les OS.

Si vous repérez des erreurs, imprécisions, omissions (et oui ça peut arriver ...) n'hésitez pas à me l'indiquer dans les commentaires !

Externalisez sereinement vos sauvegardes avec Duplicity

hard_disk

Si vous administrez des serveurs vous avez certainement déjà réfléchit aux problèmes d'externalisation de vos sauvegardes. Pour ma part j'étais à la recherche depuis pas mal de temps d'une solution permettant de réaliser une externalisation avec comme contrainte principale le fait que les sauvegardes soient stockées d’une manière chiffrée sur le serveur de destination. Bien entendu, il existe le classique Rsync (et ses dérivés), ou bien encore Rdiff-Backup, mais pour moi cette solution n'est pas viable dans tous les cas car si le transfert reste sécurisé il n'en va pas de même pour le stockage !

J'ai récemment découvert une solution qui me semble intéressante : Duplicity. Dans les grandes lignes Duplicity permet de réaliser une sauvegarde distante au travers de pas mal de protocoles : scp, ftp, ssh, rsync, s3 (et compatibles ...). Les sauvegardes peuvent être complètes ou incrémentales (à priori en mode "block" grâce à l'utilisation de librsync). Duplicity prend également en charge le chiffrement des fichiers de sauvegarde soit avec une clé symétrique soit avec un système de clé publique/privée (personnellement j'ai opté pour la première solution).

Malheureusement Duplicity semble être un peu "rude" à l'utilisation. C'est pour cette raison qu'est né le projet "Duplicity Backup". Il s'agit d'un script shell associé à un fichier de conf. L'objectif de ce script est de piloter, simplement et efficacement, le fonctionnement de vos sauvegardes (en faisant appel à Duplicity).

Voici donc un petit how-to résultant de mes premières expériences avec ce script. L'objectif pour moi était d'externaliser la sauvegarde de serveurs fonctionnant sous Linux Debian 6. J'avais initialement prévu de stocker mes sauvegardes sur Amazon S3 mais en effectuant quelques recherches j'ai trouvé un système compatible proposant un tarif plus avantageux : DreamHost proposant le Go de données stockée à 7cts/$ / mois.

C'est parti !

On va partir du principe que vous disposez d'un distrib Debian fonctionnelle (version 6 mais ça devrait également fonctionner avec les versions plus récentes). Python doit être préalablement installé (c'est normalement le cas par défaut).

  • La première chose à faire est d'installer les packages nécessaires au fonctionnement de Duplicity (le package "python-boto" permet l'interaction avec un système de type S3) :
apt-get install librsync1 python python-boto python-dev librsync-dev wget unzip
  • Créez ensuite un répertoire au sein duquel nous allons placer l'installeur de Duplicity, le script ainsi que le fichier de conf. La création de ce répertoire au sein de "/home" est proposée à titre d'exemple. Libre à vous de choisir l'emplacement qui vous convient le mieux !
mkdir /home/duplicity-backup
  • On se place ensuite au sein de ce répertoire :
cd /home/duplicity-backup
  • On télécharge Duplicity à partir du site officiel (à ajuster car la version aura préalablement évoluée lorsque vous lirez ces lignes ...) :
wget http://www.collet-matrat.com/fichiers_download/duplicity-backup/duplicity-0.6.21.tar.gz
  • On décompacte le tout :
tar -xzvf duplicity-0.6.21.tar.gz
  • On lance l'installation :
cd duplicity-0.6.21
python setup.py install

Si vous rencontrez des erreurs vérifiez bien d'avoir installé "librsync-dev" ( apt-get install librsync-dev )

  • Il faut ensuite mettre en place le script et son fichier de conf :
cd ..
wget http://www.collet-matrat.com/fichiers_download/duplicity-backup/duplicity-backup.sh
wget http://www.collet-matrat.com/fichiers_download/duplicity-backup/duplicity-backup.conf
chmod 755 duplicity-backup.sh
  • On édite ensuite le fichier de conf de Duplicity Backup (je ne détaille ici que les principales directives - pour adapter plus finement la configuration à vos besoins reportez vous à la documentation de Duplicity-Backup disponible ICI):
vi duplicity-backup.conf
  • Si vous utilisez un système de stockage AWS S3 ou compatible (comme le stockage de DreamHost par exemple) vous devez renseigner lignes 43 et 44 votre clé d'API et votre clé secrète
  • Ligne 57 maintenez le paramètre par défaut "ENCRYPTION='yes'" si vous souhaitez que vos sauvegardes soient chiffrées
  • Ligne 65 mentionnez votre clé de chiffrement (si vous optez pour un chiffrage "symétrique" / ce que je vous conseille - certes un peu moins sûr mais quand même beaucoup  plus pratique ...)
  • Commentez les lignes 78 et 79 si vous optez pour un chiffrage symétrique
  • Ligne 85 indiquez la racine du backup (utilisez un truc du style 'ROOT="/"' on définira plus tard la liste des répertoires à sauvegarder )
  • Ligne 99 mentionnez la destination de votre backup. Si vous sauvegardez directement sur AWS S3 la syntaxe est déjà prête, vous n'avez qu'à mentionner le nom de votre bucket de destination (avec un nom de répertoire). Si vous sauvegardez vers un système compatible S3 (comme DreamHost par exemple) il va falloir utiliser une syntaxe du type : DEST="s3://objects.dreamhost.com/le_nom_de_votre_bucket/le_repertoire_de_sauvegarde/"
  • Ligne 129 mentionnez le répertoire à sauvegarder (si vous avez plusieurs répertoires à sauvegarder regarder l'exemple entre les lignes 122 et 126
  • Si vous avez des répertoires à exclure ça se passe entre les lignes 134 et 137 (n'oubliez pas de commenter si vous n'en avez pas besoin)
  • La ligne 146 définie (entre autre) la politique de sauvegarde : par défaut faire un full tous les 14 jours (on peux également passer d'autres paramètres à Duplicity par le biais de cette ligne // plus d'infos : ICI)
  • La ligne 161 indique au système combien de full conserver sur le stockage distant (il existe de nombreuses possibilités en matière de conservation des données / reportez vous à la doc !)
  • On définie ligne 183 le répertoire de stockage des log de Duplicity (/var/log/duplicity par exemple)
  • Et enfin, à partir de la ligne 195 le paramétrage d'un éventuel (et optionnel) envoi de mail lors de chaque backup

Une fois ce paramétrage effectué, on peut lancer une première sauvegarde à l'aide de la commande

/home/duplicity-backup/duplicity-backup.sh -c duplicity-backup.conf -b
Pour obtenir la liste des commandes disponibles vous pouvez utiliser

/home/duplicity-backup/duplicity-backup.sh -c duplicity-backup.conf
La restauration peut être réalisée fichier par fichier à l'aide de la commande

/home/duplicity-backup/duplicity-backup.sh -c duplicity-backup.conf --restore-file fichier_à_restaurer [fichier_de_destination]
Il est également possible de restaurer l'intégralité d'une sauvegarde

/home/duplicity-backup/duplicity-backup.sh -c duplicity-backup.conf --restore [répertoire_de_destination]
Et pour finir, deux recommandations importantes :
  • n'oubliez pas de sauvegarder votre clé de chiffrement en lieu sûr !
  • consultez la documentation de Duplicity (ICI) & de Duplicity-Backup (ICI) pour découvrir toute la puissance de cet outil et du script associé !
Photo by : Jeff Kubina

Gérez « AWS Glacier » en ligne de commande

AWS_LOGO_RGB_300px

Pour ceux qui seraient passés à côté, Amazon Glacier est un système de stockage sur le cloud d'Amazon (un peu comme S3) dédié à la conservation "longue durée" de vos données (un système d'archivage en quelque sorte).

Par rapport à S3 le principal avantage de cette solution est le prix. En effet avec un coût de $0,01 par Go et par mois il s'agit certainement là de la solution de stockage la plus économique du marché (10€ / 1To / mois difficile de faire mieux) - A titre de comparaison 1To stocké sur S3 coûte 95$ / mois !

Bon à ce tarif là vous devez vous douter qu'il y a quelques inconvénients. Le plus significatif est certainement le délai de récupération des données. En effet si l'upload d'informations est immédiat, toute opération de récupération de données va nécessiter une attente préalable d'au moins 4 h ! Et ce délai concerne toutes les opérations : même une demande d’inventaire (un "ls" en quelque sorte) du contenu d'un dépôt va demander le même délai (4h) avant d'obtenir le résultat de votre requête ...

Il est donc clair qu'avec une telle contrainte il faut réserver l'usage de Glacier à des seules fins d'archivage ...

A l'inverse de S3 il n’existe pas (pour le moment) d'interface web (fournie par Amazon) permettant de gérer le contenu de ses archives. Plusieurs logiciels dédiés existent toutefois sur le marché. J'ai par exemple testé "FastGlacier" sur une des mes machines Windows (ce soft est gratuit pour un usage non commercial). Toutefois, dans certains cas, il est plus pratique d'utiliser directement une interface en ligne de commande (pour archiver le contenu d'un serveur Linux par exemple). Il existe, pour ce faire, un ensemble de scripts Python totalement fonctionnels et qui permettent d'agir sur vos archives. Il s'agit de "glacier-cmd".

L'installation (et l'utilisation) de "glacier-cmd" ne pose pas vraiment de problème, mais j'ai quand même décidé de faciliter la tâche à ceux (celles) d'entres vous qui ont quelques petites difficultés avec la langue anglaise et/ou démarrer rapidement à partir d'un document de synthèse.

C'est parti ...

Ce how-to est basé sur l'utilisation d'une distribution Debian 6 "out of the box" sans particularité. Bien entendu aucune interface graphique n'est nécessaire (c'est d’ailleurs un peu l'objectif de ce how-to ...)

La première chose à faire est de s'assurer que Python est bien installé sur votre système.

Un petit "python -V" devrait vous retourner la version de Python installée

Dans le doute vous pouvez toujours lancer un "apt-get install python" ça ne peut pas faire de mal !

Il faut ensuite passer à l'installation de "Git" (qui vous permettra de faciliter l'installation de "glacier-cmd")

apt-get install git

On récupére ensuite l'intégralité de glacier-cmd avec une seule ligne de commande :

git clone https://github.com/uskudnik/amazon-glacier-cmd-interface.git

On entre dans le répertoire où ont été récupérées les sources

cd amazon-glacier-cmd-interface/

On installe un module supplémentaire pour Python nécessaire au lancement du script d'installation

apt-get install python-setuptools

Et on lance finalement le script d'installation

python setup.py install

On va ensuite créer un fichier de configuration pour glacier-cmd.

vi /etc/glacier-cmd.conf

Le fichier va ressembler à ça :


[aws]
 access_key=Identifiant de clé d’accès
 secret_key=Clé d’accès secrète

[glacier]
 region=us-east-1
 logfile=~/.glacier-cmd.log
 loglevel=INFO
 output=print

Pour récupérer (ou créer les clés AWS) il faut se connecter ICI

Ce fichier de conf va également vous permettre de sélectionner la zone géographique où seront hébergés vos données (les tarifs varient légèrement en fonction de ce paramètre : toutes les infos sont ICI ).

Les valeurs possibles pour "region" sont donc les suivantes :


us-east-1 pour : US - Virginia
us-west-1 pour : US - N. California
us-west-2 pour : US - Oregon
eu-west-1 pour : EU - Ireland
ap-northeast-1 pour : Asia-Pacific - Tokyo

On peut ensuite passer à l'utilisation de glacier-cmd. Les principales commandes sont les suivantes :

  • Pour créer un dépôt ("vault") de stockage (afin d'y déposer ensuite des archives)
    glacier-cmd mkvault <le_nom_de_votre_dépôt>
    
  • Pour lister les dépôts disponibles :
    glacier-cmd lsvault
  • Pour obtenir le contenu (liste des archives/fichiers) d'un dépôt (attention le résultat de cette commande ne sera disponible qu'après 4h d'attente ...)
    glacier-cmd inventory <le_nom_de_votre_dépôt>
  • Pour uploader une archive (fichier) au sein d'un dépôt :
    glacier-cmd upload <nom_de_votre_dépôt> <nom_du_fichier_a_uploader> --description "la_description_du_fichier"
  • Pour télécharger les archives (fichiers) contenues au sein d'un dépôt  :

    L'opération se déroule en deux temps:

    1) On lance une demande de récupération de l'archive avec la commande suivante :

    glacier-cmd getarchive <nom_de_votre_dépôt> <id_de_l'archive_à_récupérer>

    NB : On récupère l'id de l'archive avec la commande "inventory" (voir ci-dessus)

    2) Après environ 4h d'attente vous pouvez demander le téléchargement de l'archive avec cette commande :

    glacier-cmd download <nom_de_votre_dépôt> <id_de_l'archive_à_récupérer> --outfile <nom_du_fichier>

    Donc pour résumer une récupération "type" s'effectue en 8h : 4h pour obtenir le contenu du dépôt (avec les identifiants d'archives) puis 4h pour obtenir une archive prête à être téléchargée et enfin le temps nécessaire au téléchargement du fichier ! Mieux vaut ne pas être pressé ...

  • Pour obtenir la liste de jobs en cours (inventaire, récupération ...) :
glacier-cmd listjobs nom_de_votre_dépôt

Ce how-to n'a bien entendu pas vocation à être exhaustif. Si vous souhaitez découvrir l'intégralité des fonctionnalités proposées par glacier-cmd, je vous invite à consulter la documentation disponible ICI .

Dans un prochain billet, je vous présenterai une solution permettant d'automatiser le backup d'un serveur Linux vers Glacier ...