Archives pour la catégorie Procédures & Solutions

SSH comme VPN entre serveurs

Vu le coût des machines virtuelles en ligne, il devient plus accessible d’en avoir plusieurs petites pour différents services plutôt qu’une grosse dédiée proposant de la virtualisation et disposant de multiples IP.

Mais au bout d’un moment, il devient intéressant de faire dialoguer ces serveurs de façon sécurisée.
Comme j’aime me simplifier la vie, j’ai un faible pour les solutions simples qui résolvent plusieurs problèmes.
Donc, une logique VPN permet de protéger toutes sortes de service qui ne doivent plus nécessairement l’être individuellement.

La logique

J’aurais pu implémenter OpenVPN, que j’utilise au boulot, mais mon choix s’est porté sur SSH.
Parce qu’il est tout aussi robuste sinon davantage, qu’il est installé par défaut sous Linux et que je vois son fonctionnement en port-forwarding comme une sécurité granulaire par défaut dans ce cas.

Par défaut, SSH est utilisé pour obtenir une session avec un terminal virtuel à travers un tunnel chiffré. Ce tunnel peut également servir de support de sécurité à des possibilités de transfert de fichier (SCP) voir même au montage d’un système de fichier distant (SSHFS). Il permet également de transférer les requêtes adressées à un port d’un côté du tunnel vers l’autre côté du tunnel, dans un sens ou dans l’autre.

Situation de départ

Nos deux serveurs d’exemple seront:
maitre.domaine.tld qui hébergera
un serveur MariaDB (port 3306)
et un serveur OpenLDAP (port 389).
client.domaine.tld, il doit accéder au SQL et au LDAP du maître.

Génération des clés SSH

Sur le maître, nous allons générer une paire de clés SSH.
Depuis quelques temps, je suis passé de l’algorithme RSA au ECDSA (un peu plus lent, mais semble-t-il un peu plus sûr et moins long.

On choisira un nom spécifique (pas le id_ecdsa proposé par défaut) vpn_ecdsa par exemple
et on ne choisira pas de passphrase (tapez juste <ENTER>).
Dans le cadre de l’automatisation de nos VPNs, cette clé n’a pas de passphrase, il est donc très important que personne d’autre que vous ou le système maître ne puissiez y accéder.

Il faut à présent copier la clé publique sur le serveur client. Pour ce faire, 2 possibilités :

Copie de clé automatique

… ce qui va en fait ajouter la clé publique au fichier /root/.ssh/authorized_keys de l’utilisateur root sur le serveur client. Il faudra évidemment connaître le mot de passe du compte root sur ce serveur.

Copie de clé manuelle

Cette manipulation est également réalisable à la main par un simple copier-coller (rien de chinois donc)Affichez sur le serveur maître, le contenu de la clé publique:

On se rend sur le serveur client, on crée éventuellement le fichier authorized_keys et on y colle la clé affichée par cat ci-dessus :

Sécuriser le client

Si votre système client héberge d’autres utilisateurs il vaut mieux limiter l’usage du port-forwarding à ceux qui en ont besoin et que vous controllez. Je sais qu’il n’est pas recommandé d’utiliser root, mais cela présente aussi des avantages, comme utiliser les ports reconnus (N° de ports inférieurs à 1024).

Usage du port-forwarding

Sur le client, on édite la configuration du serveur ssh

On ajoute :

Restriction de la source des connexions

on fait précéder la clé publique, ajoutée précédemment, de l’instruction de restriction from
le contenu des “” peut être une IP ou un FQDN, si vous avez besoin de plusieurs valeurs, séparez les par une virgule. Il est même possible d’utiliser des  wildcards (? *).

Création du tunnel

Nous retournons sur le serveur maître, créer la connexions SSH.

  • ssh root@client.domaine.tld crée la connexion en tant qu’utilisateur root sur la machine client.domaine.tld
  • -R crée le transfert de port depuis le distant (client) vers l’origine de la connexion (maitre)
  • 389:localhost:389 crée un port local 389 transféré à travers le tunnel vers 389
  • 3306:localhost:3306 idem avec 3306

Cette première connexion est importante, au delà du test, elle va aussi poser la question de l’ajout de l’empreinte du serveur distant, sans cela, l’automatisation future ne sera pas possible.

Une foi cette connexion établie, il est possible, sur le client de se connecter aux 2 ports ci-dessus sur l’adresse locale et d’interroger en fait les services répondant à ces ports sur le serveur maitre.

Maintenir la connexion SSH

Pour faire en sorte que les connexions SSH redémarrent automatiquement en cas de coupure, nous utilisons l’outil autossh. Nous devons donc l’installer, puis la commande devient:

  • -M 0 désactive la fonction de monitoring intégrée (on privilégie les 2 options suivantes).
  • -oServerAliveInterval=60 vérifie l’état de la connexion en envoyant un paquet null toutes les 60 sec. (sans réponse, le serveur considère que la connexion est coupée).
  • -oServerAliveCountMax=3 effectue la vérification de l’opération précédente 3X avant de considérer la perte de connexion.
  • -q active le mode silencieux.
  • -f place la connexion en tâche de fond.
  • -N n’exécute aucune commande sur le serveur distante, très utile dans notre cas puisque seul le port-forwarding nous intéresse.

Les créer automatiquement

Maintenant que nous sommes en mesure de créer cette connexion qui crée le transfert de port distant, et des les maintenir ou les rétablir, il faut les créer automatiquement au démarrage de la machine maître. Le plus simple est sans doute d’ajouter notre commande autossh dans le fichier /etc/rc.local.

ATTENTION: il est très important que la dernière ligne de /etc/rc.local soit exit 0, il faut donc ajouter notre ligne de commande autossh avant cette ligne !

Voilà, a présent, nous avons un tunnel persistant créé automatiquement et permettant à la machine cliente d’accéder aux service SQL et LDAP.

Mozilla Persona – Votre Identification Web Libre

Développée par la fondation Mozilla, la solution Persona est un système d’authentification web visant à remplacer les système privés et centralisés du genre Facebook, Twitter ou Google connect par exemple.

Les problèmes pour l’individu

Pour rappel, c’est la validation “classique” login/motdepasse de votre identité sur ces services qui est ensuite confirmée par ceux-ci aux services tiers que vous tentez d’utiliser. Il y a principalement 2 problèmes pour l’utilisateur de ces services :

  1. Votre identité dépend de leur bon vouloir et de leur existence.

    Si le service disparait ou bloque vos accès, votre identité dans tous les services auxquels vous accédez de la sorte est perdue. Le blocage d’accès ou la perte de contrôle de votre profil Facebook est plus fréquent qu’on ne le pense et vous dépendez d’eux. Le caractère unique de ce genre d’identification est donc un énorme point faible, vous ne pourrez en effet pas facilement recouvrer l’accès à vos données sur des services tiers en utilisant un nouveau compte facebook ou le remplacer par votre compte twitter par exemple.

  2. Vous êtes pistés en permanence et votre vie privée est mise à mal.

    En effet, a chaque fois que vous vous connecté à l’aide d’un de ces services centraux à un service tier, le service central choisi (facebook, twitter, google) consigne votre accès à ce service et peut suivre certains usages que vous en faites.

Les problèmes pour les services

Ce sont, grosso modo, le pendant des problèmes utilisateurs qui sont développez ici

  1. Vous donnez des informations à de potentiels concurrents.

    C’est en fait le service d’authentification qui connait le mieux votre client ou partenaire, il est au courant de ces faits et gestes et vous alimentez en fait ce concurrent potentiel en information de connexion et d’utilisation de votre service.

  2. Votre service client n’est pas réellement entre vos mains.

    Vous dépendez totalement du bon vouloir d’un service d’authentification pour fournir à vos clients le profil personnel dans lequel il agit, si pour une raison ou une autre dépendante de vos service, le tiers d’authentification vous fait faux bond, vos clients ne pourrons plus utiliser vos services et vous ne pourrez aisément les ré-identifier.

La solution proposée

Le service auquel vous souhaitez vous connecter à besoin d’un nom d’utilisateur et de valider votre courriel pour pouvoir interagir avec vous, le plus simple est donc d’utiliser cette adresse courriel comme nom d’utilisateur.

Persona propose de vous identifiez à l’aide de votre adresse courriel en utilisant le navigateur comme intermédiaire.

Dès lors,

  • vous pouvez créer un compte Persona, protégé par un mot de passe unique.
  • y associer une ou plusieurs adresses courriel (elles seront validé régulièrement)
  • lorsque vous vous inscrirez ou reconnecterez au service, vous choisirez l’une des adresses courriels disponibles dans le compte Persona.
  • celui-ci pourra alors certifier votre droit à vous présenter comme propriétaire de cette adresse.
  • et le service pourra vous inscrire ou vous connecter sans devoir à nouveau valider cette adresse ou vous demander un autre mot de passe.

Votre vie privée est totalement protégée par le fait que votre navigateur devient un intermédiaire anonyme (sorte de firewall) entre votre fournisseur d’adresse courriel et le service que vous souhaitez utiliser. Le fournisseur d’adresse n’est jamais informé du service auquel vous souhaitez vous connecter, ni même le service Persona puisqu’il n’est pas centralisé mais dépend du navigateur que vous utilisez.

Créez votre compte !

Actuellement persona.org est le seul service en ligne, mais il est conçu et disponible pour être installé sur d’autres plateforme. C’est ce qui a déjà convaincu toutes les grandes plateforme CMS d’intégrer un mécanisme d’authentification Persona. Il n’y a donc aucun risque de se retrouver isolé.

Exemples d’implémentation

Plugin WordPress :
je l’utilise pour m’authentifier mais aussi pour vous permettre de vous authentifier avant de poster vos commentaires, bienvenue ;-)

