Configurer et sécuriser votre serveur

Sécuriser votre connexion SSH et fail2ban

Ce contenu est obsolète. Il peut contenir des informations intéressantes mais soyez prudent avec celles-ci.

La sécurisation de votre serveur est principalement mise en place par le paramétrage de votre connexion à distance SSH.

Ce billet s’applique à tous les systèmes disposant d’une connexion à distance, elle est indépendante de l’usage que vous allez faire de votre serveur.

Ce billet propose un bon point de départ pour débuter la sécurisation de votre serveur. Libre à vous d’aller plus loin et de vous documentation sur les outils utilisés dans ce billet.

Sécuriser votre connexion SSH

Pour améliorer la sécurité de votre serveur vous pouvez utiliser une clé SSH avec un gestionnaire de mot de passe, plutôt qu’un mot de passe pour accéder à votre serveur, c’est une solution qui se veut plus sûre qu’un mot de passe. Si vous avez déjà un gestionnaire de mot passe foncé, sinon essayez sans avec airbus comme mot de passe efficace. :lol:

Les grandes lignes de la sécurisation de votre connexion SSH consistent à changer le port de SSH, d’autoriser un utilisateur avec un nom d’utilisateur différent de ceux par défaut (ex: objetvolant) et d’interdire la connexion en root.

Une fois connecté, vous devrez utiliser la commande su pour changer d’utilisateur (ex : su root).

1. Créer un utilisateur pour l’utiliser comme identifiant de connexion

Avant de continuer, vous devez créer un utilisateur qui vous servira pour vous connecter en SSH. En effet, utiliser le compte root est déconseillé. J’appellerai ce compte : objetvolant.

  1. adduser objetvolant
  2. Choisissez un mot de passe compliqué et sûr. (N’oubliez pas que par défaut le pavé numérique est désactivé dans PuTTY).

Vous pouvez en profiter pour changer le mot de passe du compte root avec : passwd, choisissez un mot de passe différent que celui de objetvolant. Garder un mot de passe reçu par email n’est pas conseillé !

2. Modifier la configuration SSH

Pour modifier la configuration SSH, vous devez éditer le fichier de configuration : /etc/ssh/sshd_config. Pour éditer le fichier, utilisez la commande vim /etc/ssh/sshd_config une fois fini, il faudra recharger le service SSH avec : service ssh reload.

Comment utiliser VIM ?

De nombreux tutoriels expliquent de façon complète l’usage de vim. Je vais vous expliquer l’essentiel. Lorsque vous ouvrez un fichier avec vim, la toute première chose est de modifier le mode de saisie avec la touche Inser, constatez — INSERTION — en bas de votre console.

Déplacez vous avec les flèches directionnelles de votre clavier.

Lorsque vous avez fini, faites CTRL + C — regardez en bas — écrivez la commande voulue puis validez avec Entrée. Voici les principales commandes :

  • :w pour sauvegarder ;
  • :q pour quitter ;
  • :wq pour sauvegarder puis quitter ;
  • :q! pour quitter sans sauvegarder.

Astuce : Comment copier/coller le presse-papier sous VIM avec PuTTY ? Avec : Shift + Inser

1. Changer le port

Il est important de changer le port par défaut (port 22) pour diminuer la visibilité des bots qui parcourent internet à la recherche de serveur mal sécurisé en vérifiant le port 22. Ce changement permet de diminuer le nombre de logs inutiles et de décourager les essais de BruteForce.

Pour éviter les conflits entre deux applications vérifier la disponibilité du port dans le fichier /etc/services, avec la commande : cat /etc/services. Choisissez un port au-dessus de 10000 non rond pour être sûr de n’avoir aucun conflit. Pour le cours je vais choisir le port 31262. Ne l’oubliez pas, c’est votre nouveau port de connexion au SSH !

  • Vous devez modifier la ligne Port pour obtenir : Port 31262.

2. Interdire la connexion en root

La première chose que va faire une personne mal intentionnée est d’essayer le compte root. Modifier le nom d’utilisateur root n’est pas une chose à faire. Donc on interdit la connexion au compte root.

  • Vous devez modifier la valeur de PermitRootLogin pour obtenir : PermitRootLogin no.

