Introduction

Nous allons dans cette article sécurité OMV en créant des règles dans le firewall pour les connexions entrantes et sortantes. Dans la 1ere partie de l’article nous mettrons en place une protection standard minimale qui convient parfaitement pour un NAS peu exposée aux accès extérieur. Dans un 2eme temps nous irons un peu plus loin pour mettre en place une configuration optimale (service par service) qui n’autorise que ce qui est nécessaire.

Le firewall d’OMV est par défaut actif mais tous les ports sont ouverts. Il y a deux façons de procéder :

• On commence par tout bloquer, puis on autorise ce dont nous avons besoin. Je vous déconseille cette méthode avec OMV. On peut se retrouver bloquer sans accès au NAS en cas de problème dans la configuration.
  
• On ouvre ce dont nous avons besoin et nous bloquons tous le reste. C’est ce que nous allons faire dans la 2ème partie de l’article pour la configuration avancée.
  

Configuration standard du firewall d’OMV

Sur mon NAS je n’autorise qu’une seule connexion entrante venant de l’extérieur via le service HTTPS (Port 443) et le containeur ‘swag‘ (voir l’article installation swag avec docker). Je n’ai donc que très peu de règles pour la configuration standard du firewall. Voici une capture des règles du firewall :

Comme vous pouvez le voir les règles sont assez simple (l’ordre à son importance) :

• -m conntrack –ctstate ESTABLISHED,RELATED : On accepte les paquets venant des connexions déjà établies et les paquets commençant une nouvelle connexion mais déjà lié à une connexion existante,
  
• -i lo : Autorisation de l’utilisation de l’interface ‘loopback’ (127.0.0.1),
  
• INPUT ACCEPT 192.1.168.1.0/24 : On accepte tout ce qui vient de notre LAN,
  
• INPUT ACCEPT ALL vers ‘ipNAS’:443 (TCP) : On accepte les connexions entrantes sur le port 443 ayant pour destination le NAS et que via le protocole TCP,
  
• INPUT DROP : On rejette tout le reste.

Configuration avancée du firewall d’OMV

Modification du gestionnaire de log

Nous allons dans un 1er temps activer les fichiers logs pour le firewall (‘iptables‘ sous Linux). Par défaut il n’y a pas de fichier de log spécifique pour ‘iptables’ et les messages sont redirigés vers les journaux systèmes.

Nous avions déjà vus au niveau de la gestion des taches ‘cron‘ (voir article taches planifiees avec omv) comment rajouter un fichier de log ‘cron‘ au système ‘rsyslog‘. On vas faire la même chose pour le service ‘iptables‘.

Nous allons donc modifier le fichier de configuration ‘rsyslog.conf‘ qui se trouve dans le répertoire /etc/. Pour cela on tape la commande :

Nous rajoutons la ligne suivante en dessous du paragraphe ‘RULES’ (vers la ligne 63).

Nous signalons au système que nous voulons filtrer les messages contenant la chaine ‘[iptables]‘.

On sauve le fichier en tapant les deux touches simultanément ‘CTRL+O’, puis on fait de même pour quitter en tapant ‘CTRL+X’.

Il faudra aussi créer un fichier de configuration pour la rotation des logs ‘iptables‘ en créant le fichier /etc/logrotate.d/iptables suivant :

/var/log/iptables.log
{
    rotate 7
    daily
    missingok
    notifempty
    delaycompress
    compress
    postrotate
	    /usr/lib/rsyslog/rsyslog-rotate >/dev/null
    endscript
}

Il faut relancer le daemon système ‘rsyslog’ pour que les modification soient prises en compte; puis on vérifie aussi le bon fonctionnement du daemon ‘rsyslog‘ :

Règles spécifiques pour gérer les logs dans le firewall

