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

Update: Version Debian 8 dispo

Partie 2: Sécurisation

Deuxième partie de l’article sur la configuration d’un serveur Linux Debian. 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.

Firewall

La carte ethernet du serveur est directement connecté a internet. C’est donc le serveur lui même qui fait office de par feu. Pour ce chapitre je vous propose de récupérer un script simple que l’on va installer. Celui-ci fonctionne de la façon suivante:

  • On bloque tout le trafic entrant
  • On laisse le trafic sortant libre. Le serveur va ou il veut.
  • On autorise le ping
  • Empêcher le syn flood 
  • Empêcher le scan de port
  • Enfin ouverture de deux services de base: SSH et HTTP

Vous allez devoir modifier ce script au fur et à mesure de l’implémentation de nouveau service sur vôtre machine. Pour cela vous devez connaitre le port en écoute et le protocole (TCP et/ou UDP).

Par exemple si vous installé un serveur de chat vocale comme mumble, ce dernier écoute sur le port 64738 en TCP et en UDP. Il faut alors ajouter les lignes suivantes au script

Bref je ne donne pas plus d’explication. Vous trouverez ce qu’il faut sur Google en cas de besoin.

Allé on installe le script. Déja pour commencer si vous n’avez pas GIT d’installé il faut taper ça

On récupère le code

On se place dans le dossier

On copie le script dans la init.d

On le rend exécutable

On le place au démarrage

Et enfin, on le lance

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:

  • Fail2ban doit démarrer APRES le script firewall dans l’initd. Comment faire ça ? il faut modifier le script /etc/init.d/fail2ban et rajouter dans les tags LSB dans les Required-Start le nom du script firewall. Du coup, si le script firewall est nommé “myfirewall” dans ses tags LSB, les tags LSB du fail2ban doivent ressembler à ça :

  • 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.

 

 

 

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

  1. yassine dit :

    très bon travaille essayer d’ajouter des icônes pour partager par Facebook
    merci

    1. Sispheor dit :

      Merci! Je vais voir pour ajouter la fonctionnalité.

  2. stc dit :

    Merci pour cet article, j’avais déjà les outils mais apparemment mal configurés.

  3. tom dit :

    Très bon tuto, merci!
    Petite question cependant, si je reprends le script firewall, en quoi la ligne « iptables -A FORWARD -p tcp –syn -m limit –limit 1/second -j ACCEPT » (et les similaires) offrent une protection ? Certes une limite anti-flood est appliquée mais les requêtes sur n’importe quel port sont acceptées, rendant inutiles les règles spécifiques (comme « iptables -A INPUT -p tcp –dport 22 -j ACCEPT ») puisque le paquet sera déjà accepté.

    1. N.i.c.O dit :

      Oui en effet la solution à ses limites. Je ne suis plus vraiment pour l’utilisation de iptables pour bloquer le synflood. Voir du côté de HAproxy plutôt.

      1. alejandro dit :

        Bonjour, j’ai suivi votre tutoriel, je configure portsentry, je lance un scan nmap à partir d’un autre serveur … et ça marche … mon serveur n’est pas banni … est-ce que cela à quelque chose à voir avec le dernier post de tom ?

        Je suis sous Debian 7.5 toute neuve et je suis votre tutoriel depuis le début, à part pour nullmailer car je souhaite passer par postfix que je n’ai pas encore installé.

        Merci pour votre aide.

        1. alejandro dit :

          Pour info j’ai réussi à le faire marcher, mais je ne sais pas si j’ai bien fait.

          Dans le fichier /etc/default/portsentry j’ai remplacé :

          TCP_MODE= »tcp »
          UDP_MODE= »udp »

          par

          TCP_MODE= »atcp »
          UDP_MODE= »audp »

          et ça a marché, mon nmap a échoué :

          Egalement pour effacer ma route il a fallu que j’utilise une commande différente, surement parceque je faisais mon test à partir d’un autre serveur :

          Si ça peut aider quelqu’un …
          Merci également de me préciser si j’ai bien fait de faire la modification dans /etc/default/portsentry en passant le tout en automatique.

          Cdt,

          1. N.i.c.O dit :

            Je n’ai pas eu à faire cela, peut être qu’il y a eu une modification du package. Merci pour le partage.

        2. jo dit :

          J’arrive après la guerre mais je confirme la nécessité de changer tcp et udp par atcp et audp (Ubuntu 16.04 pour ma part) afin que portsentry bloque bien le scan.

Répondre à jo Annuler la réponse.

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