3. Autoriser l’utilisateur objetvolant

Pour autoriser objetvolant dans votre espace aérien, c’est-à-dire à se connecter en SSH, vous devez l’ajouter à votre liste d’utilisateur autorisé. Par défaut, la ligne est commentée # ou absente, ajoutez là si vous ne la voyez pas.

  • La ligne AllowUsers doit contenir objetvolant donc : AllowUsers objetvolant.

4. Modifier le niveau des logs

L’outil fail2ban fonctionne à partir des entrées des logs. Afin d’améliorer son efficacité, on augmente la sensibilité des logs, on passe d’INFO à VERBOSE pour avoir plus d’entrées.

  • Vous devez modifier la valeur de LogLevel pour obtenir : LogLevel VERBOSE.

5. Sauvegarder et recharger

Pour sauvegarder vos changement et quitter vim utilisez :wq ensuite service ssh reload. Ouvrez une deuxième session de PuTTY et vérifiez vos changements en essayant de vous connecter au compte root (vous ne devriez pas réussir) et au compte objetvolant.

Si vous obtenez une erreur à la suite de la commande service ssh reload corrigez l’erreur avant de fermer PuTTY, car la connexion à distance est désactivée jusqu’à la correction du problème. Si par mal chance, la connexion devait se couper, utilisez : le KVM dans le manager d’OVH pour vous connecter à votre serveur ; ou si ce n’est pas un serveur l’écran de votre machine.

Faciliter la connexion SSH après la première connexion

Si vous êtes fatigué de devoir passer votre compte spécial pour la connexion SSH (objetvolant). Vous pouvez après avoir ouvert une première connexion SSH autoriser la connexion aux autres comptes pour votre ordinateur (tant que la première connexion SSH reste active).

Pour ce faire nous allons utiliser le Port Forwarding qui est une fonctionnalité de la connexion SSH, activable dans les paramètres de PuTTY ou en ligne de commande.

Modifier votre configuration

Commencez à modifier /etc/ssh/sshd_config, en rajoutant en dernier à la fin du fichier cette instruction :

Match Address 127.0.0.1
    AllowUsers avion, zds

N’oubliez pas de : service ssh reload.

Vous connecter

Pensez à modifier 31262, objetvolant et ipserveur dans les commandes SSH suivantes.

Votre première connexion

Lors de la première connexion en ssh vous devrez faire :

ssh -L 31262:localhost:31262 objetvolant@ipserveur -p 31262

Vos connexions suivantes

Lors de vos connexions suivantes vous devrez faire (modifier 31262 et objetvolant) :

ssh avion@localhost -p 31262

avion est le nom d’utilisateur souhaité.

SSMTP : Envoyer des emails

Pour configurer l’envoi de mail de votre serveur, suivez les instructions de ce billet. En effet, vous pouvez intégrer l’envoi de mail à fail2ban (=> votre futur firewall qui met en place des règles iptables pour bannir).

Vous pouvez aussi vous faire prévenir par mail d’une connexion SSH .

Installer et configurer fail2ban

Commençons par mettre à jour toutes les applications : apt-get update && apt-get upgrade.

Installation

Ensuite installez fail2ban apt-get install fail2ban. Il permet de mettre en place des règles de bannissement pré-configuré selon les entrées des logs.

Structure du répertoire fail2ban

  • jail.d/ : Emplacement de vos configurations (notamment jail.local), permet de définir une sanction lorsqu’un filtre est validé un certain nombre de fois.
  • filter.d : Les règles qui permettent d’analyser et d’identifier un comportement.
  • action.d : Configure les actions à faire (notamment : Ajouter une règle iptables, envoyer un email, ajouter une ligne à un fichier log, etc…).

Configurer

Les fichiers de configuration se situent dans : /etc/fail2ban/.

La documentation recommande de ne pas modifier le fichier de base jail.conf mais le fichier jail.d/jail.local qui prendra le dessus sur la configuration de base. N’hésitez pas à faire cat /etc/fail2ban/jail.conf pour comprendre ce que fait la configuration de départ. Pour écrire la configuration de jail.local, j’ai regardé jail.conf et j’ai changé ce qui ne me plaisait pas, prenez le temps de lire les commentaires du fichier, ils aident beaucoup.


