Déploiement et sécurisation light d'un VPS sous Ubuntu 20.04

Installation de iptables-permanent

Comme son nom l’indique ce paquet permet de sauvegarder en permanent les règles iptables stockées dans les fichiers /etc/iptables/rules.v4 (pour IPv4) et rules.v6 (pour IPv6).

apt install iptables-permanent

rules.v4

Les règles suivantes passent tous les paquets arrivant depuis l’extérieur en DROP. Comme c’est un serveur Web j’ouvre SSH, HTTP, HTTPS. J’accepte aussi les réponses aux requêtes DNS émises, et aux potentielles mises à jour de paquets via APT. J’accepte aussi les requêtes entrantes sur l’interface locale. Puis je log et drop le reste des paquets, ça permet de faire un peu de débogage.

*filter
:INPUT DROP [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
# Acceptable incoming TCP traffic
-A INPUT -i eth0 -p tcp -m tcp --dport 22 -j ACCEPT
-A INPUT -i eth0 -p tcp -m tcp --dport 80 -j ACCEPT
-A INPUT -i eth0 -p tcp -m tcp --dport 443 -j ACCEPT
-A INPUT -i eth0 -p udp -m udp --sport 53 --dport 1024:65535 -m state --state ESTABLISHED -j ACCEPT
-A INPUT -i eth0 -p tcp -m tcp --sport 443 --dport 1024:65535 -m state --state ESTABLISHED -j ACCEPT
-A INPUT -i l0 -m -j ACCEPT
# Log and drop
-N LOGGING
-A INPUT -j LOGGING
-A LOGGING -m limit --limit 2/min -j LOG --log-prefix "[netfilter] " --log-level 4
-A LOGGING -j DROP
COMMIT

Il suffit de modifier la configuration rsylog, pour rediriger les logs dans un fichier spécifique (créer un fichier /etc/rsyslog.d/20-netfilter.conf) :

# Log kernel generated UFW log messages to file
:msg,contains,"[netfilter] " /var/log/netfilter.log

# Uncomment the following to stop logging anything that matches the last rule.
# Doing this will stop logging kernel generated UFW log messages to the file
# normally containing kern.* messages (eg, /var/log/kern.log)
#& stop

Les logs seront situés dans /var/log/netfilter.conf.

rules.v6

Pour l’instant je bloque tout mais je pourrais avoir besoin d’ouvrir, donc je ne désactive pas IPv6.

*filter
:INPUT DROP [0:0]
:FORWARD DROP [0:0]
:OUTPUT DROP [0:0]
COMMIT

*raw
:PREROUTING DROP [0:0]
:OUTPUT DROP [0:0]
COMMIT

*nat
:PREROUTING DROP [0:0]
:INPUT DROP [0:0]
:OUTPUT DROP [0:0]
:POSTROUTING DROP [0:0]
COMMIT

*security
:INPUT DROP [0:0]
:FORWARD DROP [0:0]
:OUTPUT DROP [0:0]
COMMIT

*mangle
:PREROUTING DROP [0:0]
:INPUT DROP [0:0]
:FORWARD DROP [0:0]
:OUTPUT DROP [0:0]
:POSTROUTING DROP [0:0]
COMMIT

Vérification avec Nmap

Un petit quickscan avec Zenmap permet de confirmer la fermeture de la plupart des ports :

Installation de fail2ban

Fail2ban permet de mettre dans « une prison » toutes les requêtes insistantes sur le service SSH (par défaut c’est ce service qui est le plus utilisé mais il est possible de le faire pour HTTP, FTP, SMTP, etc).

apt install fail2ban

Configuration

Les fichiers de configuration sont situés dans le répertoire /etc/fail2ban/jail.conf. Par défaut le service sshd est bien configuré.

Vous pouvez aller voir ici, c’est bien expliqué aussi.

Bonus : utilisation d’OpenSCAP

Utilisation depuis le serveur

apt install libopenscap8

Il faut télécharger les dernières version des listes de configuration de sécurité sous format XCCDF. Ces profils sont librement téléchargeables ici.

Le principal problème c’est qu’il n’existe aucun profil pour Ubuntu 20.04 et que la compatibilité ne doit pas être « immédiate » avec la version 18.04. Il suffit d’utiliser la version pour 18.04 et de tromper la vérification de version dans le fichier ssg-ubuntu1804-ds.xml et remplacer toutes les occurrences de « CODENAME=bionic$ », par « CODENAME=focal$ ».

Puis de lancer cette commande (nous allons vérifier les règles de sécurité basique proposée par l’ANSSI) :

oscap xccdf eval --profile xccdf_org.ssgproject.content_profile_anssi_np_nt28_minimal --report report.html ssg-ubuntu2004-ds.xml

La sortie standard ressemble à ça :

Un fichier report.html est généré :

Utilisation avec SCAP Workbench

Il est aussi possible d’effectuer à distance la vérification des règles via une connexion SSH. Il suffit de reprendre le fichier modifié des règles valables pour la version Bionic et de le charger dans l’application Workbench. Une fois l’exécution terminée on obtient directement dans l’application la validation des règles :

Conclusion

Lorsque l’on commence à mettre en place un minimum de règles de durcissement système le mieux est d’aller par étape et de bien comprendre ce que l’on essaye de mettre en place. L’avantage c’est que de nombreux utilisateurs se sont déjà frottés à cet exercice et que de nombreux tutoriels sont déjà disponibles pour aller plus vite.

Mettre en place des procédures pour améliorer la sécurité c’est bien, les vérifier et les contrôler c’est encore mieux (et optimum lorsque c’est périodique). Le projet OpenSCAP est vraiment utile pour le contrôle de ces différents points, celui-ci peut aussi valider si les CVEs sont correctement corrigés même si OpenVAS est clairement plus adapté pour ça.

Pour aller plus loin si vos règles OpenSCAP ne sont pas validées, il est possible via les playbooks Ansible fournis (dans le dossier Ansible), de corriger directement vos systèmes.