Sécuriser son serveur/VPS
Contents
Sécuriser son serveur Linux[edit]
8 février 2015 Mis à jour le 4 avril 2019
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 un VPS hébergé chez OVH sur lequel j’ai installé Debian 9.
Sécurisations indispensables du serveur[edit]
1 – Modifie ton mot de passe root ![edit]
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.
Keepass 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 root
2 – Root c’est fini, bonjour admin[edit]
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 rp
On installe le paquet sudo pour permettre à certains utilisateurs autorisés de prendre les droits root :
apt install sudo
Puis 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 rp
On 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 restart
On 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 su
Combien 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 : c’est toi qui décide par où ça rentre[edit]
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 iptables
On 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/firewall
Attention ! 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 start
Si 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 defaults
Si tu changes d’avis, tu peux le retirer avec la commande :
sudo update-rc.d -f firewall remove
4 – Fail2Ban douane du trafic entrant[edit]
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 fail2ban
Cré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 restart
Puis on vérifie que les prisons sont bien en service :
sudo fail2ban-client status
5 – Toujours à jour avec cron-apt[edit]
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-apt
On 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.list
Un 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[edit]
1 – Rkhunter : Détecter les intrusions[edit]
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 rkhunter
Puis 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 --propupd
2 – Logwatch : Surveillez l’activité de votre serveur[edit]
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 logwatch
On 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 html
3 – Analyser de trafic en temps réel[edit]
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[edit]
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[edit]
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ù.
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 :
sudo /etc/init.d/firewall
6 – Authentification SSH par clé privée[edit]
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 restart
Attention ! 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[edit]
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 de 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 (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é.
Comment (27)[edit]
MG| 18 mai 2015[edit]
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épondre
Rémi 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 …
Répondre
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)
Répondre
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
GREG| 23 juin 2016[edit]
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[edit]
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[edit]
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 ? 🙂
Rémi 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
Répondre
Avatar
PIka| 1 juillet 2016
J’ai fais un copier coller du fichier firewall en changeant le port ssh
Répondre
Avatar
PIka| 5 juillet 2016
Une idée alors ? :/
Répondre
Rémi
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.
Répondre
Avatar
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 🙂
Répondre
Avatar
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 ! 🙂
Répondre
Jérémy-F| 26 décembre 2016[edit]
Par contre impossible de comprendre comment faire pour donner les autorisations nécessaire au niveau de iptables pour que OpenVPN (serveur) puisse fonctionner correctement…
AdminSys| 25 janvier 2017[edit]
Dans les services et packages à enlever, j’ajouterai seulement ftp, rlogin, rcp et telnet, qui ne sont pas cryptés
Seriously| 18 mai 2017[edit]
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 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[edit]
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
cdarsac| 31 juillet 2019[edit]
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
ahalled8ellanaripple
________________________________________________________
Authentification ssh par clé privée[edit]
Suite à un précédent article concernant la sécurisation d’un serveur linux, j’étais resté vague sur la mise en place de l’authentification ssh par clé privée.
L’authentification par clé privée augmente la sécurité d’un serveur au niveau du processus de connexion. Au lieu d’un simple couple identifiant / mot de passe, il faut désormais être en possession de deux informations secrètes à la fois :
- une clé privée (un fichier que vous conservez précieusement et surtout secrètement)
- un mot de passe (pour décrypter la clé, et ainsi pouvoir l’utiliser)
Génération des clés[edit]
Pour mettre en place ce type d’authentification, il va falloir générer 2 clés : La clé privée et la clé publique.
La clé publique n’a pas besoin d’être secrète. C’est une clé qui est capable de reconnaître sa clé privée (cryptographie asymétrique). Cette clé sera donc placée sur le serveur afin qu’elle puisse vérifier notre clé privée lorsque nous voudrons nous connecter.
Sous linux[edit]
Générons notre paire de clé :
ssh-keygen -t rsa -b 4096 -C votre@email.com
Ici on génère une clé RSA de 4096 bits avec en commentaire votre adresse mail (juste afin de s’y retrouver si vous avez plusieurs clés à générer)
Par défaut ssh-keygen génère une clé RSA de 2048 bits avec en commentaire : votre@email.com
A vous de voir si vous préférez utiliser un algorithme RSA ou DSA. Il n’y a pas de plus ou moins costaud mais DSA est plus récent.
Pour la taille de la clé, il est recommandé de faire au moins du 2048 bits pour le RSA. En DSA, la clé fait obligatoirement 1024 bits.
Vos deux clés sont générées par défaut dans : ~/.ssh/
Vous y retrouvez vos deux clés :
id_rsa.pub : La clé publique id_rsa : La clé privée
Sous windows[edit]
Utilisez la suite putty et générez vos clés avec PuTTYgen.
Mise en place de la clé publique sur le serveur[edit]
Il faut maintenant envoyer la clé publique sur le serveur et la placer dans le fichier ~/.ssh/authorized_keys. Ce fichier est utilisé lors de l’authentification pour déterminer si la clé privée de l’utilisateur est conforme à la clé publique inscrite dans le fichier.
Envoi de la clé si le serveur autorise l’authentification par mot de passe (sous client linux)
Nous allons utiliser ssh-copy-id qui permet d’envoyer notre clé publique automatiqument dans le fichier ~/.ssh/authorized_keys en remettant les bons droits d’écriture sur le fichier.
ssh-copy-id -i ~/.ssh/id_rsa.pub <username>@<ipaddress>
Si le port SSH n’est pas sur le port standard (22) :
ssh-copy-id -i ~/.ssh/id_rsa.pub -p <num_port> <username>@<ipaddress>
Autre méthode[edit]
Copiez le contenu de votre clé publique dans ~/.ssh/authorized_keys sur le serveur.
Configuration sur le serveur[edit]
Côté serveur, nous allons maintenant indiquer à ssh que nous souhaitons permettre la connexion par clés.
/etc/ssh/sshd_config :
RSAAuthentication yes PubkeyAuthentication yes StrictModes yes
Avec StrictMode = yes, donnez les bons droits à votre homedir sinon l’authentification risque d’échouer :
chmod go-w ~/ chmod 700 ~/.ssh chmod 600 ~/.ssh/authorized_keys
Gardons pour le moment la possibilité de nous connecter avec un mot de passe au cas où. Nous verrons pas la suite comment n’autoriser que l’authentification par clé.
Recharger le serveur ssh :
service sshd reload
Connexion avec votre clé privée[edit]
Sous linux[edit]
Modifiez ou créez le fichier ~/.ssh/config et adaptez le avec l’exemple ci-dessous :
~/.ssh/config
Host serveur1
HostName serveur1.domain.tld
User remi
Port 22
IdentityFile /home/remi/.ssh/id_rsa
Host serveur2
HostName 192.168.1.120
User remi
Port 22
IdentityFile /home/remi/autre_cle/private_key
HostName : Adresse ip ou nom de domaine du serveur
User : Utilisateur à utiliser en login
Port : Numéro du port à utiliser
IdentifyFile : Chemin vers votre clé privée à utiliser
Maintenant connectez-vous au serveur :
ssh serveur1
Indiquez votre passphrase.
Si tout va bien vous êtes maintenant connecté au serveur.
Vous pouvez ajouter votre clé privée dans votre agent ssh pour éviter de devoir taper votre passphrase à chaque fois (il faudra quand même le refaire à chaque ouverture de session) :
ssh-add ~/.ssh/id_rsa
Indiquez votre passphrase pour dévérouiller la clé.
Maintenant connectez-vous au serveur :
ssh serveur1
La passphrase ne vous est pas demandée et vous êtes connecté.
Il est possible aussi de se connecter directement sans passer par le fichier de config :
ssh <username>@<ipaddress>
Sous windows[edit]
Utilisez la suite putty et ajoutez votre clé publique sur Pagent. Désactiver l’authentification par mot de passe
Attention ! Soyez sûr que votre accès par clé privée est bien opérationnel sinon vous perdrez tout accès ssh à votre machine !
Seul les authentifications par clé seront possibles !
Modifiez la configuration du fichier /etc/ssh/sshd_config :
/etc/ssh/sshd_config
ChallengeResponseAuthentication no PasswordAuthentication no
Puis redémarrez le serveur ssh :
service sshd reload
Terminé !
