Configuration et sécurisation d’un serveur Linux Debian Jessie: Partie 2

Deuxième partie de l’article sur la configuration d’un serveur Linux Debian Jessie. Ici on va parler de sécurité. Pour ceux qui arrivent en cours de route le premier morceau sur la configuration de base ce trouve ici.

Dans cette partie on va s’attaquer à la sécurisation du serveur ! Il est indispensable de se protéger un minimum  des scripts qui se baladent sur le net à la recherche d’une petite machine comme la nôtre à transformer en botnet.

Partie 2: Sécurisation

Verrouillage du SSH

Le SSH est l’accès principal au serveur. Il est indispensable afin de se connecter à la machine à distance. Il est aussi la cible numéro 1 des attaques afin de prendre contrôle du serveur. Il est très important de veiller à ce que cet accès soit correctement protéger.

La première chose à faire consiste à changer le port d’écoute du serveur par défaut sur 22 pour un port plus exotique. Cela s’appel faire de la sécurité par l’obscurité. Nombreux script d’attaque effectuent une tentative de connexion sur les adresses IP publique au hasard avec le port SSH par défaut comme destination. Pour modifier le port, éditez le fichier /etc/ssh/sshd_config

Puis relancez le service. Attention si vous êtes connecté via SSH votre connexion sera coupée.

Le changement de port n’est pas suffisant, un scan approfondit permet de trouver que derrière le port exotique que nous venons configurer se cache le protocole SSH en attente de connexion.

On va ajouter l’une des deux sécurités suivantes, à vous de choisir celle qui convient le mieux:

  • verrouillage par clé privé
  • verrouillage avec mot de passe OTP

Option 1: Le verrouillage par clé privé

Il est possible de faire en sorte que le serveur SSH n’accepte uniquement la connexion en présence d’une clé privé.

Coté client il faut générer une paire de clé publique/privé.

Avec un client Linux

Si vous etre sous Linux, générez une paire de clé comme suit

Vous n’êtes pas obligé de saisir une passphrase lorsque l’on vous le demandera.

Vous avez à ce moment créé deux fichiers dans le répertoire home de votre utilisateur qui correspondent à la clé privé et la clé publique:

  • /home/moua/.ssh/id_rsa
  • /home/moua/.ssh/id_rsa.pub

Il ne reste qu’a copier la clé publique sur le serveur, sous linux il y a une commande pour ça. Ici on précise le nouveau port.

Vous pouvez ensuite tester que la connexion SSH s’effectue bien sans demander de mot de passe

Avec un client Windows

Sous Windows vous utilisez probablement l’outil Putty. Vous devez télécharger l’outils PuttyGen qui permet de générer une clé privé et publique au format PPK supporté par Putty.

puttygen

Enregistrez la clé publique et la clé privé au format PPK sur votre machine.

Copiez le contenue de la clé publique dans le fichier /root/.ssh/authorized_keys sur le serveur (créez le si il n’existe pas).

Enfin, précisez au client Putty le chemin vers la clé privé.

putty_private_key

 

Testez la connexion, celle ci doit se faire sans demander le mot de passe.

Verrouillage effectif

N’effectuez pas les manipulations suivantes sans être sur que la connexion sans mot de passe est bien fonctionnelle !

On va maintenant éditer le fichier de configuration /etc/ssh/sshd_config du serveur ssh et apporter les modifications qui suivent

On redémarre le service SSH pour prendre en compte les modifications

Et voila ! La connexion à votre serveur est uniquement possible à l’aide de votre clé ssh privé. Pensez bien à la sauvegarder!

Option 2: Mot de passe OTP

La première option est sympa, mais requière de toujours avoir sa clé privé sur le terminal qui doit effectuer la connexion. Dans cette seconde solution je propose de mettre en place un système basé sur OTP. Un Mot de passe unique ou OTP (One-time password) est un mot de passe qui n’est valable que pour une session ou une transaction.

Le système se base sur le temps de synchronisation entre le serveur d’authentification et le client fournit le mot de passe (les OTP ne sont valables que pour une courte période de temps). Il est donc préférable d’avoir correctement configurer le NTP.