TroveBox Gallerie d’images

Voost (Evènements)

Tiny Tiny RSS – Remplacer Google Reader

Tutoriel rédigé en suivant ces conventions

Il présuppose une série de connaissances de l’environnement Linux, la configuration d’un serveur Apache ou du gestionnaire de base de donnée MySQL.

Prérequis

Installation

Pour ma part, je préfère installer le gestionnaire de flux rss dans un répertoire indépendant d’un autre site web existant mais le présenter comme sous-répertoire dans l’URL soit :

Chemin d’installation sur le serveur: /var/www/reader (site web principal dans: /var/www/site)

URL de gestion: https://votrehote.votredomaine.tld/reader

URL du fil publique: http://votrehote.votredomaine.tld/reader

Récupération et mise en place de la dernière version

Nous créerons un répertoire downloads pour y placer les archives récupérées depuis Internet.

Nous nous y rendons ensuite pour télécharger la dernière archive (1.8 au moment de cette publication).

Nous décompressons l’archive puis déplaçons le répertoire ainsi obtenu à sa place définitive.

Enfin, nous attribuons les droits d’utilisation pour le serveur apache sur les fichiers.

Configuration de la base de donnée

Nous mettons à présent en place la structure de base de la base de donnée:

Paramétrage de Tiny Tiny RSS

Nous créons un fichier de configuration à partir de l’exemple fournis.

Nous allons modifier les valeurs de définition suivantes :

Interface de gestion

Comme signalé au début de cet article, Nous allons fournir l’interface de gestion au travers d’un site en protocole HTTPS et le fil des articles republiés en HTTP.

Pour ce faire, nous ajoutons 2 instructions différentes dans les fichiers de définition des sites servis par Apache.

Un alias dans le fichier du site HTTPS:

Il reste à recharger les paramètres d’Apache

Récupération du chemin publique

Vous devez vous rendre dans l’interface de gestion à présent disponible : https://votrehote.votredomaine.tld/reader

Puis en haut à droite de votre écran, vous utilisez le bouton “Actions …” et sélectionnez “Configuration…”

Sélectionnez le second onglet “Flux”, puis l’avant-dernière ligne de menu “Articles publiés et partagés / Flux générés”

Cliquez sur le bouton “Affichez l’URL”, une fenêtre apparait qui permet de copier la clé dont nous aurons besoin, c’est évidemment la partie qui suit key= dans l’URL affichée, nous le nommerons dans la suite :

