Sécuriser son serveur linux

Sécuriser son serveur linux
08 Février 2015


La sécurité d'un serveur n'est pas à prendre à la légère. Sachez que chaque jour qui passe, de nombreux robots ou humains chercheront à pénétrer votre serveur pour diverses raisons (tout casser, utiliser vos ressources, pour l'honneur, etc ...). En général, d'après mon expérience personnelle, la plupart des attaques sont des attaques de force brute en SSH.

Commençons par le commencement, vous venez de recevoir votre nouveau VPS (serveur virtuel) ou serveur dédié.

Sécurisations indispensables du serveur

Modifiez votre mot de passe root

Première chose à faire, vous avez reçu votre mot de passe par mail, il est donc considéré comme potentiellement intercepté. Il est plus prudent de le changer. Pour cela, une fois connecté en root via SSH :

passwd root

 

Créez l'utilisateur administrateur et bloquer root

La plupart des attaques sont des attaques où des robots vont tenter de se connecter en SSH sur votre serveur avec l'utilisateur root en tentant des combinaisons différentes de mot de passe. Une bonne pratique de sécurité consiste donc à bloquer root et de le remplacer par un utilisateur de votre choix qui aura les privilèges de root.

Commençons par ajouter un utilisateur (ici, je l'appelle "admin" mais choisissez ce que vous souhaitez) :

adduser admin

Il faut installer sudo pour permettre à certains utilisateurs de prendre temporairement les droits root :

apt install sudo

Puis on l'ajoute aux groupes lui permettant d'avoir les privilèges root (j'ai rajouté adm pour pouvoir consulter les logs sans devoir utiliser sudo) :

usermod -G root,sudo,adm admin

Modifier maintenant la configuration de SSH en éditant le fichier /etc/ssh/sshd_config :

PermitRootLogin no         # Interdire root de se connecter en SSH
Port 4854                  # Facultatif : Modifier le port de connexion pour le SSH
AllowUsers admin           # Facultatif : Seul admin peux se connecter en SSH
AllowGroups sshusers       # Facultatif : Seul les utilisateurs du groupe sshusers peuvent se connecter en ssh

Reste à redémarrer le service SSH :

service ssh restart

Une fois loggué avec l'utilisateur admin, pour utiliser les commandes root, utilisez `sudo` devant votre commande ou passer root en utilisant `sudo su`.

 

Firewall : Filtrez le trafic

Sur votre serveur, plusieurs services sont en cours d'exécution et certains sont à l'écoute sur des ports ouverts ce qui peut présenter un risque de piratage si le logiciel derrière le port ouvert contient une faille. Il est important de configurer un firewall qui bloquera les ports sauf ceux dont nous avons besoin et dont le logiciel qui lui est affecté est sérieux et réputé pour être sécurisé.

 

1 : Stopper les services inutiles

Certains services sont parfois installés et activés par défaut et dont nous nous servirons pas, il est donc fortement recommandé de les désactiver et les désinstaller. Vous gagnerez ainsi en sécurité et en performance globale.

Ces services sont très souvent inutiles :


C'est parti ! On désactive, on modifie les services lancés au démarrage et on supprime :

/etc/init.d/portmap stop
/etc/init.d/nfs-common stop

update-rc.d -f portmap remove
update-rc.d -f nfs-common remove
update-rc.d -f inetd remove

apt-get remove portmap
apt-get remove ppp

 

2 : Installer et configurer le Firewall

Nous allons utiliser iptables :

apt install iptables

Nous allons définir les règles de blocages dans un fichier afin de pouvoir les relancer quand on le souhaite (après l'installation d'un logiciel, au démarrage, etc ...) :

nano /etc/init.d/firewall

Placez-y le contenu suivant (commentez ou décommentez en fonction des ports que vous souhaitez ouvrir) :

#!/bin/sh 

### BEGIN INIT INFO
# Provides: firewall
# Required-Start: $remote_fs $syslog
# Required-Stop: $remote_fs $syslog
# Default-Start: 2 3 4 5
# Default-Stop: 0 1 6
# Short-Description: Démarre les règles iptables
# Description: Charge la configuration du pare-feu iptables
### END INIT INFO

# Réinitialise les règles
iptables -t filter -F 
iptables -t filter -X 
 
# Bloque tout le trafic
iptables -t filter -P INPUT DROP 
iptables -t filter -P FORWARD DROP 
iptables -t filter -P OUTPUT DROP 
 
# Autorise les connexions déjà établies et localhost
iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT 
iptables -A OUTPUT -m state --state RELATED,ESTABLISHED -j ACCEPT 
iptables -t filter -A INPUT -i lo -j ACCEPT 
iptables -t filter -A OUTPUT -o lo -j ACCEPT 
 
# ICMP (Ping)
iptables -t filter -A INPUT -p icmp -j ACCEPT 
iptables -t filter -A OUTPUT -p icmp -j ACCEPT 
 
# SSH
iptables -t filter -A INPUT -p tcp --dport 22 -j ACCEPT    # Attention, si vous avez changé le port SSH dans le fichier /etc/ssh/sshd_config, indiquez le à la place de 22 
iptables -t filter -A OUTPUT -p tcp --dport 22 -j ACCEPT 
 
# DNS
iptables -t filter -A OUTPUT -p tcp --dport 53 -j ACCEPT 
iptables -t filter -A OUTPUT -p udp --dport 53 -j ACCEPT 
iptables -t filter -A INPUT -p tcp --dport 53 -j ACCEPT 
iptables -t filter -A INPUT -p udp --dport 53 -j ACCEPT 

# NTP (horloge du serveur) 
iptables -t filter -A OUTPUT -p udp --dport 123 -j ACCEPT
 
# HTTP
iptables -t filter -A OUTPUT -p tcp --dport 80 -j ACCEPT 
iptables -t filter -A INPUT -p tcp --dport 80 -j ACCEPT 
# HTTP Caldav
iptables -t filter -A OUTPUT -p tcp --dport 8008 -j ACCEPT
iptables -t filter -A INPUT -p tcp --dport 8008 -j ACCEPT

# HTTPS
iptables -t filter -A OUTPUT -p tcp --dport 443 -j ACCEPT
iptables -t filter -A INPUT -p tcp --dport 443 -j ACCEPT
# HTTPS Caldav
iptables -t filter -A OUTPUT -p tcp --dport 8008 -j ACCEPT
iptables -t filter -A INPUT -p tcp --dport 8443 -j ACCEPT

# FTP 
iptables -t filter -A OUTPUT -p tcp --dport 20:21 -j ACCEPT 
iptables -t filter -A INPUT -p tcp --dport 20:21 -j ACCEPT 

# Mail SMTP 
iptables -t filter -A INPUT -p tcp --dport 25 -j ACCEPT 
iptables -t filter -A OUTPUT -p tcp --dport 25 -j ACCEPT 
iptables -t filter -A INPUT -p tcp --dport 587 -j ACCEPT
iptables -t filter -A OUTPUT -p tcp --dport 587 -j ACCEPT
iptables -t filter -A INPUT -p tcp --dport 465 -j ACCEPT
iptables -t filter -A OUTPUT -p tcp --dport 465 -j ACCEPT
 
# Mail POP3
iptables -t filter -A INPUT -p tcp --dport 110 -j ACCEPT
iptables -t filter -A OUTPUT -p tcp --dport 110 -j ACCEPT
iptables -t filter -A INPUT -p tcp --dport 995 -j ACCEPT 
iptables -t filter -A OUTPUT -p tcp --dport 995 -j ACCEPT 
 
# Mail IMAP
iptables -t filter -A INPUT -p tcp --dport 993 -j ACCEPT 
iptables -t filter -A OUTPUT -p tcp --dport 993 -j ACCEPT 
iptables -t filter -A INPUT -p tcp --dport 143 -j ACCEPT
iptables -t filter -A OUTPUT -p tcp --dport 143 -j ACCEPT

# Anti Flood / Deni de service / scan de port
iptables -A FORWARD -p tcp --syn -m limit --limit 1/second -j ACCEPT
iptables -A FORWARD -p udp -m limit --limit 1/second -j ACCEPT
iptables -A FORWARD -p icmp --icmp-type echo-request -m limit --limit 1/second -j ACCEPT
iptables -A FORWARD -p tcp --tcp-flags SYN,ACK,FIN,RST RST -m limit --limit 1/s -j ACCEPT

 

Il faut donner les droits d'exécution au script :

chmod +x /etc/init.d/firewall

Pour mettre en place les règles de filtrage :

/etc/init.d/firewall

Pour que ce script soit lancé au démarrage du serveur (recommandé, un oubli est vite arrivé) :

 update-rc.d firewall defaults

 

Fail2Ban : Empêcher les attaques par force brute

Fail2Ban permet de bannir les machines qui tentent de brute forcer votre serveur. Pour cela, il se base sur les logs du serveur et en fonctions de règles établies, bannit les IPs pirates.

Pour installer Fai2Ban :

apt install fail2ban

Un peu de configuration, copiez /etc/fail2ban/jail.conf vers /etc/fail2ban/jail.local puis éditez /etc/fail2ban/jail.local :

ignoreip = 127.0.0.1/8      # liste des IPs de confiance (séparé par un espace)
bantime  = 3600             # Durée du bannissement en seconde
findtime = 600              # Plage de temps de surveillance des logs
maxretry = 3                # Nombre de tentatives avant bannissement
destemail = root@localhost  # Adresse mail des notifications
sendername = Fail2Ban       # Nom du sender dans les notifications mail

[ssh]                       # Pour chaque services, définir les options
enabled  = true
port     = ssh
filter   = sshd
logpath  = /var/log/auth.log
maxretry = 3

...
...

[recidive]                  # Après plusieurs bannissements, on bannit pour plus longtemps

enabled  = true
filter   = recidive
logpath  = /var/log/fail2ban.log
action   = iptables-allports[name=recidive]
           sendmail-whois-lines[name=recidive, logpath=/var/log/fail2ban.log]
bantime  = 604800  ; 1 week
findtime = 86400   ; 1 day
maxretry = 3

Je vous laisse activer et configurer les services à bannir comme vous le souhaitez. Vous pouvez aussi ajouter vos propres règles de bannissement.

Voici un exemple pour bloquer les attaques w00tw00t sur apache :

/etc/fail2ban/jail.local

[apache-w00tw00t]
enabled = true
filter = apache-w00tw00t
action = iptables[name=Apache-w00tw00t,port=80,protocol=tcp]
logpath = /var/log/apache2/access*.log
maxretry = 1

/etc/fail2ban/filter.d/apache-w00tw00t.conf

# Fail2Ban configuration file
# Author: Rémi POIGNON

[Definition]
failregex = ^<HOST> -.*"GET \/w00tw00t\.at\.ISC\.SANS\.DFind\:\).*".*
ignoreregex =

 

Enfin on redémarre Fail2Ban :

/etc/init.d/fail2ban restart


Rkhunter : Détecter les intrusions

Rhkunter calcule les empreintes MD5 des logiciels installés sur votre serveur. Si un pirate arrivait à pénétrer votre serveur, il est fort probable qu'il ajoute une backdoor afin de pouvoir revenir facilement par la suite. Rkhunter détecte donc ces backdoors et vous avertit. Souvent, Rkhunter vous alerte pour des faux positifs.

Pour installer Rkhunter :

 apt install rkhunter

Puis on édite la configuration /etc/default/rkhunter :

CRON_DAILY_RUN="yes"   # Pour effectuer une vérification chaque jour (lancer rkhunter --checkall si vous souhaitez le lancer manuellement après une attaque par exemple)
REPORT_EMAIL="votre@email.com"

Pour éviter un maximum de faux positifs, on va éditer le fichier /etc/rkhunter.conf, voici mes modifications par rapport à la configuration de base, adaptez le fichier à vos besoins :

DISABLE_TESTS="suspscan hidden_procs deleted_files packet_cap_apps apps os_specific"

SCRIPTWHITELIST="/usr/bin/unhide.rb"

ALLOWHIDDENDIR="/etc/.java"
ALLOWHIDDENDIR="/dev/.static"
ALLOWHIDDENDIR="/dev/.udev"

ALLOWDEVFILE="/dev/.udev/rules.d/root.rules"

Rkhunter va parfois vous avertir de modifications sur un logiciel alors que vous en êtes à l'origine, dans ce cas, il faut mettre la base d'empreintes à jour avec la commande :

rkhunter --propupd

 

Logwatch : Surveillez l'activité de votre serveur

Logwatch est un utilitaire qui analyse vos logs du serveur pour vous faire un récapitulatif tout les jours sous forme de mail. Il est important de suivre les logs de votre serveur pour détecter les anomalies. Logwatch va par exemple vous faire un récapitulatif des mails sortants de votre serveur. Vous pouvez ainsi voir si votre serveur ne sert pas de passerelle pour le spam. Il va vous indiquer les attaques bloquées par fail2ban, etc ...

Pour l'installer :

apt install logwatch

Pour la configuration, copiez /usr/share/logwatch/default.conf/logwatch.conf vers /etc/logwatch/conf/logwatch.conf et modifiez :

Format = html              # Pour recevoir les mails au format html, c'est plus agréable à lire
MailTo = votre@email.com   # Adresse sur laquelle recevoir les mails
Detail = Med               # Niveau de détail des logs
#TmpDir = /var/cache/logwatch # On commente pour utiliser le repertoire /tmp 

Pour générer le rapport quand vous le souhaitez :

logwatch --mailto votre@email.com

 

Sécurité avancée

A ce stade, votre serveur est bien protégé. Il est toujours possible de protéger plus son serveur, mais plus l'on protège plus on ajoute de contraintes en général. Sachez que la protection ultime n'existe pas, du moment que la machine est connectée à internet, la moindre faille peut-être exploitée de façon plus ou moins ingénieuse par un pirate.

 

Analyseur de trafic en temps réel

Les deux logiciels suivants analysent le trafic en temps réel pour empêcher les attaques. Ils se lancent donc à chaque requête vers le serveur pour détecter les attaques et consomment donc des ressources, ce qui ralentit les échanges. Dans le cas d'un serveur d'hébergement web, ce n'est pas très pertinent si vous souhaitez des sites qui répondent du tac au tac. Après c'est vous qui voyez en fonction de votre besoin en sécurité. Je ne vais pas m'attarder dessus dans cet article.

  • Portsentry : Détection des scans de ports très puissant. Pour l'utiliser c'est ici.
  • Snort : Système de détection d'intrusion. Pour l'utiliser c'est ici.

 

Avertir dès qu'une connexion à lieu

Une autre chose très simple que vous pouvez mettre en place est une alerte mail dès qu'une authentification a lieu sur votre serveur. Editez le fichier .bashrc de l'utilisateur à protéger (dans le homedir) et ajoutez :

echo "Objet : Login with ssh.
Server : `hostname`
Date : `date`
`who` " | mail -s "`hostname` ssh login from : `who | cut -d"(" -f2 | cut -d")" -f1`" votre@email.com

Cette méthode est plutôt contraignante car normalement, tous les mails reçus sont des faux positifs ...

 

Ajoutez des restrictions sur l'ip

Cette méthode est très efficace, car seul l'ip de votre choix peut communiquer avec le serveur sur le protocole choisi. Par contre, les offres d'accès internet permettent rarement d'avoir une ip fixe et on ne peut plus accéder à son serveur de n'importe où.

Il existe plusieurs méthodes pour restreindre par IPs. Je vous présente celle qui utilise le firewall. Si vous avez suivi ce tuto depuis le début, nous avons créé un fichier /etc/init.d/firewall.

Il nous suffit de rajouter les options `-s 100:100:100:100, 101:101:101:101` sur les protocoles à restreindre (avec vos IPs bien sûr ...).

Exemple pour restreindre le protocole SSH sur mon ip seulement :

iptables -t filter -A INPUT -p tcp --dport 22 -s 100:100:100:100 -j ACCEPT

Vous pouvez faire de même sur les autres ports. Pensez à le faire sur les lignes INPUT, vous voulez bloquer le trafic entrant vers le serveur, il est plutôt inutile de bloquer le trafic sortant ...

 

Authentification ssh par clé privée

L'authentification par clé privée augmente considérablement la difficulté de brute forcer le serveur en SSH. Il faut à la fois un fichier et une clé pour décrypter ce fichier avant de pouvoir se connecter au serveur.

Une fois la clé publique insérée sur le serveur, éditez le fichier /etc/ssh/sshd_config :

RSAAuthentication yes
PubkeyAuthentication yes     # Autoriser l'authentification par clé privée
PasswordAuthentication no    # Bloquer l'authentification avec mot de passe simple

Puis relancer le service ssh :

service ssh restart

Contrainte : Devoir ajouter votre clé privée à chaque démarrage de session de votre poste (commande `ssh-add` pour Linux ou putty pageant pour Windows).

 

Le mot de la fin

La sécurité d'un serveur est un sujet délicat, plus vous avez de services qui tournent sur le serveur, plus le nombre de failles potentielles est important. Je vous recommande de diviser vos fonctionnalités pour mieux régner, séparez vos services (mails, hébergement, cloud, etc ...) sur des serveurs différents. Si l'un des services tombe, les autres subsistent et c'est l'un des avantages des serveurs virtuels.

Autre chose, plus vous avez d'utilisateurs sur un serveur, plus le risque de mot de passe "dans la nature" est grand. Les utilisateurs "légaux" de votre serveur sont la plupart du temps les éléments déclencheurs de problèmes sur le serveur. Pensez donc à attribuer le strict minimum de droits à vos utilisateurs sur le serveur et formez-les. Mettez en place des restrictions (exemple : maximum d'envois de mails par heure par utilisateur pour éviter que l'utilisateur puisse servir de relais spam en étant piraté). Obligez vos utilisateurs à utiliser des mots de passe complexes.

Mettez à jour vos logiciels le plus souvent possibles ! (`apt-get update` puis `apt-get upgrade`).

Tenez-vous informé sur les logiciels que vous utilisez pour être au courant des dernières failles, abandon de projet, etc ...

Forcez l'utilisation de protocoles sécurisés utilisant le cryptage SSL (ssh, https, imaps, smtps, etc ...)

Tentez de vous piratez vous même, cherchez les failles dans votre système.

 

Commentaires

Lolo
04 Septembre 2017 19:41

Merci pour ce super tuto !

les commandes suivantes ne marchent pas chez moi.. (Ubuntu 16.04.03)
iptables -t filter -A INPUT -i lo -j ACCEPT
iptables -t filter -A OUTPUT -o lo -j ACCEPT

j'ai remplacé par :
iptables -t filter -A INPUT -s 127.0.0.1 -j ACCEPT
iptables -t filter -A OUTPUT -d 127.0.0.1 -j ACCEPT

Rémi POIGNON admin
15 Juin 2017 11:18

@Seriously, c'est corrigé pour le port ssh, merci. Que veux-tu dire par "le drop all à la fin" ?

Seriously
18 Mai 2017 20:43

Tu répètes deux fois le "port", cela va créer une anomalie / conflit dans le fail2ban pour les personnes qui ont changées le port dans le sshd_config .

[ssh] # Pour chaque services, définir les options
enabled = true
port = ssh
filter = sshd
logpath = /var/log/auth.log
port = 22 # Ou votre numéro de port SSH
maxretry = 3

Il faudrait penser à revoir les choses avant de les diffuser !

Seriously
18 Mai 2017 20:38

Il faudrait peut être mettre le drop all à la fin !
Sinon ça bloque tout le système.

AdminSys
25 Janvier 2017 12:48

Très bon article ! Vraiment complet et instructif :)
Dans les services et packages à enlever, j'ajouterai seulement ftp, rlogin, rcp et telnet, qui ne sont pas cryptés

Jérémy-F
26 Décembre 2016 12:02

Salut salut :)

Un grand merci pour ce tuto, c'est vraiment simple à faire, et ca ne peut être que mieux que aucune sécurité.
Par contre impossible de comprendre comment faire pour donner les autorisations nécessaire au niveau de iptables pour que OpenVPN (serveur) puisse fonctionner correctement...

Cordialement ;)