La partie cliente se compose d’un logiciel qui s’exécute sur votre smartphone. Si vous n’en avez pas vous pouvez passer à la suite directement.

Pour mettre en place ce service nous allons utiliser Google Authenticator. Alors pour être clair, il y a bien Google dans le nom du programme mais ne vous inquiétez pas, votre mot de passe ne part par sur les serveurs du géant américain. C’est juste que Google est à l’origine du projet open source.

Le paquet est disponible dans les dépôt de Debian depuis la version Jessie. Pour l’installer il suffit donc de taper la commande suivante

Une fois installé, on tape la commande suivante pour générer une clé secrète sur la machine

Le programme vous affichera alors deux choses:

  • un QR code, que vous devez scanner avec l‘application Google Authenticator. Ici le lien est pour Android mais le client est aussi disponible sur iOS et BlackBerry.
  • Des codes d’urgences (emergency scratch codes) que vous devez copier et garder quelque part en sécurité, ils vous seront demandé si vous perdez votre téléphone. Ces codes ne sont valable q’une seule fois chacun.

Une fois le code barre scanné, le programme vous affichera un mot de passe temporaire qui changera toute les 30 secondes.

google_auth_android

 

Il reste à activer le service à la connexion. Éditez le fichier /etc/pam.d/sshd et ajouter la ligne suivante en fin de fichier

Enfin, éditer la configuration de SSH dans le fichier /etc/ssh/sshd_config et modifiez la ligne suivante

Relancez le service SSH pour prendre en compte les changements

Voila, à la prochaine connexion SSH, Vous tapez votre mot de passe habituel, puis vous serez invité à taper le code de vérification.

Protection anti-intrusion

Les machines exposées au réseau Internet, sont continuellement la cible de tentatives d’attaques de type brute force et DOS. Pour s’en protéger nous allons mettre en place un petit programme du nom de Fail2Ban.

Pour rappel, Fail2Ban est un programme écrit en python et disponible dans la plupart des dépôts Linux qui à pour but de prévenir des attaques de type brute-force.  Fail2ban lit les logs de divers serveurs (SSH, Apache, FTP…) à la recherche d’erreurs d’authentification répétées et ajoute une règle iptables pour bannir l’adresse IP de la source.

Installation

Il y a plusieurs modifications à effectuer pour utiliser correctement Fail2Ban:

  • Par défaut, les prisons (jails) de fail2ban sont un peu trop permissives, il faut les changer pour que le nombre d’essais soit plus petit et le temps de ban soit plus long. Ça se passe dans /etc/fail2ban/jail.conf, voici un exemple de conf :

  • Dans ce même fichier de configuration on va changer l’adresse email de contact

  • Et enfin, toujours dans ce fichier de configuration, on change l’action par défaut pour que Fail2Ban envoi un mail avec un rapport complet sur l’adresse bannie.

  • Un problème problème avec fail2ban, c’est qu’il ne persiste pas les ips bannies… Quand on redémarre, les méchants sont unbans et c’est open-bar pour eux de nouveau. Pour persister les ips bannies, il faut modifier le fichier /etc/fail2ban/action.d/iptables-multiport.conf qui définit (entre autres) les actions en cas de ban et en cas de démarrage de fail2ban. En cas de ban, on ajoute l’ip à un fichier texte. Au start de fail2ban, on lit ce fichier texte et on bannit toutes les ips qu’il contient.

  • Un truc pas mal aussi, si vous avez plusieurs serveurs, c’est de savoir qui envoi le mail. Pour cela on édite le fichier /etc/fail2ban/action.d/sendmail-whois-lines.conf. En ce qui me concerne j’ai modifié pour les 3 actions (actionstart, actionstop et actionban) la valeur entre croché ou il est écrit « [Fail3Ban] » par le nom de mon serveur.