****LaCléQueNousRécupéreronsDansLinterfaceDeGestion****

Publication de ce chemin

On va utiliser une RewriteRule dans le fichier du site HTTP.

Mise à jour des flux

Nous devons à présent mettre en place l’automatisation de la récupération des articles publiés dans les flux rss auxquels nous nous abonnerons. Pour ce faire, le mieux est d’utiliser la solution start-stop-daemon.

Nous pouvons éditer le fichier /etc/rc.local et y ajouter la ligne suivante:

A vous …

…de parcourir les menus et de découvrir les fonctions et paramètres vous correspondants.

Il existe une appli Androïd qui est vraiment très chouette aussi !

StartSSL – Une autorité de certification raisonnable

Disposer de services sécurisés par un certificat ssl est devenu indispensable dès lors que l’on propose un espace ou la vie privée à sa place et à fortiori si il y a échange de mot de passe.

Il est toujours possible de se générer un certificat auto-signé, cela ne coute rien et chiffre aussi efficacement les données que s’il émanait de Verisign ou Thawte. Cependant le “client” qui ne vous connait pas, ne profite pas d’une relation de confiance auprès d’un tiers qui lui garanti que vous êtes bien qui vous prétendez être (il vous a identifié et à associé la propriété du nom de domaine à votre personne/entreprise).

Heureusement, il n’y a pas que des requins prets à faire payer des sommes folles pour des services totalement dénués de coûts réels et justifiant leurs pratiques commerciales par des assurances et des garanties dont vous n’avez sans doute pas besoin (sauf vous êtes une banques ou un très gros site de vente en ligne).