NuX_O
14 Juillet 2016 23:02

dsl le 2eme lien pour comprendre la démarche: (http://www.kitpages.fr/fr/cms/193/installer-un-sftp-avec-chroot-sur-debian), voir 1er lien (dans message précédent) avec méthode fonctionnel pour le SFTP.

bon courage ! :)

NuX_O
14 Juillet 2016 23:00

Bonjour,

@Plka :

Pourquoi utiliser FTP si nativement le SSH gère le SFTP ? (FTP via tunnel chiffré)
Le SFTP ne nécessite pas forcément de logiciel FTP (un paquet logiciel en moins à installer et un port d'écoute connu [20 21] en moins à ouvrir.)

En sommes le SFTP passe par le même port que SSH... en plus, on peut chrooter les utilisateurs.

https://askubuntu.com/questions/134425/how-can-i-chroot-sftp-only-ssh-users-into-their-homes/134442#134442
et ce lien (pas la peine d'utiliser le script) pour comprendre l'ensemble, le 1er lien donné devrait suffire :)

Rémi POIGNON admin
05 Juillet 2016 09:14

Je suis pas expert en FTP mais je crois que c'est le client FTP qui fait le choix du mode actif ou passif. En mode passif, ça ne peut pas marcher avec le firewall tel qu'il est configuré mais en mode actif, en ouvrant le port 20 et 21, le ftp devrait fonctionner.
Regardez au niveau de la conf du client FTP je pense.
Sinon vérifiez avec nmap que les ports souhaités soient bien ouverts sur le serveur.

PIka
05 Juillet 2016 03:37

Une idée alors ? :/

PIka
01 Juillet 2016 22:21

J'ai fais un copier coller du fichier firewall en changeant le port ssh

Rémi POIGNON admin
01 Juillet 2016 16:45

#PIka, vous pouvez utiliser directement jail.conf mais fail2ban vérifie s'il existe un fichier jail.local avant d'utiliser le jail.conf. Ça permet de garder une configuration d'origine propre et de bidouiller dans le jail.local.

Pour le FTP, avez vous ouvert le port 21 dans le fichier firewall ?

iptables -t filter -A OUTPUT -p tcp --dport 21 -j ACCEPT
iptables -t filter -A INPUT -p tcp --dport 21 -j ACCEPT

PIka
01 Juillet 2016 16:35

Bonjour,

Quand je met la configuration firewall, mon ftp passe en mode passive. Une solution pour qu'il reste en active ou remédier à que je puisse me connecter ? :)

Merci

PIka
01 Juillet 2016 15:24

Un peu de configuration, copiez /etc/fail2ban/jail.conf vers /etc/fail2ban/jail.local puis éditez /etc/fail2ban/jail.local :

Pas plutôt jail.conf à éditer ?

GREG
23 Juin 2016 08:44

Bonjour et bravo pour ce tuto.
J'ai réussi à me logger en admin sur mon serveur via le terminal.
Je tente de passer en root avec la commande su ou sudo
on m'invite à entrer le mot de passe mais ensuite ça bloque : Permission denied, please try again.
Qu'est ce qui n'a pas fonctionné ?

Rémi POIGNON admin
08 Juin 2016 12:15

@MG merci pour l'info, j'ai mis à jour la configuration du firewall

divix
05 Février 2016 18:56

super tuto!

tu regroupes l'essentiel sur 1 page....

à quand la même chose pour snort :)

MG
22 Novembre 2015 14:21

Sur Debian 8, les règles du firewall déclenchent une erreur "
insserv: warning: script 'firewall' missing LSB tags and overrides"

Il faut simplement ajouter ça après /bin/sh


### BEGIN INIT INFO
# Provides: firewall
# Required-Start: $remote_fs $syslog
# Required-Stop: $remote_fs $syslog
# Default-Start: 2 3 4 5
# Default-Stop: 0 1 6
# Short-Description: Démarre les règles iptables
# Description: Charge la configuration du pare-feu iptables
### END INIT INFO

MG
21 Mai 2015 13:16

@Rémi Merci pour tes précisions. Je chercher surtout à me proteger des bots.
Je rajoute une note pour moi même lorsque je configurerai mon prochain serveur :
Concernant fail2Ban, une bonne solution est de de choisir un grand 'findtime' et un très grand 'bantime' : 3600 et 86400, ou encore 86400 et 604800. (source: doc Ubuntu)

Rémi POIGNON admin
20 Mai 2015 14:26

@MG, je ne conseille pas de configuration type pour un serveur de prod. Je pense que le firewall doit être adapté en fonction de tes besoins.
Par exemple, si ton serveur sert uniquement de serveur mail, alors il est inutile et potentiellement dangereux de garder le port 80 ouvert (ainsi que le 8008, 443, 21, etc ...).
La logique est donc de fermer tous les ports puis d'ouvrir un à un les ports dont tu as besoin.

Merci pour ta remarque concernant le port du SSH.
En réalité, modifier le port du SSH n'apporte pas beaucoup plus en sécurité. Il te permettra certes d'éviter que de nombreux robots essayent de te brute-forcer, car ils sont en général paramétrés sur le port 22, mais fail2ban est là pour les calmer. En plus, le port que tu auras spécifié à la place du port 22 ne sera pas invisible aux yeux des pirates. Un simple scanner de port le dévoilera. Et puis c'est assez contraignant ensuite pour se connecter à ton serveur : il ne faut pas oublier de spécifier le port dès que tu veux te connecter.

Pour une meilleure sécurité sur le protocole SSH, je conseille de n'autoriser le port 22 seulement depuis ton IP (si tu as la chance d'avoir une IP fixe). (cf "Ajoutez des restrictions sur l'ip"). Là, le gain en sécurité est plus intéressant, mais tu ne pourras te connecter que depuis ton IP ce qui est contraignant aussi.

Il faut trouver la limite entre la sécurité maximale qui est très contraignante et la sécurité minimale qui laisse tout passer ...

MG
18 Mai 2015 23:12

Super tuto !
Attention, dans le firewall à bien mettre le port du SSH si jamais on l'a changé comme tu l'as préconisé au début.
Ce firewall est celui que tu conseilles pour un serveur de prod ?

max
09 Mai 2015 23:03

Excellent tuto ... et de très bonnes thématiques d'article.

Un tout grand merci !

Snor
30 Mars 2015 01:11

Très bon tuto et qui regroupe pas mal d'outils pour sécuriser correctement son serveur! Bonne continuation