Par défaut seul la prison SSH est active. Vous trouverez à la fin du fichier de configuration /etc/fail2ban/jail.conf une liste de prison pré-configurée. Pour les activer il suffit de changer l’état de la variable « enabled ». Par exemple si l’on installe un serveur web par la suite on activera la prison correspondante comme cela

Il ne reste qu’a relancer le programme pour prendre en compte les changements

Protection contre le scan de ports

C’est l’une des premières étapes pour effectuer le piratage d’une machine sur internet: le scan de ports.

Cette technique consiste à effectuer un balayage des  ports ouverts sur la machine cible. Chacun de ses ports correspondant à des services accessibles. Le pirate peut ensuite chercher une faille à exploiter dans l’un des services en question pour s’introduire sur vôtre système. On va mettre en place un outil pour empêcher ce scan.

Installation de portsentry

La configuration s’effectue dans le fichier /etc/portsentry/portsentry.conf. Je vous affiche ici uniquement les lignes à modifier

On redemarre le service pour prendre en compte

Test depuis un client Linux. Attention cette ligne de commande va provoquer le bannissement de l’IP à l’origine de l’attaque.

Pour enlever le ban on supprime la route.

Puis on édite le fichier /etc/hosts.deny et on supprime la ligne de l’ip correspondante qui ressemble a ceci

Le serveur est suffisamment protégé pour le moment. D’autres sécurités seront mis en place au fur et à mesure de la mise en place de service.

On va passer à la dernière étape de la configuration du serveur: le monitoring.

18 thoughts on “Configuration et sécurisation d’un serveur Linux Debian Jessie: Partie 2”

  1. GGLinnk dit :

    Wha c’est quoi ce tuto ?????
    Après avoir créer les fichiers ppk avec PuttyGen et avoir intégré dans Putty le fichier privé, où faut il faut mettre le fichier public ??? car si on n’intègre pas celui-ci sur le serveur on obtiendra automatiquement une erreur de refus de connexion. Je suis totalement perdu il faudrait revoir le TUTO qui me semble incomplet …

    1. GGLinnk dit :

      Ok je n’avait pas compris autorized_key est un fichier et non pas un dossier

  2. Mehdy dit :

    Bonjour,
    j’ai créer trois utilisateurs en plus du root et je n’arrive pas à me connecter en SSH avec mes trois utilisateurs.
    Je voudrais qu’ils puissent y accéder avec un OTP qui fonctionne très bien sur root.
    Auriez vous une solution ?

    Cordialement.

    1. Mehdy dit :

      C’est bon, il faut se connecter a l’aide de la commande su (user) sur chaque utilisateur et leur creer un profil google authenticator.

      1. N.i.c.O dit :

        Bien joué. J’ai oublié de répondre entre temps. Désolé.

  3. Max dit :

    hello

    il y a une faute de frappe pour redémarrer fail2ban
    systemctl restart fail2ban et non sytemctl restart fail2ban

    1. N.i.c.O dit :

      C’est corrigé, merci.

  4. Nostromo dit :

    Salut à tous,

    je viens de lire ton tutoriel il est super bien fait et par avance merci… mon ssh était déjà bien verrouiller mais rajouter OTP est toujours un plus… ( je suis un petit peu trop parano peut être ^^)…

    bref.. j’ai quand même un petit souci : j’ai bien tout installer OTP mais maintenant en voulant me connecter avec mon user ( j’ai interdit le root de ce connecter à distance: PermitRootLogin = no) il m’est impossible de me connecter. Je n’ai qu’un user.

    Après avoir entrée le nom de mon user voila ce que j’obtiens
    Password: (je rentre ici mon mot de passe habituel)
    Access denied
    Using keyboard-interactive authentication.
    Password:

    Il se passe quoi ?

    Merci pour vos réponses.

      1. Nostromo dit :

        Salut,

        je viens de lire le tutoriel que tu m’as donner mais c’est exactement ce que j’ai fais en repondant « y » a toutes les question… bon je vais réinstaller (car je n’ai plus du tout accès a mon serveur) en laissant l’autorisation au root de se logger à distance pour tester.

        je reviens faire un feedback des que j’ai trouver ce qui ne va pas…

        merci encore ^^

        Nos…

        1. N.i.c.O dit :

          Sinon il y a le mode rescue si tu es chez OVH. Et oui comme il est écrit dans l’article en rouge et gras: ne pas couper l’accès sans avoir testé 🙂

          1. Nostromo dit :

            oui mais j’ai couper bêtement ^^ erreur de débutant comme quoi ça arrive a tout le monde de faire des bêtises ^^
            heureusement que je viens de tout reformater car j’étais encore en Wheezy ^^ et j’ai préféré remettre tout propre l’installation ^^

            Et non je ne suis pas chez OVH mais chez son concurrent… le mode rescue oui je sais mais vue que je viens de le réinstaller donc je recommence l’installation… j’aime quand c’est tout beau tout neuf ^^ bref… je te reviens….

            Par contre pour moi il manque des choses au niveau de la sécurisation serveur… par exemple tu n’as pas parler de rkhunter par exemple… ni du firewall comme iptable avec netfilter etc…

            Nos…

          2. N.i.c.O dit :

            Rkhunter à un mauvais ratio ressources consommées / utilité.
            Iptables je n’utilise plus, mes serveurs écoutent sur les ports que j’autorise à écouter. Il m’est donc inutile de fermer le reste car se n’est de toute façon pas en écoute. Et ça consomme aussi du temps cpu. Je suis très radin la dessus 🙂

  5. Nostromo dit :

    Me revoilà.
    Alors mon Feedback:
    Pour ce qui est du site sur lequel tu me revois, à part le fait d’avoir installer une « dépendance », j’ai quand même suivi ton tutoriel, pour ce qui est du reste, mais en autorisant, pour le moment, au user root de se connecter à distance et là tout à bien fonctionner.
    Par contre pour chaque user, il faut également installer un profile google-authenticator pour que cela fonctionne. Je pense qu’il serai bien d’expliquer la manipulation à faire pour réussir à ce que tout fonctionne correctement et surtout pour qu’un éventuel débutant puisse s’en sortir du premier coup ^^
    Maintenant je peux refermer l’accès distant au root ^^ puisque je passe par le user pour accéder au user root (c’est le mieux à mon goût).
    Donc, installer la « dépendance » (je pense tout de même que c’est optionnelle) avant de lancer la commande « google-authenticator »

    apt-get install libpam0g-dev

    Puis un fois le profile installer sur le user « root », faire un « su autre_user » pour changer de user, aller dans le /home de celui-ci (commande « cd » sans les ».. » derrière) et créer un profile en lançant la commande « google-authenticator » (évidement ne pas oublier de scanner le Qrcode avec l’application google-authenticator). Puis exit pour revenir en root. ( à faire avec chaque user).

    Maintenant la question se pose: comment faire si on ne veux pas que tel utilisateur utilise le google-authenticator ?

    Voila bonne lecture à tous ^^

    Nos…

  6. Nostromo dit :

    Bonjour,
    Je reviens vers vous car j’ai un souci avec navicat qui ne me demande pas le code de vérification de google authenticator, du coup impossible de me connecter pour la gestion de mes bdd…

    navicat n’est il pas compatible avec OTP ? pourtant j’utilise bien le tunneling ssh pour me connecter a ma machine

    Merci de vos retour.

    Nos…

    1. N.i.c.O dit :

      Je ne connais pas du tout navicat. Désolé.

  7. Nostromo dit :

    Bonjour a tous,

    voila alors pour Navicat et certainement d’autre logiciel qui passe par le ssh pour la connection:

    Il n’est pas compatible avec OTP (source de l’éditeur: j’ai ouvert un ticket pour savoir d’ou venait le problème et il m’a répondu que Navicat n’était pas compatible avec OTP).

    D’où l’importance pour moi de savoir si oui ou non on peux faire qu’un user n’utilise pas l’OTP et les autre l’utilise.

    Merci de votre retour si quelqu’un sait comment faire ^^

    Bien a vous,

    Nos…

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *