Dans le cadre de la suite d’articles sur l’installation d’un serveur dédié Kimsufi sous Ubuntu Server 14.04 LTS, je vais aujourd’hui présenter quelques mesures de sécurité à mettre en place afin que le serveur soit un minimum protégé des attaques extérieures. Ce billet, tout comme mes autres articles n’ont pas vocation à être complets ni exhaustifs. Ainsi, je ne serai en aucun cas responsable de possibles problèmes de sécurité sur votre serveur.
- Pourquoi sécuriser un serveur ?
Une fois qu’un serveur est corrompu, l’attaquant pourra alors attaquer d’autres machines depuis le serveur, mettre à disposition du contenu illicite et bien d’autres activités illégales. Ainsi, votre responsabilité pourrait être engagée en cas de problème. Il est donc nécessaire de sécuriser le serveur.
- Créer un compte utilisateur
Une des premières choses à faire pour sécuriser le serveur est de créer un compte utilisateur. Ceci permet de travailler sur le serveur en toute sécurité, sans avoir tous les pouvoirs et donc créer des trous de sécurité par inadvertance. Pour ce faire, connectez vous au serveur via SSH et tapez la commande suivante en modifiant le nom d’utilisateur avec celui de votre choix:
|
|
root@serveur:~# useradd -m NOM_UTILISATEUR
|
Ici l’utilisateur créé disposera d’un répertoire personnel. Pour pouvoir se connecter au serveur avec cet utilisateur, il faut encore
disposer d’un moyen d’authentification. Nous pouvons soit mettre en place un
mot de passe, soit utiliser un certificat (comme nous l’avons fais à l’
installation du serveur depuis le manager de Kimsufi).
Pour mettre en place un
mot de passe, il suffit de taper la
commandesuivante
en remplaçant le nom d’utilisateur:
|
|
root@serveur:~# passwd NOM_UTILISATEUR
Entrez le nouveau mot de passe UNIX :
Retapez le nouveau mot de passe UNIX :
passwd : le mot de passe a été mis à jour avec succès
|
La commande demande de saisir un mot de passe et de le confirmer.
|
|
utilisateur@poste-travail:~$ scp maclé.pub root@IP_DU_SERVEUR:
|
N’oubliez pas les deux-points situés après l’adresse IP du serveur.
Ensuite, il est nécessaire de l’ajouter aux clés publiques valides pour l’utilisateur, sur le serveur, avec les commandes ci-dessous:
|
|
root@serveur:~# mkdir /home/NOM_UTILISATEUR/.ssh
root@serveur:~# cat maclé.pub >> /home/NOM_UTILISATEUR/.ssh/authorized_keys
root@serveur:~# chmod 600 /home/NOM_UTILISATEUR/.ssh/authorized_keys
root@serveur:~# rm maclé.pub
|
Au passage, nous supprimons le fichier contentant la clé publique sur le serveur puisque nous n’en n’avons plus besoin.
P.S. : Pour savoir sur quel compte vous êtes connecté, il suffit de regarder le prompt, c’est à dire le début de la ligne sur laquelle vous inscrivez vos commandes. Celui-ci indique le nom du compte et grâce au symbole juste avant votre commande, vous savez si vous êtes sous le compte root ou sous un simple compte utilisateur. Ainsi, en tant que simple utilisateur, vous aurez un prompt similaire à ceci:
Alors qu’en tant que root, vous aurez:
Vous remarquerez que le nom de compte change et que le prompt finit par un $ (dollar) si vous êtes connecté en tant qu’utilisateur. Il finira avec un # (dièse) si vous êtes connecté en tant que root. Ainsi, dans la suite de cet article et dans mes prochains billets, dans les exemples de commandes à taper, vous saurez qu’il faut les saisir en tant que root si le prompt finit par un # (dièse), sinon en tant qu’utilisateur normal.
Toujours pour des raisons de sécurité, il est préférable d’avoir un mot de passe différent par compte; qui plus est pour le compte root qui donne accès à tous le privilèges sur la machine. Nous allons donc le modifier de la même manière que pour l’utilisateur, à la différence qu’il n’est pas obligatoire de donner le nom d’utilisateur en argument. Ainsi, entrez la commande suivante pour changer le mot de passe root:
|
|
root@serveur:~# passwd
Entrez le nouveau mot de passe UNIX :
Retapez le nouveau mot de passe UNIX :
passwd : le mot de passe a été mis à jour avec succès
|
Bien entendu, le mot de passe doit être assez solide (voir section Sécuriser SSH de cet article).
Nous pouvons avoir accès au compte root depuis SSH mais également en utilisant les commandes su et sudo lorsque l’on est connecté au serveur en tant que simple utilisateur. La commande su demandera systématiquement le mot de passe root tandis que sudo est configurée, par défaut, à autoriser les comptes utilisateurs qui font partie du groupe sudo à basculer en tant qu’utilisateur root. Ainsi, si votre compte utilisateur est compromis, l’attaquant pourra facilement se connecter en tant que root et faire plus de dégâts. Pour éviter cela, nous allons modifier la configuration de sudo. Pour cela, entrez la commande suivante:
Ajoutez la ligne suivante à la fin du fichier:
|
|
Defaults rootpw,timestamp_timeout=0
|
Ici nous modifions la configuration de sudo pour qu’il demande systématiquement le mot de passe root et fixons à zéro le délai pendant lequel il ne redemandera pas le mot de passe root. Ainsi, à chaque utilisation de la commande sudo, il sera nécessaire de fournir le mot de passe root.
Enregistrez et quittez l’éditeur (faites Contrôle-X puis O pour enregistrer le fichier et quitter sous nano).
L’utilisateur que nous avons créé plus haut ne fait pas encore partie du groupe sudo. Pour remédier à cela, entrez la commande suivante:
|
|
root@serveur:~# gpasswd -a NOM_UTILISATEUR sudo
|
Pour le moment,
le seul accès possible au serveur se fait via
SSH. Le protocole a beau être sécurisé,
il reste possible d’attaquer un serveur. Certains attaquants utilisent des
techniques d’attaques par dictionnaire ou par brute force. Les attaques de type brute force consistent à essayer tous les couples de login/mot de passe possibles. Cette technique présente l’avantage de tomber forcément sur votre mot de passe. Cependant,
avec un mot de passe suffisamment solide, cette technique devient inexploitable. En effet, il faudra des millions d’années pour trouver le mot de passe. Avec par exemple, un mot de passe contenant des lettres majuscules et minuscules ainsi que des chiffres, s’il fait une longueur de 8 caractères, il peut y avoir 62 puissance 8 possibilités soit: 218 340 105 584 896 possibilités. À raison d’un test par seconde, il faudrait environ 6 923 519 années pour tester toutes les combinaisons. Un autre type d’attaques peut être plus efficace: les attaques par dictionnaire. Le principe reste le même que le brute force sauf que l’on ne teste pas toutes les possibilités de mot de passe mais juste des mots d’un dictionnaire et éventuellement des combinaisons entre eux. Ainsi, si votre mot de passe est un mot ou une phrase, il sera beaucoup plus facile à deviner.
Vous pourrez trouver un script Pyton de génération de mots de passe dans mon précédent article.
Nous allons modifier la configuration du serveur SSH de votre serveur. Nous allons entre autres changer le port d’écoute de SSH qui est par défaut le port 22. En utilisant un port différent, l’attaquant devra alors trouver en plus le bon port pour tenter de se connecter au serveur. Il existe certes des scanners de ports mais ils ne sont pas systématiquement utilisés (la plupart des attaques se font sur le port 22). Ainsi, vous allez devoir choisir un numéro de port qui soit supérieur à 1024 et qui ne correspond pas à un service exécuté par le serveur. Nous allons également interdire les connexions au compte root. En effet, de nombreuses attaques visent le compte root puisqu’il s’agit du compte ayant le plus de privilèges. Pour se connecter au compte root, il faudra d’abord se connecter via le compte utilisateur créé plus haut dans cet article. Ainsi l’attaquant devra également connaître le nom d’utilisateur du compte que l’on a créé et son mot de passe ou son certificat.
Pour réaliser toutes ces opérations, sur le serveur, ouvrez et éditez le fichier /etc/ssh/sshd_configavec votre éditeur préféré, comme ici:
|
|
root@serveur:~# nano /etc/ssh/sshd_config
|
Puis, modifiez le fichier pour avoir les lignes suivantes en remplaçant le numéro de port:
|
|
Port NUMERO_PORT
PermitRootLogin no
|
Enregistrez alors le fichier, et quittez l’éditeur (faites Contrôle-X puis O pour enregistrer le fichier et quitter sous nano)
Il faut ensuite redémarrer le serveur SSH en tapant la commande suivante:
|
|
root@serveur:~# sudo service ssh restart
|
Pour vous connecter en tant que root sur le serveur, vous devrez dorénavant vous connecter avec votre compte utilisateur sur le serveur et basculer en root avec su ou sudo.
À présent, pour vous connecter au serveur, vous allez devoir préciser le port que le client SSH devra utiliser pour communiquer avec le serveur.
– Sous GNU/Linux, il suffit d’ajouter à la commande ssh le paramètre -p suivi du numéro de port, comme ici:
|
|
utilisateur@poste-travail:~$ ssh NOM_UTILISATEUR@IP_DU_SERVEUR -p NUMERO_PORT
|
Sécurisation minimale d’un serveur dédié Kimsufi sous Ubuntu Server 14.04 LTS – Modification du port SSH dans PuTTY
Vous pouvez maintenant vous connecter avec le bon port et restaurer la session correctement configurée ultérieurement.
Pour encore plus de sécurité, il est possible de bannir les attaquants. En effet, les journaux systèmes (logs) enregistrent toutes les tentatives de connexion au serveur. Ceux-ci gardent l’adresse IP de toute machine qui essaye de se connecter au serveur. Ainsi, s’il y a trop de tentatives de connexion en échec, il est possible de bannir l’attaquant en indiquant au pare-feu de bloquer toutes les connexions depuis l’adresse IP vers le serveur SSH. Les logiciels denyhosts et fail2banpermettent d’automatiser cette tâche. Ici, nous allons mettre en place fail2ban qui a l’avantage de protéger d’autres services que SSH, tels que FTP, le serveur Web Apache, etc…
Pour cela, il est nécessaire d’installer le paquet fail2ban sur le serveur. Toujours sur le serveur, entrez la commande suivante en tant que root:
|
|
root@serveur:~# apt-get install fail2ban
|
Ouvrez ensuite le fichier /etc/fail2ban/jail.conf et modifiez la section [ssh], en changeant le numéro de port avec celui choisi comme port d’écoute pour SSH:
|
|
[ssh]
enabled = true
port = ssh,sftp,NUMERO_PORT
filter = sshd
logpath = /var/log/auth.log
maxretry = 3
|
Ici, on ajoute l’écoute sur le port SFTP ainsi que le port SSH que l’on a redéfinit et on fixe le nombre d’essais possibles, avant blocage, à 3.
Lorsqu’une adresse IP est bloquée, on dit qu’elle est en prison ou en liste noire. Sous fail2ban, il existe une prison par service protégé.
Afin d’être prévenu quand une adresse IP est bloquée, un e-mail peut être envoyé depuis le serveur sur une adresse e-mail spécifiée. Pour ce faire, il faut modifier la variable destemail comme ceci:
|
|
destemail = adresse@email.fr
|
De plus, modifiez la ligne suivante:
En:
Bien entendu, il est nécessaire que le serveur soit équipé d’un serveur SMTP afin qu’il puisse envoyer l’e-mail. Nous en installerons et configurerons un dans un futur article.
Il est possible de mettre en place des règles spécifiques pour éviter certaines attaques fréquentes telles que les requêtes DFind w00tw00t. Pour ce faire, ajoutez à la fin du fichier la section suivante:
|
|
[apache-w00tw00t]
enabled = true
filter = apache-w00tw00t
action = iptables[name=Apache-w00tw00t,port=80,protocol=tcp]
logpath = /var/log/apache2/access*.log
maxretry = 1
|
Vous pouvez alors enregistrer et quitter l’éditeur.
Il faut ensuite créer et éditer le fichier /etc/fail2ban/filter.d/apache-w00tw00t.conf avec par exemple:
|
|
root@serveur:~# nano /etc/fail2ban/filter.d/apache-w00tw00t.conf
|
Insérez y alors le contenu suivant:
|
|
[Definition]
failregex = ^<HOST> -.*"GET \/w00tw00t\.at\.ISC\.SANS\.DFind\:\).*".*
ignoreregex =
|
Vous pouvez enregistrer et quitter l’éditeur.
Afin d’être le plus efficace possible contre les attaques par brute force, on peut activer le filtre SASL. Pour cela, il faut créer le fichier/etc/fail2ban/filter.d/sasl.conf avec par exemple:
|
|
root@serveur:~# nano /etc/fail2ban/filter.d/sasl.conf
|
Et y insérer les lignes suivantes:
|
|
[Definition]
failregex = (?i): warning: [-._\w]+\[<HOST>\]: SASL (?:LOGIN|PLAIN|(?:CRAM|DIGEST)-MD5) authentication failed(: [ A-Za-z0-9+/]*={0,2})?\s*$
ignoreregex =
|
Vous pouvez enregistrer et quitter l’éditeur.
Il faut maintenant recharger la configuration du service fail2ban avec la commande suivante:
|
|
root@serveur:~# fail2ban-client reload
|
Il est possible que vous obteniez un message d’erreur du genre:
|
|
ERROR No file found for /var/log/apache2/access*.log
|
Cela est dû au fait que le serveur Web Apache n’est pas encore installé sur le serveur. Son installation sera le sujet d’un futur article.
Pour vérifier que le service fonctionne correctement, tapez:
|
|
root@serveur:~# fail2ban-client status
Status
|- Number of jail: 1
`- Jail list: ssh
|
Ainsi, la commande indique le nombre de prisons. c’est à dire de services protégés par fail2ban.
Attention: si vous vous trompez de login/mot de passe 3 fois, vous allez être bloqué et vous devrez redémarrer le serveur en mode rescue ou vous connecter avec une adresse IP publique différente.
Pour voir quelles adresses IP sont bannies, il faut lancer la commande suivante:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
|
root@serveur:~# iptables -L -n
Chain INPUT (policy ACCEPT)
target prot opt source destination
fail2ban-ssh tcp -- 0.0.0.0/0 0.0.0.0/0 multiport dports 22,115,NUMERO_PORT
Chain FORWARD (policy ACCEPT)
target prot opt source destination
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
Chain fail2ban-ssh (1 references)
target prot opt source destination
REJECT all -- ADRESSE_IP_BLOQUÉE 0.0.0.0/0 reject-with icmp-port-unreachable
RETURN all -- 0.0.0.0/0 0.0.0.0/0
|
Ainsi, on voit ici que l’adresse IP ADRESSE_IP_BLOQUÉE a été bloquée grâce à la directive REJECTdu pare-feu iptables, dans la chaîne fail2ban-ssh.
Pour supprimer une adresse IP de la liste noire (par exemple, si on a bloqué une machine qui ne devait pas être bloquée), il faut utiliser la commande suivante:
|
|
root@serveur:~# iptables -D fail2ban-ssh -s ADRESSE_IP_BLOQUÉE -j REJECT
|
Comme il existe d’autres types de prison que SSH, il faut adapter la commande en remplaçant par exemple, fail2ban-ssh par fail2ban-pure-ftpd pour utiliser la prison FTP.
Ubuntu se compose de nombreux logiciels. Comme tout programme, ils ne sont pas parfait et comportent des bugs. Ces bugs peuvent se transformer en failles de sécurité exploitables par de potentiels attaquants et donc compromettre la sécurité du serveur. Ainsi, les développeurs de ces programmes publient régulièrement des mises à jour qui corrigent ces bugs et apportent de nouvelles fonctionnalités. Il est donc vital de disposer d’un serveur toujours à jour. Pour cela, exécutez les trois commandes suivantes sur le serveur:
|
|
root@serveur:~# apt-get update
root@serveur:~# apt-get upgrade
root@serveur:~# apt-get dist-upgrade
|
La première commande va mettre à jour la liste des paquets alors que les deux dernières vont mettre à jour les paquets eux mêmes. Ces commandes sont à lancer régulièrement sur le serveur pour qu’il soit constamment à jour et protégé des failles de sécurité.
Même avec ces mesures de sécurité mises en place,
il est nécessaire d’être vigilent. Ainsi, il est conseillé de contrôler régulièrement les fichiers journaux des différents services afin de déceler une éventuelle intrusion ou un problème sur un service qui pourrait mettre en péril la sécurité du serveur.
Vous trouverez les fichiers journaux
dans le dossier /var/log sur le serveur.
Sachez également, que vous êtes dans l’obligation, aux yeux de la loi de conserver ces fichiers pendant au minimum un an. Pensez donc à les sauvegarder régulièrement.
Comme dit en début d’article, la sécurité informatique est un vaste domaine. Cet article n’est donc qu’une introduction à la sécurité sur les serveurs dédiés. Il est nécessaire de rester vigilant et de maintenir à jour le serveur tant au niveau des logiciels et que de leur configuration. Maintenant que le serveur est à peu près sécurisé, nous allons pouvoir installer et configurer un premier service: le serveur Web Apache. Ce sera le sujet du prochain article.
EDIT: cet article a été mis à jour suite aux remarques de ts, données en commentaire, concernant l’oubli de la commande chown qui permet de fixer le propriétaire et le groupe du fichier /home/NOM_UTILISATEUR/.ssh/authorized_keys dans la partie Créer un compte utilisateur. Une autre erreur a également été corrigée concernant le fichier /etc/fail2ban/filter.d/apache-w00tw00t.conf,voir les commentaires plus bas.
