OMV6 [Mémo] Régler son pare-feu OMV ( Openmediavault ) pour un usage local

EVO

Administreur
Membre du personnel
25 Novembre 2019
9 030
1 787
293
/var/run/docker.sock
Bonjour,
Petit mémo, sur comment paramétrer le pare-feu d'OMV pour un usage local :

Les Règles sont as rajouter dans l'ordre, car l'ordre a une importance. Le pare-feu exécute les regles de la 1ere a la dernière.

Dans l'ordre nous allons :
  1. Autoriser les connexions entrantes déja existantes
  2. Autoriser les connexions sortantes déja existantes
  3. Autoriser le loopback en entrée
  4. Autoriser le loopback en sortie
  5. Autoriser toutes les connexions sortantes
  6. Autoriser tous ce qui viens du réseau local
  7. On interdit tout le reste des connexions entrantes

Voici cela cela donne :
mGDhMha.png


Attention : Pour la règle n°6 "Autoriser tous ce qui viens du réseau local" penser à personnaliser le réseau "Source" par votre réseau local. Si votre réseau local est en 192.168.1.X comme moi alors c'est 192.168.1.0/24 qu'il faut indiquer, si par exemple votre réseau local est en 192.168.0.X alors il faut indiquer 192.168.0.0/24.

Pour plus de sécurité vous pouvez également filtré les connexions sortantes ( ici on autorise toutes les connexions sortante sans distinction ), pour plus d'infos, je vous laisse avec ce tutoriel.

Et si je fait une bétise ? :?
Si vous vous bloquer vous même, il vous faut brancher un écran et un clavier sur votre machine ( si ce n'est pas déja fait ), puis vous logger. Une fois logger executer la commande suivante pour supprimer les règles de pare-feu actuelle :
Code:
iptables -F
 
Dernière édition:
si notre NAS n'est pas ouvert vers l'exterieur et qu'on y accede uniquement par VPN, est-ce necessaire de configurer le pare feu d'OMV ? Je precise que je suis une grosse brele en securite (c'est pour cela que je ne l'ouvre pas et que je prefere la solution VPN - Tailscale dans mon cas).
 
si notre NAS n'est pas ouvert vers l'exterieur et qu'on y accede uniquement par VPN, est-ce necessaire de configurer le pare feu d'OMV ? Je precise que je suis une grosse brele en securite (c'est pour cela que je ne l'ouvre pas et que je prefere la solution VPN - Tailscale dans mon cas).
Je dirait que Oui.
Qu'est-ce qui t'assure que ton NAS n'est pas ouvert vers l'extérieur ? Ta box ? Et si tu en change, sera tu toujours aussi sur ?
L'IPV6 est actif sur ton réseau ? et sur le NAS ?
Tu es sur qu'il n'est pas accessible par ce biais ( qui ne nécessite pas d'ouverture de port ) ?
...
 
En effet, IPV6 etait active, je viens de le desactiver.

Je ne suis pas sur place avant le mois de mai donc je ne vais pas jouer avec le pare feu maintenant... mais je regarderai ce memo de nouveau quand je serai de retour
 
  • J'aime
Réactions: EVO
Je ne comprends pas très bien le sens des 2 premières règles.

Qu'entends tu par ?
  • Autoriser les connexions entrantes déjà existantes
  • Autoriser les connexions sortantes déjà existantes
Je ne suis que sur le LAN et je n'ai pas de docker ou autre container, c'est juste un NAS qui contient des films et de la musique.
 
Dernière édition:
Salut;,
Autoriser les connexions entrantes déja existantes

Cela permet de garder en "vie" les connexion entrantes établies avec le NAS

Autoriser les connexions sortantes déja existantes
Pareil a l'inverse, cela permet de garder en "vie" les connexion sortantes établies avec le NAS ( on pourrai ne pas la mettre car on ne filtre pas les connexion sortantes, mais c'est par habitude, et si tu souhaite renforcer la securité en filtrant aussi ce qui sort, la regle sera deja la.
 
Salut;,


Cela permet de garder en "vie" les connexion entrantes établies avec le NAS


Pareil a l'inverse, cela permet de garder en "vie" les connexion sortantes établies avec le NAS ( on pourrai ne pas la mettre car on ne filtre pas les connexion sortantes, mais c'est par habitude, et si tu souhaite renforcer la securité en filtrant aussi ce qui sort, la regle sera deja la.
Mais ces connexions sont celles du LAN ? Par exemple, est ce que le fait que j'accède à ce NAS en FTP pour y copier mes fichiers à partir de mon ordinateur en fait partie ?
Est ce que les connexions sortantes sur le LAN pour que ma shield et Kodi lisent les fichiers en font parties ?
 
Dans les cas des deux regles dont il est questions, elles sont valable pour toutes les connexions local, externe, ... et ne concerne que les connexions déja établie. Si la connexion n'est pas établie avec le NAS, alors le filtrage au dessus s'applique. Si c'est une connexion deja établie, elors elle passe directement ( quelques soit sa provenance )

On pourrai schématiser avec l'entrée d'une discothèque avec un vigile.
La 1ere fois que tu te présente pour la soirée, il va regarder si tu correspond aux critères ( pas dans la liste des bannis :p , majeur, bien habillé :D , ... ) une fois que tu est rentré, si tu re-sort de la discothèque pour x raison, quand tu te représente, le vigile se souvenant de toi, te laissera passer directement.
 
j'ai l'impression de déterrer de vieux sujets mais bon je me lance...
Il y a un moment je me suis fait un NAS diy: un Hp G7 N54L sous OpenMediaVault en raid 5. L'objectif est d'avoir un endroit ou déposer mes projets et programmes, que ma famille puisse aussi avoir un espace personnel ou il y mettent ce qu'ils veulent, d'y stocker mes photos et vidéos et d'y lire des film le soir...
Récemment une nouvelle version d'OMV et je viens de migrer en v6. j'ai profité de l'occasion pour m’intéresser au monde du FireWall... je n'y connais rien a part qu'il existe des "méchants" qui peuvent foutre un bordel chez moi...
j'ai parcouru plein de site et j'ai compilé les règles sans trop savoir si s’était les bonnes et voila ce que ca donne part la commande:
Code:
sudo iptables -L
Code:
Chain INPUT (policy ACCEPT)
target     prot opt source               destination
ACCEPT     all  --  anywhere             anywhere             ctstate ESTABLISHED
ACCEPT     all  --  anywhere             anywhere
ACCEPT     icmp --  192.168.1.0/24       anywhere
ACCEPT     tcp  --  192.168.1.0/24       anywhere             tcp dpt:ssh
ACCEPT     all  --  192.168.1.0/24       anywhere
ACCEPT     tcp  --  192.168.1.0/24       anywhere             tcp dpt:http
DROP       all  --  anywhere             anywhere

Chain FORWARD (policy DROP)
target     prot opt source               destination
DOCKER-USER  all  --  anywhere             anywhere
DOCKER-ISOLATION-STAGE-1  all  --  anywhere             anywhere
ACCEPT     all  --  anywhere             anywhere             ctstate RELATED,ESTABLISHED
DOCKER     all  --  anywhere             anywhere
ACCEPT     all  --  anywhere             anywhere
ACCEPT     all  --  anywhere             anywhere

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination
ACCEPT     all  --  anywhere             anywhere             ctstate ESTABLISHED
ACCEPT     all  --  anywhere             anywhere
ACCEPT     all  --  anywhere             anywhere
ACCEPT     tcp  --  anywhere             anywhere             tcp dpt:domain
ACCEPT     udp  --  anywhere             anywhere             udp dpt:domain
ACCEPT     tcp  --  anywhere             anywhere             tcp dpt:http
ACCEPT     tcp  --  anywhere             anywhere             tcp dpt:https
ACCEPT     tcp  --  anywhere             anywhere             tcp dpt:123
ACCEPT     tcp  --  192.168.1.0/24       anywhere             tcp dpt:9000

j'ai l'impression qu'il y en a en double mais bon pour mon fonctionnement ça à l'aire d'être Ok
voila, si ça peut être utile pour d'autre tant mieux! et si un expert passe par la, qu'il n'hésite pas à critiquer :eek:
 
Hello ! 👋

A mon tour de déterrer un "vieux" sujet. J'ai quelques problèmes avec ton tuto Evo..

Je souhaite exposer certains services (Plex et Overseer pour ne mentionner qu'eux) à certains membres de ma famille. La solution VPN est trop complexe à mettre en place pour eux (mais je me la réserve pour les services auxquels je serai le seul à avoir accès). J'ai donc fait l'acquisition d'un NDD et je sais qu'il me faudra ouvrir des port, mettre en place un reverse proxy, etc.

Mais je me suis dit qu'avant de faire tout ça, il serait bien de sécuriser un peu le tout. Donc j'ai activé le firewall et entré les rules de ton post. Je me suis dit que pour l'adapter, je n'aurai au moins qu'à renseigner la plage du VPN (wireguard via le plugin OMV), les IP de cloudflare pour ce qui est proxy chez eux et puis géobloquer à la France pour Plex.

Je me suis toutefois rendu compte que j'ai des problèmes à cause de la dernière ligne (le OUTPUT drop ALL) :
- Elle semble me bloquer mon VPN. Il fonctionne parfaitement sans elle et j'ai accès à mon réseau local lorsqu'il est activé. Mais si je rajoute la ligne du drop, ça ne fonctionne plus. J'ai même essayé de déclarer une règle avec la ligne de drop avec la range d'IP de wireguard, mais je n'ai pas eu plus de résultat ;​
- Elle empêche également mes services docker de communiquer entre eux. Lorsqu'elle est renseignée, Tautulli ne voit plus mon serveur Plex. De même que Sonarr/Radarr ne voient plus Prowlarr. Tous ces services sont sur la même machine. Pas de problèmes lorsque la règle de drop ALL n'est pas renseignée.​

Alors je suis très néophyte, l'étendue de mes connaissances se limite aux tutos que je lis et au tatonnage que j'applique. Si je comprends bien, wireguard déclare des règles iptables, est-ce que ça n'est pas des règles pour autoriser les connexions dans le firewall ? Ou ça n'a rien à voir ? J'ai essayé la commande "iptables -L" pour voir si quelque chose me sauterait aux yeux s'agissant de mon problème, mais je me suis retrouvé devant une liste qui fait 3-4 fois la taille de celle d'Erty et j'ai pris peur ahah.
J'ai regardé un peu sur internet mais j'ai pas trouvé le début d'une piste qui me lance sur une résolution.

Est-ce que quelqu'un aurait une petite idée sur ce qui me bloque et pourquoi ? :)
 
C'est encore moi ! 👋

Je me permets de double post, parce que j'avance un peu et que ça peut permettre à quelqu'un qui viendrait voir ce topic dans le futur de voir des pistes de résolution en dehors de mon précédent pavé. Ou pour quelqu'un qui souhaiterai mettre en place son firewall et un VPN sans avoir besoin d'exposer son serveur à internet. Mais n'hésitez pas à fusionner si c'est pas bien :giggle:

S'agissant de wireguard (toujours via le plugin OMV) j'ai finalement réussi à me connecter tout en ayant la règle "DROP ALL" à la fin du firewall. Je suis tombé à force de recherches sur ce topic sur le forum officiel de OMV qui m'a fait me rendre compte qu'en plus de préciser la range d'IP déclarée par le VPN, il me fallait également autoriser dans le firewall l'écoute sur le port de wireguard. Autrement dit, mes règles sont désormais comme celles du tuto, et wireguard est pris en compte de la façon suivante :

Capture d’écran (4).png

Alors est-ce que c'est bien, est-ce que c'est pas bien. Est-ce que c'était effectivement ce qu'il fallait faire et que je n'avais pas compris, je ne sais pas. Mais en tous cas ça fonctionne. Je laisse à ceux qui s'y connaissent le soin de dire si j'ai bien fait ou pas :giggle:

S'agissant de mes conteneurs docker maintenant. En me basant sur cette ligne que j'ai nommée "wireguard port" je peux faire la même chose pour mes conteneurs maintenant. Par exemple, si j'ajoute une ligne avec comme destination l'IP de mon NAS et le port Plex (donc "192.168.1.28 -- 32400 -- TCP") ça fonctionne, Tautulli peut désormais voir mon Plex (toujours sur la même machine).

Ce qu'il y a c'est que je n'arrive pas à apprécier la portée de cette règle (en ne déclarant pas de source j'entends) : est-ce que ça veut dire que "toutes les IP peuvent accéder à ce port" ? Mais en même temps, comme l'IP de destination correspond à une IP locale, est-ce que ça ne veut pas plutôt dire "toutes les IP LAN peuvent accéder à ce port" ? Auquel second cas, cette règle en l'état n'existe bien que pour que mon Tautulli communique avec mon Plex. Mais je ne comprends pas la différence avec la règle qui autorise tout ce qui vient du réseau local du coup (puisqu'on ne déclare pas de destination, j'ai envie de comprendre que tout est destination possible du coup non ?)

Alors en poussant un peu, je me suis rendu dans Service > Compose > Network je me suis rendu compte que chacun de mes conteneurs Docker a sa propre adresse IP. Par exemple, l'adresse de mon Tautulli semble être 172.19.0.2/16. Donc je peux déclarer une ligne comme celle-ci désormais :

Capture d’écran (5).png
Toujours dans ma compréhension de néophyte, cette règle voudrait dire "ce qui vient de Tautulli vers le LAN du NAS sur le port de Plex c'est autorisé". Et cette règle fonctionne.

En soit cette règle me convient du coup puisqu'elle coupe complètement court à la première hypothèse soulevée tout à l'heure. Pour autant, ça ne m'a pas franchement l'air orthodoxe comme manière. Et elle supposerait que je doive déclarer X règles pour que chacun de mes conteneurs docker communiquent entre eux comme avant. C'est fastidieux et autant d'occasions de se tromper. Il doit y avoir un meilleur moyen de faire, mais lequel ?

EDIT: Bon, je viens de comprendre que mon Docker a créé un nouveau network a chaque conteneur (format "NomConteneur_default"). Donc une adresse IP chacun. Donc quand je "DROP ALL INPUT" à la fin de mes règles firewall, les networks docker qui n'ont pas été déclarés auparavant sont drop.
Il faut que je comprenne comment les networks docker fonctionnent pour regrouper tout ça..

EDIT2: C'était totalement ça. J'ai dû éditer tous mes conteneurs docker pour les grouper sous un même network (j'ai suivi la documentation ici). J'ai toutefois laissé mon plex en "network_mode: host" comme dans les tutos d'Evo, comme ça l'accès local n'était pas modifié et je n'avais pas besoin de faire le tour de tous les appareils connectés de la maison pour changer l'IP :rolleyes:😇
Du coup, la règle INPUT de mon firewall ressemble à celle pour mon LAN ou pour le VPN (cf au dessus). J'autorise la range d'IP du network docker en INPUT ALL et c'est bon, tout communique parfaitement !
Dans une telle configuration, je me demande si watchtower va encore pouvoir mettre à jour tant les applications qui se trouvent dans le network docker que celles qui ne s'y trouvent pas. Je vais suivre tout ça de près pour voir !
 
Dernière édition: