Sécuriser son serveur Linux
La sécurité d’un serveur n’est pas à prendre à la légère. Chaque jour qui passe, de nombreux robots ou humains chercheront à pénétrer ton serveur. Pour tout casser, pour utiliser tes ressources, pour l’honneur, etc …
Bon, en général, d’après mon expérience personnelle, la plupart des attaques sont des attaques de force brute en SSH totalement stupides qui essaye du mot de passe en brute force pour différent utilisateurs communs (root, admin, administrator, …). Il est extrêmement rare d’être la cible d’une attaque réfléchie. Sauf bien sûr si tu héberge un site ou un service très connu. Mais en bon admin serveur, tu dois garder le contrôle de ton serveur ! On va voir comment faire pour attendre un bon niveau de sécurité.
Commençons par le commencement, tu viens de recevoir ton nouveau VPS (serveur privé virtuel) ou ton nouveau serveur dédié.
Sur ce tuto, j’utilise Debian 10.
Sécurisations indispensables du serveur
1 – Modifie ton mot de passe root !
Pour la gestion de tes mots de passe, je te conseille l’utilisation d’un gestionnaire de mot de passe. Tu pourra alors stocker des mots de passe complexes et différents. Il te suffira simplement de connaître un mot de passe pour déverrouiller les autres. KeepassXC est gratuit et multi-plateforme, il encrypte vos mots de passe avec l’algo AES avec SHA-256, il permet d’utiliser une clé privée. Bref, je te le recommande, un bon admin système ne met jamais les même mots de passe sur ses serveurs !
Première chose à faire, si comme moi tu as reçu ton mot de passe root par mail, considère le comme potentiellement intercepté. (Comme pour tout tes mots de passe que tu reçois par mail d’ailleurs). Ton mot de passe root ne doit être connu que par toi et n’être accessible par personne d’autre, alors on le change tout de suite. Connectes toi en SSH sur ton serveur et change ton mot de passe avec la commande :
passwd root2 – Root c’est fini, bonjour admin
Comme je l’ai dis, la plupart des attaques sont des attaques où des robots vont tenter de se connecter en SSH sur ton 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 ton choix qui aura les privilèges root.
Commences par ajouter un utilisateur, ici, je l’appelle « rp » parce que c’est mes initiales mais ne sois pas benêt et mets les tiennes à la place 😉 :
adduser rpOn installe le paquet sudo pour permettre à certains utilisateurs autorisés de prendre les droits root :
apt install sudoPuis on ajoute l’utilisateur aux groupes lui permettant d’avoir les privilèges root (j’ai rajouté le groupe adm pour pouvoir consulter les logs sans devoir utiliser sudo) :
usermod -aG root,sudo,adm rpOn modifie maintenant la configuration SSH pour interdire la connexion en tant que root. Tu peux aussi modifier ton port de connexion SSH si tu le souhaite, ça t’évitera 99.99% des attaques par brute force mais c’est un peu pénible pour la suite de devoir toujours indiquer ton numéro de port …
/etc/ssh/sshd_config
... # Interdire à root de se connecter en SSH PermitRootLogin no # Facultatif : Modifier le port de connexion pour le SSH Port 4854 # Facultatif : Seul admin peux se connecter en SSH AllowUsers rp # Facultatif : Seul les utilisateurs du groupe sshusers peuvent se connecter en SSH AllowGroups sshusers ...
Attention ! Avant de redémarrer ton service SSH, avec une mauvaise configuration, tu risques de perdre complètement l’accès à ton serveur ! Penses à garder ta session ssh root active le temps de vérifier que tout va bien et que tu dispose bien des privilèges root avec le nouvel utilisateur.
On redémarre le service SSH :
service ssh restartOn se connecte en SSH avec le nouvel utilisateur et on test que la commande sudo fonctionne bien :
sudo ls -l ./Si ça ne fonctionne pas, ne quittes surtout par ta session root et fais ce qu’il faut pour que ça marche.
Le principe de sudo est simple, tout ce que tu exécutes en utilisant le préfixe sudo va exécuter la commande avec les droits root. Tu peux même prendre la main sur l’utilisateur root avec la commande (mais à éviter) :
sudo suCombien d’admin système qui ne respecte pas cette bonne pratique se retrouve connecté au serveur en root, puis lors d’une pause café, laisse parfois leur session connecté sans surveillance ? Déjà s’il te plaît, verrouilles toujours ta session quand tu laisse ton abandonne ton poste. Sudo apporte une sécurité supplémentaire, il faut confirmer ton mot de passe pour exécuter une commande root.
3 – Un firewall strict = maîtrise des portes d’entrées / sorties
Sur ton 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 si le logiciel derrière le port ouvert contient une faille. Il est important de configurer un firewall qui bloquera tous les ports sauf ceux dont nous avons besoin et dont le logiciel qui l’utilise est sérieux, réputé pour être sécurisé et dont on a confiance.
Aller hop ! On installe l’incontournable paquet iptable :
sudo apt install iptablesOn définit les règles du firewall, en fonction des services que tu utilises, commentes, dé-commentes ou ajoute des lignes :
/etc/init.d/firewall
#! /bin/sh
### BEGIN INIT INFO
# Provides: PersonalFirewall
# Required-Start: $remote_fs $syslog
# Required-Stop: $remote_fs $syslog
# Default-Start: 2 3 4 5
# Default-Stop: 0 1 6
# Short-Description: Personal Firewall
# Description: Init the firewall rules
### END INIT INFO
# programme iptables IPV4 et IPV6
IPT=/sbin/iptables
IP6T=/sbin/ip6tables
# Les IPs
#IP_TRUSTED=xx.xx.xx.xx
do_start() {
# Efface toutes les regles en cours. -F toutes. -X utilisateurs
$IPT -t filter -F
$IPT -t filter -X
$IPT -t nat -F
$IPT -t nat -X
$IPT -t mangle -F
$IPT -t mangle -X
$IP6T -t filter -F
$IP6T -t filter -X
$IP6T -t mangle -F
$IP6T -t mangle -X
# strategie (-P) par defaut : bloc tout l'entrant le forward et autorise le sortant
$IPT -t filter -P INPUT DROP
$IPT -t filter -P FORWARD DROP
$IPT -t filter -P OUTPUT ACCEPT
$IP6T -t filter -P INPUT DROP
$IP6T -t filter -P FORWARD DROP
$IP6T -t filter -P OUTPUT ACCEPT
# Loopback
$IPT -t filter -A INPUT -i lo -j ACCEPT
$IPT -t filter -A OUTPUT -o lo -j ACCEPT
$IP6T -t filter -A INPUT -i lo -j ACCEPT
$IP6T -t filter -A OUTPUT -o lo -j ACCEPT
# Permettre a une connexion ouverte de recevoir du trafic en entree
$IPT -t filter -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
$IP6T -t filter -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
# ICMP
$IPT -t filter -A INPUT -p icmp -j ACCEPT
# DNS:53
$IPT -t filter -A INPUT -p tcp --dport 53 -j ACCEPT
$IPT -t filter -A INPUT -p udp --dport 53 -j ACCEPT
$IP6T -t filter -A INPUT -p tcp --dport 53 -j ACCEPT
$IP6T -t filter -A INPUT -p udp --dport 53 -j ACCEPT
# SSH:22
# ATTENTION, indiques bien ton port personnalisé si tu l'as changé
$IPT -t filter -A INPUT -p tcp --dport 22 -j ACCEPT
$IP6T -t filter -A INPUT -p tcp --dport 22 -j ACCEPT
# HTTP:80
$IPT -t filter -A INPUT -p tcp --dport 80 -j ACCEPT
$IP6T -t filter -A INPUT -p tcp --dport 80 -j ACCEPT
# HTTPS:443
$IPT -t filter -A INPUT -p tcp --dport 443 -j ACCEPT
$IP6T -t filter -A INPUT -p tcp --dport 443 -j ACCEPT
# SMTP:25/587/465
$IPT -t filter -A INPUT -p tcp --dport 25 -j ACCEPT
$IP6T -t filter -A INPUT -p tcp --dport 25 -j ACCEPT
$IPT -t filter -A INPUT -p tcp --dport 587 -j ACCEPT
$IP6T -t filter -A INPUT -p tcp --dport 587 -j ACCEPT
# $IPT -t filter -A INPUT -p tcp --dport 465 -j ACCEPT
# $IP6T -t filter -A INPUT -p tcp --dport 465 -j ACCEPT
# POP3:110/995
# $IPT -t filter -A INPUT -p tcp --dport 110 -j ACCEPT
# $IP6T -t filter -A INPUT -p tcp --dport 110 -j ACCEPT
# $IPT -t filter -A INPUT -p tcp --dport 995 -j ACCEPT
# $IP6T -t filter -A INPUT -p tcp --dport 995 -j ACCEPT
# IMAP / SIEVE : 143/993/4190
# $IPT -t filter -A INPUT -p tcp --dport 143 -j ACCEPT
# $IP6T -t filter -A INPUT -p tcp --dport 143 -j ACCEPT
$IPT -t filter -A INPUT -p tcp --dport 993 -j ACCEPT
$IP6T -t filter -A INPUT -p tcp --dport 993 -j ACCEPT
$IPT -t filter -A INPUT -p tcp --dport 4190 -j ACCEPT
$IP6T -t filter -A INPUT -p tcp --dport 4190 -j ACCEPT
# accepte tout d'une ip en TCP
# $IPT -t filter -A INPUT -p tcp -s $IP_TRUSTED -j ACCEPT
echo "firewall started [OK]"
}
# fonction qui arrete le firewall
do_stop() {
# Efface toutes les regles
$IPT -t filter -F
$IPT -t filter -X
$IPT -t nat -F
$IPT -t nat -X
$IPT -t mangle -F
$IPT -t mangle -X
$IP6T -t filter -F
$IP6T -t filter -X
$IP6T -t mangle -F
$IP6T -t mangle -X
# remet la strategie
$IPT -t filter -P INPUT ACCEPT
$IPT -t filter -P OUTPUT ACCEPT
$IPT -t filter -P FORWARD ACCEPT
$IP6T -t filter -P INPUT ACCEPT
$IP6T -t filter -P OUTPUT ACCEPT
$IP6T -t filter -P FORWARD ACCEPT
#
echo "firewall stopped [OK]"
}
# fonction status firewall
do_status() {
# affiche les regles en cours
clear
echo Status IPV4
echo -----------------------------------------------
$IPT -L -n -v
echo
echo -----------------------------------------------
echo
echo status IPV6
echo -----------------------------------------------
$IP6T -L -n -v
echo
}
case "$1" in
start)
do_start
exit 0
;;
stop)
do_stop
exit 0
;;
restart)
do_stop
do_start
exit 0
;;
status)
do_status
exit 0
;;
*)
echo "Usage: /etc/init.d/firewall {start|stop|restart|status}"
exit 1
;;
esac
Il faut donner les droits d’exécution au script :
sudo chmod +x /etc/init.d/firewallAttention ! Si tu définis mal les règles, tu peux te bloquer toi même et ne plus pouvoir accéder au serveur. Je te conseille fortement d’exécuter le script puis essaye de te ré-authentifier en SSH. Si après exécution du script, tout est bloqué, tu as perdu ta session et impossible de te reconnecter, redémarre le serveur pour réinitialiser le firewall.
C’est partit ! On lance le script :
sudo /etc/init.d/firewall startSi tout va bien et que tu peux toujours te connecter en SSH, alors on peut indiquer au serveur que tu veux que le script soit exécuté au démarrage pour que jamais le firewall ne soit corrompu :
sudo update-rc.d firewall defaultsSi tu changes d’avis, tu peux le retirer avec la commande :
sudo update-rc.d -f firewall remove4 – Fail2Ban, surveillance des logs et bannissement par IP
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.
On installe le paquet fail2ban :
sudo apt install fail2banCréer le fichier de configuration des « prisons »
sudo cp /etc/fail2ban/jail.conf/etc/fail2ban/jail.local/etc/fail2ban/jail.local
... # Durée du bannissement en seconde bantime = 600 # Plage de temps de surveillance des logs findtime = 600 # Nombre de tentatives avant bannissement maxretry = 3 # Adresse mail des notifications destemail = moi@mondomain.fr # Nom du sender dans les notifications mail sendername = Fail2ban ...
Dans ce fichier, sont configurés différents filtres [ssh], [apache-auth] … On va indiquer au serveur lesquels doivent être surveillés.
/etc/fail2ban/jail.d/custom.conf
[sshd] enabled = true [sshd-ddos] enabled = true [postfix] enabled = true [dovecot] enabled = true [sieve] enabled = true [recidive] enabled = tru
C’est un exemple, il faut indiquer les services que tu utilises toi.
Depuis une dernière version de fail2ban, pour recevoir les mails de notification, il faut indiquer votre mail dans les fichiers :
- /etc/fail2ban/action.d/sendmail-common.conf
- /etc/fail2ban/action.d/mail.conf
- /etc/fail2ban/action.d/mail-whois.conf
Je m’arrête 2 secondes sur le filtre [recidive]. Il permet de bannir plus longtemps les IPs qui ont déjà été bannie plusieurs fois. Par exemple, on va pouvoir dire à fail2ban de bannir pendant 1 an les IPs qui ont déjà été bannies 3 fois dans la journée.
Une fois que tout est configuré, on redémarre le service :
sudo service fail2ban restartPuis on vérifie que les prisons sont bien en service :
sudo fail2ban-client status5 – Toujours à jour avec cron-apt
Bon, c’est bien beau, mon serveur est sécurisé mais que se passe il le jour où une faille dans un logiciel est découverte pendant que je suis en vacance ? Un pirate aura tout son temps pour en profiter.
Un serveur fait les choses de façon automatique non ? Hé bien qu’il se mette à jour tout seul ! Aller on installe le paquet cron-apt :
sudo apt install cron-aptOn veux faire les mises à jour de sécurité uniquement, donc on créé un nouveau fichier de source :
grep security /etc/apt/sources.list > /etc/apt/security.sources.listUn peu de configuration :
/etc/cron-apt/config
APTCOMMAND=/usr/bin/apt-get OPTIONS="-o quiet=1 -o Dir::Etc::SourceList=/etc/apt/security.sources.list" MAILTO="moi@mondomain.fr" MAILON="upgrade"
On indique qu’on veut que cron-apt installe les mises à jour quand il en trouve :
/etc/cron-apt/action.d/3-download
dist-upgrade -y -o APT::Get::Show-Upgraded=true
Cron-apt se lance par défaut toute les nuits à 4h du matin, si tu veux modifier ça, c’est ici : /etc/cron.d/cron-apt
Ok, on est pas trop mal là, c’est plutôt bien sécure ! Mais nous on est des dingues, on va encore plus loin ! Il est toujours possible de protéger plus son serveur, mais plus l’on protège plus on ajoute de contraintes. 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.
Sécurité avancée
1 – Rkhunter : Détecter les intrusions
Rhkunter calcule les empreintes MD5 des logiciels installés sur ton serveur. Si un pirate arrivait à pénétrer ton 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 t’avertis.
On installe le paquet rkhunter :
sudo apt install rkhunterPuis on édite la configuration :
/etc/default/rkhunter
# Pour effectuer une vérification chaque jour CRON_DAILY_RUN="yes" REPORT_EMAIL="moi@mondomaine.fr"
Rkhunter va parfois t’avertir de modifications sur un logiciel alors que tu en es à l’origine (suite à une mise à jour par exemple), dans ce cas, il faut mettre la base d’empreintes à jour avec la commande :
sudo rkhunter --propupd2 – Logwatch : Surveillez l’activité de votre serveur
Logwatch est un utilitaire qui analyse vos logs du serveur pour te faire un récapitulatif tout les jours sous forme de mail. Delà te permet de détecter les anomalies. Logwatch va par exemple te faire un récapitulatif des mails sortants de votre serveur. Tu pourras ainsi voir si ton serveur ne sert pas de passerelle pour le spam. Il va t’indiquer les attaques bloquées par fail2ban, etc …
On installe le paquet logwatch :
sudo apt install logwatchOn le configure :
sudo cp /usr/share/logwatch/default.conf/logwatch.conf /etc/logwatch/conf/logwatch.conf/etc/logwatch/conf/logwatch.conf
# Pour recevoir les mails au format html, c'est plus agréable à lire Format = html # Adresse sur laquelle recevoir les mails MailTo = moi@mondomaine.fr # Niveau de détail des logs Detail = Med
Et si tu veux recevoir un rapport là tout de suite :
sudo logwatch --mailto moi@mondomaine.fr --output html3 – Analyser 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 tu souhaites des sites qui répondent du tac au tac. Après c’est toi qui vois en fonction de tes 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.
4 – Une alarme SSH
Une autre chose très simple que tu peux mettre en place est une alerte mail dès qu’une authentification ssh a lieu sur ton serveur.
Cette méthode est plutôt contraignante car normalement, tous les mails reçus sont des faux positifs …
Édites le fichier .bashrc de l’utilisateur à protéger (dans le homedir) et ajoutes à la fin du fichier :
~/.bashrc
echo "Objet : Alerte connexion SSH.
Serveur : `hostname`
Date : `date`
`who` " | mail -s "`hostname` connexion ssh de : `who | cut -d"(" -f2 | cut -d")" -f1`" moi@mondomaine.fr
Si tu veux le mettre en place pour l’utilisateur root, le fichier est /root/.bashrc car le homedir de root est /root/
5- Restrictions par IP
Cette méthode est très efficace, car seul l’IP de ton 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 puis tu ne pourra plus accéder à ton serveur de n’importe où (sauf VPN).
Il existe plusieurs méthodes pour restreindre par IPs. Je te présente celle qui utilise le firewall. Si tu as suivi ce tuto depuis le début, nous avons créé un fichier /etc/init.d/firewall.
Il suffit de rajouter les options `-s 100:100:100:100, 101:101:101:101` sur les protocoles à restreindre (avec tes IPs bien sûr …).
Exemple pour restreindre le protocole SSH sur mon IP seulement :
/etc/init./firewall
$IPT -t filter -A INPUT -p tcp --dport 22 -s 100:100:100:100 -j ACCEPT $IP6T -t filter -A INPUT -p tcp --dport 22 -s 100:100:100:100 -j ACCEPT
Tu peux faire de même sur tous les ports que tu veux. Si tu veux le faire temporairement, par exemple pour autorisé un ami à se connecter de chez lui :
iptables -t filter -A INPUT -p tcp --dport 22 -s 100:100:100:100 -j ACCEPT ip6tables -t filter -A INPUT -p tcp --dport 22 -s 100:100:100:100 -j ACCEPT
Quand il a fini, on réinitialise, on applique la tolérance zéro !
iptables -t filter -A INPUT -p tcp --dport 22 -s 100:100:100:100 -j DROP ip6tables -t filter -A INPUT -p tcp --dport 22 -s 100:100:100:100 -j DROP
Tu peux aussi redémarrer le firewall pour lui retirer les droits (cela réinitialise toutes les règles) :
sudo /etc/init.d/firewall restart6 – 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.
J’ai fait un article expliquant la mise en place d’une authentification SSH par clé privée : c’est ici !
Une fois ta clé publique insérée sur le serveur, configure ton service SSH pour bloquer l’authentification par mot de passe simple :
/etc/ssh/sshd_config
... RSAAuthentication yes # Autoriser l'authentification par clé privée PubkeyAuthentication yes # Bloquer l'authentification avec mot de passe simple PasswordAuthentication no ...
On relance le service SSH :
sudo service ssh restartAttention ! Encore une fois, assure toi que ça marche bien en essayant de t’authentifier avec ta clé avant de fermer ta session sinon tu vas perdre accès à ton serveur …
Si tu gère plusieurs serveurs, il est plus agréable de se connecter avec la même clé privée. Ainsi, aucun mot de passe ne t’es demandé pour te connecter une fois que ta clé privée est déverrouillée. Il y a donc aussi des avantages à utiliser cette méthode. tu peux aussi permettre la connexion via clé privée et via mot de passe (au choix). Dans ce cas, tu ne gagne pas en sécurité, mais tu gagne en simplicité d’utilisation.
Le mot de la fin
La sécurité d’un serveur est un sujet délicat, plus tu as de services qui tournent sur le serveur, plus le nombre de failles potentielles est important. Je te recommande de diviser pour mieux régner, sépares tes 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 tu as d’utilisateurs sur un serveur, plus le risque de mot de passe « dans la nature » est grand. Les utilisateurs « légaux » de ton serveur sont la plupart du temps les éléments déclencheurs des problèmes. Penses donc à attribuer le strict minimum de droits à tes utilisateurs sur le serveur et formes-les. Mets en place des restrictions sur tes services (exemple : maximum d’envois de mails par heure par utilisateur pour éviter que l’utilisateur puisse servir de relais spam en étant piraté). Obliges tes utilisateurs à utiliser des mots de passe complexes.
Mets à jour tes logiciels le plus souvent possibles !
Tiens toi informé sur les logiciels que tu utilise pour être au courant des dernières failles, abandon de projet, etc …
Forces l’utilisation de protocoles sécurisés utilisant le cryptage SSL ou TLS (ssh, https, imaps, smtps, etc …)
Tentes de te pirater toi même, cherches les failles dans ton système, fais une veille sur la sécurité.
Commentaire (31)
Snor| 30 mars 2015
Très bon tuto et qui regroupe pas mal d’outils pour sécuriser correctement son serveur ! Bonne continuation
max| 9 mai 2015
Excellent tuto … et de très bonnes thématiques d’article.
Un tout grand merci !
MG| 18 mai 2015
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 ?
Rémi| 20 mai 2015
@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| 21 mai 2015
@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)
MG| 22 mai 2015
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
Rémi| 8 juin 2016
@MG merci pour l’info, j’ai mis à jour la configuration du firewall
divix| 5 février 2016
super tuto!
tu regroupes l’essentiel sur 1 page….
à quand la même chose pour snort 🙂
GREG| 23 juin 2016
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é ?
PIka| 1 juillet 2016
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 ?
Pika| 1 juillet 2016
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
Rémi| 1 juillet 2016
@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| 1 juillet 2016
J’ai fais un copier coller du fichier firewall en changeant le port ssh
PIka| 5 juillet 2016
Une idée alors ? :/
Rémi| 5 juillet 2016
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.
NuX_O| 14 juillet 2016
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 🙂
NuX_O| 14 juillet 2016
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 ! 🙂
Jérémy-F| 26 décembre 2016
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 😉
AdminSys| 25 janvier 2017
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
Seriously| 18 mai 2017
Il faudrait peut être mettre le drop all à la fin !
Sinon ça bloque tout le système.
Seriously| 18 mai 2017
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 !
Rémi| 15 juin 2017
@Seriously, c’est corrigé pour le port ssh, merci. Que veux-tu dire par « le drop all à la fin » ?
Lolo| 4 septembre 2017
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
luthor| 13 mars 2019
excellent tres bien explique
Michcorp| 2 juillet 2019
Wow, merci beaucoup. Je viens de trouver une petit perle !
(Je démarre sur Debian/Linux, ce genre de documentation est une aubaine)
Bonne continuation.
cdarsac| 31 juillet 2019
Bonjour,
Merci pour cet excellent tuto. 🙂
Me concernant, j’ai installé Logwatch mais je ne reçois pas d’email instantané après la commande:
logwatch –mailto moi@mondomaine.fr –output html
Quelqu’un peut-il me dire ce que je dois vérifier ? 🙂
Merci de vos réponses.
KOUOMEU Kevin| 23 février 2020
Excellent tuto, Merci beaucoup !!
Christophe| 1 octobre 2020
Bonjour,
Je crois qu’il manque un espace entre la source et la destination pour la copie du jail.conf :
sudo cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local
Merci pour ce tuto !
ATWOPI| 1 novembre 2020
bonjour,
merci pour cet article qui va me servir à mettre une sécurisation sur mes serveurs dédiés de chez scalway.
je conseille cette lecture
joe| 23 novembre 2020
Bonjour,
Merci pour cette article visiblement encore d’actualité !
Une question ; pour faire fonctionner les e-mail avec « mail » dans le chapitre 4 – Une alarme SSH ? Quelle est la « bonne pratique » ? Faut-il installer un serveur smtp ou simplement utiliser le serveur smtp de son hébergeur ? Dans ce dernier cas, où configurer ‘mail’ ?
Merci à vous !
Abel| 2 septembre 2024
Bonjour. La sécurisation d’un serveur virtuel univirtual ou d’un serveur dédié est une préoccupation majeure en sécurité informatique pour tout administrateur système responsable. L’article aborde de manière concise mais approfondie les défis et les meilleures pratiques pour protéger efficacement une infrastructure en ligne. En mettant en avant des solutions pratiques, comme l’utilisation d’un gestionnaire de mots de passe pour des mots de passe complexes et uniques, l’auteur souligne l’importance de prévenir les risques d’intrusion et de compromission des données sensibles.Le choix de Debian 10 comme exemple démontre l’engagement envers une distribution Linux réputée pour sa stabilité et sa sécurité. L’article insiste sur la nécessité de remplacer l’accès root par un utilisateur administratif distinct, une mesure efficace contre les attaques par force brute ciblant les utilisateurs communs comme root.En abordant la sécurité des accès SSH avec une approche proactive, l’article recommande également de bloquer l’accès direct au compte root pour renforcer la défense contre les tentatives d’intrusion automatisées. Ces mesures, combinées à une surveillance continue des journaux système et à l’utilisation d’outils comme fail2ban pour détecter et bloquer les adresses IP suspectes, contribuent à maintenir un environnement serveur sécurisé.En conclusion, cet article offre une lecture instructive et pratique pour les administrateurs soucieux de la sécurité informatique de leur infrastructure. Les conseils fournis sont essentiels pour établir une base solide de sécurité sur un serveur virtuel ou vps, assurant ainsi la protection des données et la disponibilité des services hébergés. Pour tout professionnel ou débutant dans le domaine de l’administration système, ces recommandations sont une ressource précieuse pour améliorer la sécurité et la robustesse de leur serveur virtuel univirtual.