StartSSL (https://startssl.com) est un partenaire fiable, reconnu nativement par tous les grands navigateurs de dernières générations et qui ne fait payer que les services qui lui coûtent (intervention humaine) ou qui auraient pu être évités (révocations de certificats sans motif valable).

Niveaux de validation

Class 1 : Validation de base (gratuit)

Cela consistera à valider votre adresse courriel et/ou un nom de domaine, c’est toujours le même principe : envoi d’un code sur l’adresse courriel choisie ou d’administration du domaine (au choix hostmaster@ postmaster@)

La validation est valable 30 jours durant lesquels vous pouvez créer des certificats SSL/TLS ou S/MIME gratuits à volonté qui auront une validité d’1 an. Après ces 30 jours vous devrez recommencez le processus de validation pour l’adresse ou le domaine si vous désirez créer de nouveaux certificats.

Attention ce niveau de validation ne permet pas de gérer plusieurs domaines ni de créer des certificats génériques du type *.votredomaine.tld Pour ce faire il faut passer à l’étape payante de la classe 2.

Class 2 : Validation d’identité/d’organisation

59.99$ chaque
Là vous devrez fournir des documents d’identité (Carte d’identité, passeport, permis de conduire) et/ou un mandat de votre entreprise, les statuts, etc pour l’organisation. La validation d’un organisation suppose d’avoir préalablement rélaisé la validation d’identité et implique un second paiement soit dans ce cas 119.98$ au total.

La validation de couriels et domaines pour 30 jours est toujours de mise, mais vous pouvez générer des certificats valides pour 2 ou 3 ans et disposer de domaines multiples dans vos certificats ainsi que de *.votredomaine.tld

D’autres options sont encore possibles, à consulter sur le site, mais ce n’est pas le propos ici.

Créer son compte

S’inscrire

Une fois sur le site, on choisi l’icône en haut à droite de l’écran : login
On arrive sur une page où il sera possible de s’identifier à l’avenir pour gérer sa PKI et surtout, où nous allons créer notre premier compte (il faut un compte pour chaque entreprise, pas pour chaque domaine).
Nous choisissons donc Sign-Up : Sign-up

Nous remplissons le formulaire. Tous les champs doivent être remplis par des informations réelles et personnelles, ces informations seront vérifiées par la suite (par exemple, validation auprès des annuaires téléphonique du lien entre nom, téléphone et adresse).

En cliquant sur “Continue“, nous devons confirmer que les informations ont été remplies de façon conforme et honnête et que nous adhérons aux règles de l’Autorité de Certification (CA).

Un mail est envoyé à l’adresse mentionnée et le code de vérification qu’il contient nous est à présent demandé.

Certificat d’identification privé

Le site vous invite alors à choisir un niveau de sécurité pour ce certificat et cliquer sur “Continuer”
L’écran suivant vous invite à installer ce certificat dans votre navigateur en cliquant sur “Installer”, c’est ce qui vous permettra de vous authentifier à l’avenir sur le site pour pouvoir gérer vos domaines et certificats associés.

Votre navigateur vous informe que l’opération à été menée à bien et la page suivante vous informe qu’il est important de sauvegarder cette clé, pour le cas ou vous devez changer d’ordinateur ou de navigateur par exemple … sans cette clé, plus d’accès à votre compte StartSSL !

Read more

Valider son courriel et son domaine

A présent, vous devez valider une adresse courriel ou un domaine avant de pouvoir générer des certificats respectivement de type S/MIME ou SSL/TLS pour ce faire aller dans l’onglet intitulé “Validations Wizard” et sélectionnez l’objet approprié dans le menu déroulant, la procédure est du même genre que précédemment :

  • introduire courriel ou domaine
  • “suivant”
  • récupérer le code envoyé par mail et l’injecter dans le formulaire

Une fois cette(ces) étape(s) accomplies, on peut créer son premier certificat de domaine

Créer son premier certificat

Pour cela on se rend dans l’onglet “Certificates Wizard” et choisir par exemple “Web Server SSL/TLS Certificate” et cliquez sur “Continue”

A ce stade, soit vous voulez générer une clé privée pour le serveur sur lequel vous souhaitez un certificat et vous produirez également un certificate server request (CSR)

alors, sous linux, réalisez cette Read more

Soit ce n’est pas le cas et nous allons créer ce qu’il faut au travers de l’interface web de StartSSL.
Il faut alors choisir un mot de passe (à introduire 2x pour vérification)
ainsi que la taille de la clé (2048 ou 4096) et l’algorithme de hashage (SHA1 ou 2). Les paramètres proposés par défaut sont bien suffisants mais vous pouvez en changer si vous n’utilisez pas le certificat sur un windows XP ou 2003 car il serait incapable de gérer des valeurs plus élevées que celles par défaut.

Nous arrivons sur une page ou à été généré une clé privé et nous devons copier/coller le contenu du cadre, en ce compris les balises de début “—–BEGIN RSA PRIVATE KEY—–” et de fin “—–END RSA PRIVATE KEY—–”.
Vous devez ensuite ouvrir un éditeur de texte sur le serveur, coller le contenu et sauvegarder le fichier :

En utilisant la commande suivante et en fournissant le mot de passe, nous allons créé une second clé déprotégée

Passer à la page suivante ou vous choisissez le domaine pour lequel vous souhaitez générer le certificat et ensuite indiquer le nom d’hôte relatif à ce domaine. Le certificat sera valide pour hôte.domaine.tld et domaine.tld.

Parfois immédiatement, parfois en différé (via notification par courriel) vous serez informez que le certificat est prêt.
Si c’est immédiat, vous aurez à nouveau une fenêtre pour réaliser un “copier” (comme pour la clé privé) et vous collez le contenu, balises de début et de fin incluses, dans un fichier texte.

Récupérer le root CA et les intermédiaires

Dans le portail de la PKI, le premier onglet à côté des “wizards” est la boîte à outil (Toolbox)
l’un des items est “StartCom CA Certificates”, il mène à une liste de liens permettant de récupérer les éléments de la chaine de certification.

Il est alors possible de copier les adresses de ces certificats et les télécharger par exemple à l’aide de la commande wget exécutée depuis le répertoire de stockage définitif

Dabord le root CA:

Puis l’intermédiaire pour les certificats de classe 1

Ou celui validant les certificats de classe 2

Exemple d’utilisation de ces éléments

configuration web dans Apache

configuration xmpp dans eJabberd