Pour commencer à configurer fail2ban faites : vim /etc/fail2ban/jail.d/jail.local.

[DEFAULT]

maxretry = 6
#Une semaine = 604800 secondes, deux semaines = 1209600.
findtime = 604800
bantime  = 1209600

destemail= votre@email
sender   = email@duserveur
action   = %(action_mwl)s
mta      = sendmail

ignoreip = 312.312.312.312 127.0.0.1

[ssh]
enabled  = true
port     = 31262
maxretry = 6
#          ^ --> [DEFAULT].maxretry ne peut pas prendre le dessus sur [ssh].maxretry
# car il existe dans jail.conf il faut donc déclarer maxretry dans ssh pour pouvoir
# définir une valeur personnalisée.

#Normalement en ssh vous n'avez pas besoin d'ignorer 127.0.0.1 en ssh
#(sauf si vous utilisez la fonctionnalité de port forwarding ssh -L 31262:localhost:31262)
ignoreip = 312.312.312.312

bantime : effective ban duration (in seconds).
findtime : time interval (in seconds) before the current time where failures will count towards a ban.
maxretry : number of failures that have to occur in the last findtime seconds to ban then IP.

Documentation

Pensez à modifier le port 31262 par votre port de connexion et les deux emails par les vôtres.

Réglez à votre convenance : maxretry, findtime et bantime. Sachez que si vous vous faites bannir, vous pourrez toujours accéder à votre serveur via le KVM ou l’écran de votre machine. Si le SSH est votre seul moyen de connexion, rajoutez une règle ignoreip dans jail.local pour ne pas tenter le diable.

Pour recharger fail2ban, faites fail2ban-client reload.

Se débannir de fail2ban

Accédez à la console en compte root. Il s’agira pour les VPS d’utiliser le KVM et pour les autres directement l’écran de votre machine.

Si vous suivez les instructions de ce sujet

  1. Accéder au mode interactif avec : fail2ban-client -i (Il faudra faire CTRL + C pour le quitter).
  2. Pour récupérer la liste des IP bannies faites status ssh.
Status for the jail: ssh
|- filter
|  |- File list:        /var/log/auth.log
|  |- Currently failed: 0
|  `- Total failed:     12
`- action
   |- Currently banned: 2
   |  `- IP list:       24.105.25.248 123.123.123.123
   `- Total banned:     2
  1. Puis pour débannir notre IP faites set ssh unbanip 123.123.123.123

Personnaliser les emails à recevoir

Vous pouvez choisir quels types d’informations recevoir lors d’un bannissement ou bien créer votre propre configuration (dans action.d/) pour modifier, traduire, ou désactiver certain mail (start and stop par exemple).

Choisir la configuration du mail de bannissement :

Lors d’un bannissement vous avez le choix entre 3 types de mails lors d’un ban :

  • action = %(action_)s : Par défaut voir l’extrait ci-dessous.
  • action = %(action_mw)s : Le même que le précédent mais avec un whois.
  • action = %(action_mwl)s : Le même que le précédent mais avec les lignes de log qui ont provoqué le ban.

Pour personnaliser ou traduire le mail vous pouvez modifier, selon votre précédent choix : action.d/sendmail.conf, action.d/sendmail-whois.conf ou action.d/sendmail-whois-lines.conf.

Extrait de la configuration pour le mail de bannissement %(action_)s
# Option:  actionban
# Notes.:  command executed when banning an IP. Take care that the
#          command is executed with Fail2Ban user rights.
# Tags:    See jail.conf(5) man page
# Values:  CMD
#
actionban = printf %%b "Subject: [Fail2Ban] <name>: banned <ip> from `uname -n`
            Date: `LC_TIME=C date -u +"%%a, %%d %%h %%Y %%T +0000"`
            From: <sendername> <<sender>>
            To: <dest>\n
            Hi,\n
            The IP <ip> has just been banned by Fail2Ban after
            <failures> attempts against <name>.\n
            Regards,\n
            Fail2Ban" | /usr/sbin/sendmail -f <sender> <dest>

Créer votre configuration/propre mail :

Si vous voulez créer votre fichier .conf, par exemple : sendmail-avion_en_papier.conf vous aurez besoin de rajouter ces deux lignes à votre fichier jail.d/jail.local. Vous permettant de relier le fichier à votre configuration.

action_mwl_avion = %(banaction)s[name=%(__name__)s, port="%(port)s", protocol="%(protocol)s", chain="%(chain)s"]
               %(mta)s-avion_en_papier[name=%(__name__)s, dest="%(destemail)s", logpath=%(logpath)s, chain="%(chain)s", sendername="%(sendername)s"]
action = %(action_mwl_avion)s

Vous trouverez plus d’information dans la catégorie # Action shortcuts. de jail.conf.


N’hésitez pas à aller voir le billet sur comment configurer fail2ban avec apache2 ou un autre serveur HTTP.

12 commentaires

Il y a également la possibilité d’utiliser un système comme blocklist-ipsets pour bannir automatiquement (et donc ne pas gérer les requêtes de) certaines IP rapportées comme ayant un comportement suspect.

À fail2ban on peut aussi y câbler un système pour rapporter directement à ce genre de service les IPs qu’on a banni.

+0 -0

Il y a également la possibilité d’utiliser un système comme blocklist-ipsets pour bannir automatiquement (et donc ne pas gérer les requêtes de) certaines IP rapportées comme ayant un comportement suspect.

À fail2ban on peut aussi y câbler un système pour rapporter directement à ce genre de service les IPs qu’on a banni.

Heziode

Ouep j’ai vu passer : http://www.mynetwatchman.com/ dans /etc/fail2ban/action.d/mynetwatchman.conf. Je ne sais pas ce que ça vaut par contre.

Hello,

Billet fort sympathique. Je me permets quelques remarques :

  • Ce billet concerne les distributions linux. Il existe une alternative à IPTables, beaucoup plus intuitive et plus simple à utiliser.

OpenBSD Packet Filter :

### allow ssh
pass in log quick on egress proto tcp from !(egress) to egress port ssh \
flags S/SA modulate state (max-src-conn-rate 2/360, overload <bruteforce> flush global

La seconde partie de la ligne offre la fonction failtoban et alimente la table PF <bruteforce> :

block log quick from <bruteforce>
  • Très bien d’interdire l’accès root. Néanmoins, si je peux me permettre en terme de sécurité Clé SSH impératif + passphrase : "J’aime quand mon chien me fait la fête le soir !"
  • Le changement de port demeure quand même une rustine. Un attaquant lambda trouvera ton port SSH via un scan de port sur le service. effectivement cela évite les bots "lambda".
  • Si ta machine fait office de serveur de courrier, il vaut mieux utiliser le tryptique : OpenSMTPD + PF + Spamd, avec la surcouche classique : clamav, clamav-unsigned, spamassassin. Ce, via port 587 & 993

Super Job, no offense, je souhaitas effectuer des remarques constructives :)

Si j’ai fais ce billet c’est aussi pour m’améliorer !

Le changement de port demeure quand même une rustine. Un attaquant lambda trouvera ton port SSH via un scan de port sur le service. effectivement cela évite les bots "lambda".

Tout à fait, je ne le précise pas mais c’est juste esthétique et éviter les attaques généralisés/automatiques.

Très bien d’interdire l’accès root. Néanmoins, si je peux me permettre en terme de sécurité Clé SSH impératif + passphrase : "J’aime quand mon chien me fait la fête le soir !".

Je pars du principe que le combo : changement de port + utilisateur de connexion différent + mot de passe fort est largement suffisant. Puis accompagné de LogWatch on a le temps de voir les soucis venir.

Dans mon usage ce qui me dérange c’est le sockage de la clé si on a plusieurs PC (même si mes PC sont sains, je n’aime pas l’idée de les laisser à l’intérieur). Et que j’ai beau utiliser une Clé SSH sur mon serveur, mon compte OVH n’en a pas, ni mon email… Donc beaucoup de soucis pour rien.


D’ailleurs il faudra que je pense à faire un petit billet sur logwatch. :) J’ai oublié de l’ajouter.

Dans mon usage ce qui me dérange c’est le sockage de la clé si on a plusieurs PC (même si mes PC sont sains, je n’aime pas l’idée de les laisser à l’intérieur). Et que j’ai beau utiliser une Clé SSH sur mon serveur, mon compte OVH n’en a pas, ni mon email… Donc beaucoup de soucis pour rien.


A-312

Tu présentes plusieurs sujets ;

  • Stockage de la clé : une génération par poste de travail, et tu exportes la clé publiques. Sous windows j’utilise Bitwise SSH comme outil graphique, il peut générer une clé. Tu copy / paste la clé publique générée dans : .ssh/authorized_keys de l’user de ton serveur cible.

Sous Unix :

ssh-keygen -t rsa -b 4096
  • Un certificat utilisateur de messagerie est basé sur le meme principe, mais lui doit être "signé" par une autorité de certification.
  • OVH, je ne connais pas leur procédure d’authentification. Je suis chez Online

—> Je sais, je sais nul n’est parfait :lol:

Chez Online ils font des efforts au niveau de l’authentification ?

A-312

Je ne voulais pas dire de bétises ;)

J’ai check :

Authentification sécurisée

Online.net permet la validation en deux étapes (à l’aide d’un code envoyé par SMS ou de >Google Authenticator) pour améliorer la sécurité de votre compte. Validation par Google Authenticator

Google Authenticator est un système de validation basé sur des codes à validité limitée >dans le temps. Des implémentations et des applications sont disponibles pour plusieurs >langages et systèmes d’exploitation.

Donc de ma compréhension pas d’authentification par cle SSH sur le portail. Mais une authentifictaion en deux temps possible.

Je boycott google… donc… :ninja:

Ok rien d’extraordinaire, c’est comme OVH.

Je boycott google… donc… :ninja:

Oliv

J’ai essayé intensivement pendant 2 mois, je suis vite revenu sur Google, ça devenait vite un poids. Le seul bon point que j’ai vu pour le canard, c’est que les images en résultat sont de meilleur qualité, plus facile de trouver des illustrations/images à utiliser pour une maquette ou un article.

Ce qui serait également intéressant, c’est un magnifique article sur le chiffrement de partition de serveur et surtout de comment entrer le mot de passe quand le serveur redémarre :lol:.

J’ai essayé intensivement pendant 2 mois, je suis vite revenu sur Google, ça devenait vite un poids. Le seul bon point que j’ai vu pour le canard, c’est que les images en résultat sont de meilleur qualité, plus facile de trouver des illustrations/images à utiliser pour une maquette ou un article.

A-312

Les goûts les couleurs, je suis bien placé pour ça (coucou Python :P), je suis passé du jour au lendemain de G à D (boycte de G également), ça change au début, mais je m’y suis fait. Il est vrai que l’algo de D est moins performant que celui de G. Dans de rare cas où je ne trouve ce que je cherche avec D j’utilise G (car il y a des trucs très mal référencé sur D voir pas du tout malhereusement).

+0 -0

Ce qui serait également intéressant, c’est un magnifique article sur le chiffrement de partition de serveur et surtout de comment entrer le mot de passe quand le serveur redémarre :lol:.

Quand tu utilises le KVM, tu peux suivre le démarrage. ;)

J’ai essayé intensivement pendant 2 mois, je suis vite revenu sur Google, ça devenait vite un poids. Le seul bon point que j’ai vu pour le canard, c’est que les images en résultat sont de meilleur qualité, plus facile de trouver des illustrations/images à utiliser pour une maquette ou un article.

A-312

Les goûts les couleurs, je suis bien placé pour ça (coucou Python :P), je suis passé du jour au lendemain de G à D (boycte de G également), ça change au début, mais je m’y suis fait. Il est vrai que l’algo de D est moins performant que celui de G. Dans de rare cas où je ne trouve ce que je cherche avec D j’utilise G (car il y a des trucs très mal référencé sur D voir pas du tout malhereusement).

Heziode

Tout ce qui était lié à la programmation notamment dev web et javascript était très mal référencé (notamment stackoverflow introuvable sur D mais ça a l’avantage de donner plus de chance au petit site).

+0 -0
Connectez-vous pour pouvoir poster un message.
Connexion

Pas encore membre ?

Créez un compte en une minute pour profiter pleinement de toutes les fonctionnalités de Zeste de Savoir. Ici, tout est gratuit et sans publicité.
Créer un compte