Sécuriser son serveur est d’autant plus important que c’est un « serveur », donc par définition une machine ouverte sur Internet. Intéressant pour héberger vos sites web, mais attention à ne pas vous faire attaquer (Brute force, DDOS…).
Ce tuto a donc pour but de vous donner les éléments les plus importants à sécuriser.
On est ici sur une « fresh install » d’un Ubuntu Server 20.04 LTS.
Son IP pour le labo est : 192.168.1.210, son nom est « tuto » et le username est : ludo. Pour éditer les fichiers de configuration, j’utilise « vim ».
C’est parti !
Sécurisation de l’accès SSH
On se connecte à la machine en SSH (perso, sur mon PC, j’utilise Windows Terminal). On voit ici que pour la première connexion, le terminal indique qu’il ne connait pas notre serveur. Il nous indique sa clé publique et demande si on veut bien se connecter. Il faut écrire « yes » en toutes lettres.
ssh ludo@192.168.1.210
The authenticity of host '192.168.1.210 (192.168.1.210)' can't be established.
ECDSA key fingerprint is SHA256:YnLds3OTzyE0Tn55DVW4qC69MkACkDxRLNOqkwLABBw.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '192.168.1.210' (ECDSA) to the list of known hosts.
ludo@192.168.1.210's password:
Welcome to Ubuntu 20.04.1 LTSOn est connecté sur la machine.
Maintenant, quelques mises à jour s’imposent. Pour ma part, je préfère bosser en root, pour éviter le « sudo » et avoir à taper systématiquement mon mot de passe à chaque action. Attention cependant, root est très puissant et des fausses manips’ peuvent avoir de lourdes conséquences. Ne le faites que si vous savez exactement ce que vous faites.
ludo@tuto:~$ sudo -i
[sudo] password for ludo:
root@tuto:~#On recherches les mises à jour :
root@tuto:~# apt updateSi des mises à jour sont trouvées, on les installe :
root@tuto:~# apt upgradeMaintenant que notre machine est bien à jour, on va aller s’attaquer au port d’écoute SSH. Par défaut, c’est 22. Ce port standard est donc le premier à se faire bruteforcer par des individus malveillants. Le changer permettra d’éviter de nombreuses attaques de bots. On ouvre donc le fichier de config SSH :
vim /etc/ssh/sshd_configOn recherche la ligne suivante :
#Port 22On décommente et on met un port de votre choix. Pour ma part, j’ai choisi le 8383 :
Port 8383Plus loin, on interdit à root de se connecter directement en SSH. On décommente et on passe la valeur à « no » :
PermitRootLogin noOn sauvegarde et puis on quitte. Il faut ensuite redémarrer le service SSH afin de prendre en compte les modifications que nous venons de faire :
service ssh restartOn quitte notre session SSH afin de tester si ce qu’on a fait fonctionne bien :
root@tuto:~# exit
logout
ludo@tuto:~$ exit
logout
Connection to 192.168.1.210 closed.On se connecte ensuite, avec l’argument « -p » pour indiquer sur quel port on souhaite lancer la connexion SSH :
ssh -p 8383 ludo@192.168.1.210
ludo@192.168.1.210's password:
Welcome to Ubuntu 20.04.1 LTSCela fonctionne ! Si le port saisi était faux ou que ce dernier n’était pas renseigné, on aurait eu cette réponse :
ssh: connect to host 192.168.1.210 port 22: Connection refusedSécurisation des ports de la machine : le Pare-Feu UFW
« UFW » est un pare-feu déjà installé sur Unbuntu Server. Il constitue une alternative plus simple au bon vieux « Iptables ». On se remet en utilisateur root :
ludo@tuto:~$ sudo -i
[sudo] password for ludo:
root@tuto:~#On vérifie que UFW est bien installé en vérifiant l’état du service. Il faut que son statut soit sur « active » :
root@tuto:~# service ufw status
ufw.service - Uncomplicated firewall
Loaded: loaded (/lib/systemd/system/ufw.service; enabled; vendor preset: enabled)
Active: active (exited) since Sat 2020-12-05 15:10:58 UTC; 28min ago
Docs: man:ufw(8)
Process: 492 ExecStart=/lib/ufw/ufw-init start quiet (code=exited, status=0/SUCCESS)
Main PID: 492 (code=exited, status=0/SUCCESS)On va lui définir la règle suivante : on autorise tout ce qui sort, et on interdit tout ce qui rentre. Pourquoi ? Car c’est une règle important en sécurité : tout est interdit par défaut… sauf les règles que l’on applique :
ufw default deny incoming
ufw default allow outgoingMaintenant que c’est fait, on va commencer par autoriser les connexions SSH, sur le port défini :
root@tuto:~# ufw allow 8383
Rules updated
Rules updated (v6)Une règle est créée en IPV4, mais également en IPV6. Maintenant que c’est fait, on peut activer UFW sans crainte de se faire couper la session SSH en cours (un warning apparait d’ailleurs à ce sujet, on saisit « y » pour valider notre choix :
root@tuto:~# ufw enable
Command may disrupt existing ssh connections. Proceed with operation (y|n)? y
Firewall is active and enabled on system startupC’est fait, UFW refuse pour le moment toutes les connexions entrantes, hormis le SSH customisé, et se lancera automatiquement à chaque démarrage de la machine. On peut vérifier l’état de UFW et les règles actuellement actives :
root@tuto:~# ufw status verbose
Status: active
Logging: on (low)
Default: deny (incoming), allow (outgoing), disabled (routed)
New profiles: skip
To Action From
-- ------ ----
8383 ALLOW IN Anywhere
8383 (v6) ALLOW IN Anywhere (v6)On voit donc ici que le Firewall est actif, qu’il accepte toutes les connexions sortantes (outgoing), qu’il refuse toues les connexions entrantes (incoming) sauf celles vers le port 8383 en IPV4 et en IPV6.
Notre machine est un serveur web, on va donc autoriser les connexions entrantes vers les ports les plus communément utilisés. Voici ceux qu’il faut ouvrir à minima sur un serveur possédant un serveur web, une base de données SQL, un FTP et un serveur email :
20 Port ftp-data utilisé pour la transmission des données FTP
21 Port FTP
25 Port SMTP pour le serveur Email
53 Port DNS
80 Port HTTP
110 Port POP3 pour le serveur Email
143 Port IMAP pour le serveur Email
443 Port HTTPS
587 Port Submission pour le serveur Email
993 Port IMAPS (utilisant SSL) pour le serveur Email
995 POP3S (utilisant SSL) pour le serveur Email
3306 Port MySQL / MARIADB (à n’ouvrir que si besoin de connexions externes)
C’est parti pour la création des règles UFW :
ufw allow 20
ufw allow 21
ufw allow 25
ufw allow 53
ufw allow 80
ufw allow 110
ufw allow 143
ufw allow 443
ufw allow 587
ufw allow 993
ufw allow 995
ufw allow 3306On affiche ensuite le récapitulatif :
root@tuto:~# ufw status verbose
Status: active
Logging: on (low)
Default: deny (incoming), allow (outgoing), disabled (routed)
New profiles: skip
To Action From
-- ------ ----
8383 ALLOW IN Anywhere
20 ALLOW IN Anywhere
21 ALLOW IN Anywhere
25 ALLOW IN Anywhere
53 ALLOW IN Anywhere
80 ALLOW IN Anywhere
110 ALLOW IN Anywhere
143 ALLOW IN Anywhere
443 ALLOW IN Anywhere
587 ALLOW IN Anywhere
993 ALLOW IN Anywhere
995 ALLOW IN Anywhere
3306 ALLOW IN Anywhere
8383 (v6) ALLOW IN Anywhere (v6)
20 (v6) ALLOW IN Anywhere (v6)
21 (v6) ALLOW IN Anywhere (v6)
25 (v6) ALLOW IN Anywhere (v6)
53 (v6) ALLOW IN Anywhere (v6)
80 (v6) ALLOW IN Anywhere (v6)
110 (v6) ALLOW IN Anywhere (v6)
143 (v6) ALLOW IN Anywhere (v6)
443 (v6) ALLOW IN Anywhere (v6)
587 (v6) ALLOW IN Anywhere (v6)
993 (v6) ALLOW IN Anywhere (v6)
995 (v6) ALLOW IN Anywhere (v6)
3306 (v6) ALLOW IN Anywhere (v6)Aller plus loin
Sécuriser l’accès SSH de se machine et restreindre les ports ouverts sont de très bons prérequis pour se prémunir d’attaques et sécuriser son serveur.
Il existe cependant d’autres configurations qui peuvent être appliquées. Ces outils ne sont pas à proprement parler des outils de sécurité, mais ils permettent de surveiller et maintenir à jour son serveur. Ceci fera peut-être l’objet d’autres tutos. Voici une liste non exhaustive de paquets pouvant être mis en place :
Fail2Ban
Cron-Apt
RKHunter
LogWatch
Restrictions par IP via UFW
Authentification SSH par clé privée