Nous allons ajoutés deux règles dans le firewall pour renvoyer tout ce qui est rejeté en INPUT et OUTPUT vers le log avec le préfixe ‘[iptables] ‘. Ces deux règles devront se situer à la fin de toutes les autres règles du firewall, juste avant la dernière règle « DROP ».

Préparation des règles du firewall

OMV gère les regles ‘iptables‘ via le script ‘openmediavault-firewall.sh’ qui se trouve dans le répertoire /etc/iptables. Faites en une sauvegarde avant de commencer.

Pour cette deuxième partie, nous avons prévu d’autoriser tous nos services un par un, puis de terminer par une directive LOG et DROP. Avant de commencer, il faut faire un état des lieux de vos différents services hébergés sur votre réseau et le trafic entrant et sortant qu’ils occasionnent. Nous allons donc procéder en deux étapes, le trafic entrant (INPUT), puis le trafic sortant (OUPUT) :

Le trafic entrant (INPUT) avec les numéros de ports :

• On autorise le loopbak (127.0.0.1),
• *N autorise les ESTABLISHED et RELAT,
• Notre seul accès autorisé de l’extérieur : HTTPS (443),
• Tous les paquets ICMP venant du LAN (192.168.1.0/24),
• Notre accès FTP (21) venant du LAN,
• Notre accès SSH (22) venant du LAN,
• L’accès DNS (53) en TCP/UDP venant du LAN si vous hébergé un service Pi-Hole (53), # optionnel
• Notre accès HTTP (80) pour l’interface d’OMV venant du LAN,
• Les accès SMB/CIFS (137 et 138) en UDP venant du LAN,
• Les accès SMB/CIFS (139 et 445) en TCP venant du LAN,
• Les accès sur le port 1900 pour le protocole UPnP, #optionnel
• Les accès sur le port 5353 pour le protocole mDNS, #optionnel
• Le Multicast est bloqué en amont pour ne pas polluer les logs, #optionnel
• La redirection vers les LOG pour tout le reste qui sera rejeté,
• On bloque tout le reste en entrée.

Le trafic sortant (OUPUT) avec les numéros de ports :

• On autorise le loopbak (127.0.0.1),
• PN autorise les ESTABLISHED et RELAT,
• Tout les paquets ICMP,
• Tout le trafic vers le LAN,
• Tout le trafic FTP Sortant (21) pour les outils comme Duplicati,
• Les accès SSH OU SFTP (22) vers l’extérieur,
• Les accès SMTP (25) pour les notifications,
• Toutes Les demandes DNS vers l’extérieur (53),
• Les accès HTTP (80) vers l’extérieur,
• Les demandes NTP (123) si nécessaire,
• Les accès HTTPS (443) vers l’extérieur,
• Les accès SMTPS (465/487) pour les notifications,
• Les accès sur le port 5353 pour le protocole mDNS, #optionnel
• La redirection vers les LOG pour tout le reste qui sera rejeté.
• On bloque tout le reste en sortie.

Ce qui donnera en règle brut :

Vous devrez entrer les règles une par une en conservant bien le même ordre. Sauvegarder les règles avant de les appliquer :

Vous pouvez vérifier la présence du fichier /var/log/iptables.log qui vous indiquera les connexions qui ont été bloquées. S’il n’est pas présent c’est que le Firewall n’a encore rien bloquer pour le moment.

Pour terminer, nous allons vérifier le bon fonctionnement du fichier de log. Taper par exemple une requête extérieur sur le port 23 (TELNET) :

Vous pouvez remarquer beaucoup de spam (avant 21h21) provenant du multicast. Après l’ajout des règles de blocage en amont, il n’y a plus aucun message. Sur les dernières lignes on peut voir le test de blocage en sortie sur le port 23 (Telnet).

Vous aurez peut-être d’autres règles ‘DROP’ pour nettoyer les LOG de messages inutiles ou alors d’autres règles ‘ACCEPT’ spécifique à rajouter pour autoriser un protocole particulier. Vérifiez vos logs de temps en temps pour les identifier.