Juin 022013
 

Depuis Apache 2.2.12, et le support natif du SNI (Server Name Identification), il est possible d’héberger plusieurs sites web sur un seul serveur tout en utilisant différents certificats SSL. Cela vous permet par exemple de protéger différents sous domaines avec plusieurs certificats SSL de classe 1 (qui peuvent être obtenus gratuitement sur StartSSL…) La plupart des navigateurs supportent aujourd’hui le SNI et la mise en place est très simple grâce à ISPConfig 3. Ce post a donc pour objectif de vous guider à travers les étapes nécessaires.

 Prérequis

Je suppose dans ce post que vous disposez déjà d’un serveur fonctionnel avec ISPConfig 3 installé et correctement configuré. Je vous invite, si cela n’est pas le cas, à lire mes précédents posts sur la mise en place d’un serveur de ce type: Installation ISPConfig 3 Je vous conseille également de lire l’article suivant: Sécuriser ISPConfig avec un certificat SSL, ce post vous permettra de mettre en place un certificat global pour votre configuration apache et notamment votre accès ISPConfig. Il vous permettra en plus de vous familiariser avec StartSSL qui vous permettra d’obtenir gratuitement vos certificats SSL signés.

Création d’un site web avec un certificat SSL non signé

Dans un premier temps, nous allons créer un site web et son certificat associé (non signé) entièrement via ISPConfig. Rendez vous pour cela dans l’onglet Site puis sélectionnez Ajouter un nouveau siteVous pouvez, bien évidemment, choisir un site déjà existant…

ISPConfig 3, création d'un site web

ISPConfig Création Site Web

Entrez les paramètres souhaités, n’oubliez pas de cocher la cas SSL sur la 4ième avant dernière ligne. Cliquez ensuite sur l’onglet SSL vous arrivez sur la page suivante:

Création d'un site ISPConfig, onglet SSL

Création site ISPConfig, onglet SSL

Cette page vous permet de créer entièrement votre certificat SSL via ISPConfig en créant automatiquement la clé privée, la requête CSR et un certificat (non signé.) Rentrez pour cela les paramètres demandés. (Attention, la traduction ISPConfig en français souffre d’une erreur et la première ligne concerne en réalité l’état ou le département)
Il est inutile de remplir les champs SSL key, Requête SSL, Certificat SSL ou encore SSL Bundle. Choisissez Créer le certificat dans le champ Action SSL puis cliquez sur Enregistrer.

Continue reading »

Mai 182013
 

Après plusieurs tutoriels sur l’installation de ISPConfig 3, nous verrons aujourd’hui comment sécuriser une installation ISPConfig avec un certificat signé. (Un second article suivra sous peu pour une procédure permettant d’installer différents certificats signés pour plusieurs sites web gérés par ISPConfig.)

Ce tutoriel est basé sur le très bon tutoriel disponible sur le site de Howtoforge.com dont le lien est disponible ci-dessous (en anglais.)
http://www.howtoforge.com/securing-your-ispconfig-3-installation-with-a-free-class1-ssl-certificate-from-startssl

Rapide introduction

Afin de clarifier un peu les idées et pour comprendre comment fonctionne les différents certificats entre eux, voici un résumé des différents fichiers importants:

  • clé privée (*.key)
    Il s’agit comme son nom l’indique d’une clé privée générée par le serveur et qui ne doit jamais être communiquée à l’extérieur. Élément de base des certificats, elle est utilisée pour vérifier l’authentification du serveur.
  • demande de signature de certificat (*.csr)
    Afin de pouvoir demander à une autorité de certification de générer un certificat public signé, il est nécessaire de fournir un document différent lié à la clé privé tout en permettant l’authentification du  demandeur.
  • certificat (*.crt)
    Le certificat à proprement parler sera celui envoyé au client lors d’une requête sécurisée (https ou autre) Il peut être signé localement (mais n’est en général dans ce cas pas reconnu) ou bien généré (et signé) par une autorité de certification reconnue. (Il est alors correctement accepté par les différents navigateurs ou autres logiciels.)

Création de votre clé privée et du CSR

Avant toute chose, il convient donc de (re)créer une clé privée pour votre serveur et un Certificat Signing Request (CSR) qui vous permettra de demander la création d’un certificat signé (celui qui sera vu par les utilisateurs) sans pour autant divulguer votre clé privé. (Ce qui serait une brèche de sécurité importante.)

Penser à effectuer toutes les opérations suivantes en tant que root pour éviter les problèmes.

La génération d’une clé privée et d’un CSR peut se faire lors de l’installation d’ISPConfig. Dans ce cas, et si vous avez renseigné des paramètres corrects lors de l’installation, vous trouverez ces certificats dans le dossier /usr/local/ispconfig/interface/ssl

Si toutefois, vous n’avez pas renseigné les champs de votre certificat correctement ou si vous souhaitez recréer ceux-ci, il existe une manipulation simple pour cela. (Si vous ne savez pas ce que contiennent vos certificats actuels ET que vous n’utilisez pas ces certificats pour d’autres services, je vous conseille fortement de les recréer de la façon suivante:

Vous aurez à renseigner les champs requis pour votre certificat. (Ils ne sont pas tous obligatoire mais je vous suggère d’être exhaustifs.)

Notez que par cette commande, vous ne recréez pas de fichier .crt Ceci est normal car nous l’obtiendrons par l’autorité de certification.
Vous devez maintenant vous retrouver avec un fichier *.key (votre clé privée) et un fichier *.csr

Le contenu du fichier CSR doit ressembler à ceci:

Demande d’un certificat signé de classe 1

Nous allons maintenant demander à une autorité de certification de signer notre certificat afin qu’il soit reconnu comme valide par les navigateurs internet et autres logiciels de messagerie.
Vous pouvez vous tourner vers diverses autorité de certification mais il en est une qui permet d’obtenir gratuitement un certificat de classe 1. (Un certicat de classe 1 ne sera pas aussi bien considéré qu’un certificat de classe 2 ou + mais c’est totalement suffisant pour nos besoin, et puis c’est gratuit…

StartSSL

C’est StartSSL qui permet la création gratuite de ces certificats. Rendez vous donc sur leur site: http://www.startssl.com/

Il vous faudra tout d’abord créer un compte sur StartSSL et le valider. Enfin, vous devrez également faire valider le domaine sur lequel pour lequel vous souhaiter créer le certificat. Une fois un domaine valider (e.g. domain.com) vous pourrez créez autant de certificat que vous le souhaitez pour autant de sous domaines choisis. (www.domain.com, webmail.domain.com…) Après 30 jours en revanche, vous devrez revalider le domaine pour créer un certificat. (Les certificats déjà créés restent bien entendu valide pour une durée de 1 an, même si vous ne revalidez pas votre domaine.)

Je ne détaillerai pas dans ce post la création de compte et validation de domaine pour ne pas surcharger cet article, l’aide de StartSSL est plutôt bien faite. N’hésitez pas à poser vos question si nécessaire en commentaires si nécessaire.

Création de votre certificat gratuit de Classe 1

Une fois votre domaine validé, il est temps de créer votre certificat.
Dans l’onglet Certificates Wizard  sélectionnez Web Server SSL/TLS Certificate dans le champs Certificate Target

StartSSL Choix du type de certificat

StartSSL Choix du type de certificat

Cliquez sur Continue, vous arrivez sur une page qui ne nous concerne pas car nous disposons déjà d’une clé privée. Cliquez donc sur Skip afin de passer directement à l’étape suivante.

StartSSL, private key

StartSSL, private key

Lors de l’étape suivante, il vous sera demandé de fournir votre CSR. Nous avons dans la première partie de ce post comment l’obtenir. Il vous faut donc recopier intégralement tout le contenu du fichier /usr/local/ispconfig/interface/ssl/ispconfig.csr  en incluant les lignes d’en tête et de fin. (—–BEGIN CERTIFICATE REQUEST—– et —–END CERTIFICATE REQUEST—–)

StartSSL, transmission CSR

StartSSL, transmission CSR

Lors des étape suivantes, vous devrez choisir le domaine pour lequel sera créé le certificat ainsi qu’un sous domaine. (Par exemple: blupgnup.com et serveur.blupgnup.com)
Notez qu’un certificat de classe 1 ne s’applique pas aux sous domaines. Ainsi le certificat créé vous permettra de sécuriser votre TLD et le sous domaine choisit. Il est donc important de choisir le sous domaine que vous utilisez pour accéder à votre interface ISPConfig dans le cas présent.

Heureusement, StartSSL nous permet de créer autant de certificats de classe 1 qu’on le souhaite pour autant de sous domaines que l’on souhaite protéger. Vous pourrez ainsi par la suite protéger www.votredomaine.com, ftp.votredomaine.com etc. Si en revanche vous souhaitez protéger tous vos domaines avec un seul certificat, il vous faudra un certificat de classe 2, et celui-ci ne sera pas gratuit (le prix n’est toutefois pas excessif.)

StartSSL, choix du sous-domaine

StartSSL, choix du sous-domaine

Après quelques instant, votre certificat est généré, vous recevrez également un mail de confirmation. Si vous souhaitez le récupérer à postériori, rendez vous dans l’onglet Toolbox puis Retrieve certificate.
Comme nous l’avons fait pour le CSR, copier intégralement le contenu du champ présenté. Après avoir fait un backup du certificat original ispserver.crt remplacez tout le contenu du fichier.

StartSSL, récupération du certificat

StartSSL, récupération du certificat



Le contenu doit être de la forme suivante:

Il vous faudra ensuite télécharger les certificats racines de StartSSL sur votre serveur,

puis les renommer,

Application du certificat à l’interface ISPConfig

Il ne reste alors plus qu’à effectuer une petite modification dans le fichier vhost de ISPConfig, /etc/apache2/sites-available/ispconfig.vhost

Il vous faut ajouter la chaîne de certificat. Rechercher la zone # SSL Configuration  et ajouter la dernière ligne comme suit:

Il vous faudra bien veiller à modifier à nouveau votre fichier vhost après une mise à jour d’ISPConfig si celui-ci a été écrasé.
N’oubliez pas de redémarrer apache.

A ce stade, vous pouvez déjà vous connecter en https à votre interface d’administration ISPConfig. Le certificat devrait être correctement accepté par votre navigateur et vous devriez avoir la joie de voir apparaître un magnifique cadenas vert (selon les navigateurs…) Les étapes suivantes sont utile pour configurer les services associés tels que le ftp pour utiliser votre certificat ainsi créé.

Sécuriser son serveur Debian, les règles de base

 Serveurs dédiés  Commentaires fermés sur Sécuriser son serveur Debian, les règles de base
Août 112012
 

Introduction

Dans l’administration d’un serveur, la sécurité doit être un point essentiel et ne doit en aucun cas être prise à la légère. Votre point d’accès central au serveur est (et restera) votre connexion ssh. Dans le cas d’une distribution linux ‘nue’ vous ne disposerez pas d’autre moyen d’accès à votre serveur lors de la première connexion. Enfin, même une fois complètement fonctionnel, vous serez toujours amenés à vous connecter en ssh à celui-ci. Il est donc important de sécuriser correctement cet accès et il peut également s’avérer pratique d’automatiser la connexion à partir d’une machine suffisamment sécurisée physiquement. Je m’attarderais dans ce post à la configuration de la connexion en ssh depuis Windows via Putty. Putty est un logiciel gratuit aux fonctionnalités multiples. Il permet notamment d’établir aisément des connexions de type telnet, ssh, rlogin/rsh et raw. Vous trouverez le logiciel en téléchargement sur le site de l’éditeur: http://www.chiark.greenend.org.uk/~sgtatham/putty/download.html

Premiers réflexes:

Lors de votre première connexion au serveur, il est important de prendre deux précautions.

  1. Penser à changer le mot de passe du root (qui vous a probablement été transmis en clair, par mail.
  2. Créer un nouvel utilisateur et lui donner les droits suffisants pour l’administration afin d’éviter de travailler en root sur le serveur.

Changer le mot de passe root.

Vous avez de cette façon créé un utilisateur héritant des droits des groupes root et admin. Vous pouvez alors vérifier la connexion avec le nouvel utilisateur (commande ‘su’) puis vous déconnecter de root. Il reste maintenant à sécuriser votre connexion ssh.

Utilisation de putty et connexion à l’aide de clés ssh:

Maintenant que les bases sont posées pour la sécurité de votre serveur, vous pouvez être tenté d’en automatiser la connexion à partir de votre poste de travail principal. Bien évidemment, je ne m’attarderais pas sur le fait qu’il convient, dès que l’on pense à ce genre de solution, de s’assurer de la sécurité du poste de travail en question. (D’autant plus si vous gérez plusieurs serveurs.) Toutefois, il est souvent plus simple de sécuriser une machine locale qu’un serveur distant. (Et si l’IP de votre serveur sera facilement accessible par n’importe qu’elle personne accédant à l’un de vos services, il lui sera bien plus difficile de trouver l’IP à partir de laquelle vous administrez le serveur, ce qui rend l’attaque en ligne plus délicate.)

  1. Génération de la clé SSH: Nous allons tout d’abord utiliser PuttyGen (disponible sur la page de téléchargement de putty) afin de générer la clé ssh. Pour la plupart des cas d’utilisation, les paramètres par défaut suffisent amplement. Ils génèrent une clé SSH-2 (Rsa) qui est la clé la plus sécurisé qu’il est en mesure de créer. La clé est cryptée sur 1024bits qui, à ce jour est considérée comme incassable dans des délais humainement raisonnables. (Il va de soit que la technologie évoluant, il sera toujours nécessaire d’augmenter la complexité de cryptage au fil des ans…) Appuyez sur « generate » et bouger votre souris à l’écran pour générer une clé totalement aléatoire. La clé s’affiche dans le premier cadre. Le champ « key comment » vous permet d’entrer une zone de texte pour identifier votre clé. Le champs « passphrase » vous permet de définir un mot de passe pour protéger l’utilisation de votre clé privée. Si vous n’entrez pas de mot de passe, l’utilisation de la clé ne sera pas restreinte. C’est à dire que n’importe quelle personne ayant accès à votre ordinateur ou ayant réussi à se procurer votre clé pourra l’utiliser pour se connecter librement à votre serveur. L’utilisation d’un mot de passe vous permet ainsi de sécuriser votre connexion mais il vous sera toujours demandé lors de la connexion au serveur. Il vous faut alors sauvegarder votre clé privé et votre clé publique (« save public key » et « save private key ») L’extension de la clé privé doit nécessairement être du type .ppk pour la clé publique, il est communément admis l’utilisation de l’extension .pub
  2. Vous pouvez maintenant configurer Putty afin d’utiliser automatiquement la clé ssh que vous venez de configurer. Après avoir configuré votre Host Name et le port pour votre connexion, qui dépend de la configuration de votre serveur ( je recommande d’utiliser un autre port que le port 22 pour des raisons de sécurité…) Dans la catégorie SSH c’est le menu Auth qui vous intéresse. Dans la zone Private key file for authentification saisissez l’emplacement de votre clé privé (extension .ppk si vous avez suivi les instructions ci-dessus.) Vous pouvez ensuite revenir au menu Session afin de sauvegarder la configuration.
  3. Connectez vous à l’aide de votre mot de passe sur votre serveur. Placez vous dans le répertoire home de l’utilisateur pour lequel vous souhaitez activer l’authentification par clé. Il vous suffit ensuite de créer le répertoire .ssh (s’il n’existe pas déjà) qui contiendra vos diverses clés ssh privées ou publique pour les diverses authentifications que vous mettrez en place. Il vous suffit ensuite de créer le fichier  authorized_keys et d’y coller le contenu de votre clé publique. (Si puttygen est toujours ouvert, vous pouvez copier le contenu de la clé, autrement, il vous suffit d’ouvrir votre clé .pub avec un éditeur de texte et d’en copier le contenu.) Enregistrer le fichier et déconnectez vous du serveur.

Vous pouvez alors tenter de vous reconnecter à votre serveur avec putty et la connexion configurée précédemment. Si vous aviez configuré un mot de passe pour votre clé, celui-ci vous sera demandé à chaque connexion (mais n’est plus transmis au serveur ce qui diminue le risque d’interception du mot de passe) si vous n’aviez configuré aucun mot de passe, vous vous connectez directement au serveur. Si la connexion échoue, votre serveur vous demandera votre mot de passe pour vous connecter manuellement. Vérifier alors la bonne mise en place des clés .ppk et .pub sur Putty et sur votre serveur.

Vous avez ainsi pu sécuriser et automatiser la connexion à votre serveur par ssh. Il existe bien évidemment d’autres méthodes pour disposer d’une connexion sure et ceci n’est pas La méthode fondamentale. Toutefois, elle permet déjà de sécuriser convenablement la connexion et éventuellement de l’automatiser afin d’éviter d’avoir à entrer un mot de passe à chaque connexion.