Vous n'êtes pas identifié(e).
Dernière modification par fab34080 (18-07-2019 21:32:31)
Hors ligne
Hors ligne
Hors ligne
Si j'ai bien compris un pare feu sert à TOUT interdire SAUF ce que l'on a besoin.
Non, pas forcément. Pour commencer, "pare-feu" est une notion assez vague qui peut recouvrir des choses différentes. Nftables et son prédécesseur iptables sont des filtres de paquets. Ufw n'est qu'un enrobage d'iptables. Il existe d'autre méthodes pour contrôler les communications réseau, par exemple au niveau socket (ça doit être faisable avec SELinux), ou par TCP wrapper pour les services TCP.
Si j'ai un serveur pour héberger un site, je dois donc ouvrir le port HTTP ?
Si j'ai un site sécurisé, je dois ouvrir le port HTTPS ?
"Ouvrir un port", ça ne veut rien dire de concret, notamment pour un filtre de paquets qui se borne à accepter ou bloquer des paquets. Il faut raisonner en terme de flux puis de paquets.
Dernière modification par raleur (19-07-2019 23:26:12)
Il vaut mieux montrer que raconter.
Hors ligne
Hors ligne
Je n'ai jamais utilisé IPtables... et comme je debute je souhaite commencer directement sur NFtables puisque il semble que bebian migrera vers NFtables.
Sache néanmoins qu'iptables ne sera pas retiré dans un avenir proche, et qu'il y a beaucoup plus de personnes connaissant iptables et susceptibles de t'aider à l'utilser que nftables.
J'ai compris que NFtables est juste une interface et pas un pare feu.
Non, nftables n'est pas une interface mais un filtre de paquet, un type de pare-feu.
La première question est que peut (ou doit) bloquer un pare feu :
des IP, des Ports, des protocoles, des programmes
Encore une fois, bloquer une adresse ou un port est une notion vague qui peut se faire de différentes façons à différents niveaux de la pile réseau.
Un filtre de paquets comme nftables ne peut bloquer que des paquets en fonction de leurs caractéristiques (protocole, adresses IP source et destination, ports source et destination si applicable au protocole... et bien d'autres). Ce n'est pas toujours suffisant pour déterminer si un paquet est légitime ou pas, notamment quand il répond à un autre paquet. On doit alors utiliser d'autres informations liées aux paquets comme le suivi des "connexions" auxquelles les paquets appartiennent.
Quant à savoir ce qu'un pare-feu doit bloquer, ça dépend de tes besoins. Et donc de ta capacité à définir clairement tes besoins.
Par exemple si tu veux interdire à un programme spécifique de communiquer avec l'extérieur, un filtre de paquets n'est pas le bon outil.
Dernière modification par raleur (20-07-2019 13:04:49)
Il vaut mieux montrer que raconter.
Hors ligne
Hors ligne
Hors ligne
Donc on bloque tout sauf les 3 ports, ou déjà la je fais fausse route ???
Il faudra aussi le suivi de connexion rien que pour faire les mises à jour (appelé contrack).
Donc il te faut autoriser le trafic entrant sur les ports http et https, sur le port ssh
que tu as choisi uniquement pour l'adresse de ton pc (à condition d'avoir une ip fixe).
Autoriser les connexion sortantes et autoriser les connexions relatives à ces connexions
(contrack). Faire une redirection des ports http et https de ta boxe sur le serveur (où
le traffic entrant sur ces ports est autorisé.
Il faut aussi autorisé certains paquets icmp (au moins les ping depuis ta machine).
Si ton serveur obtiens son adresse via dhcp, il faut bien penser à autoriser les traffic depuis
le routeur sur le port 68 (si je ne me trompe pas).
Avec tout ça, tu as un filtre de paquets minimal. Mais cela ne veut pas dire que tu sois
à l'abri des ennuis pour autant. Ce qu'il faire aussi, c'est éviter d'avoir des daemons qui écoutent
(listen) sur ton interface réseau. Il faut bien comprendre que la redirection des ports http et https
depuis le routeur vers ton serveur fait que c'est comme si ta machine était exposé directement
au moins pour ces deux ports. Le plus fragile dans ce genre de configuration ça sera le serveur
web, et surtout php, et ça, le filtre de paquets ne peut rien y faire.
Hors ligne
sous la forme
1°) table inet filter -> indique que l'on utilise un FILTRE applicable au IPv4 et IPv6
2°) chain input -> indique que la règle s'applique aux entrées
3°) type filter hook input priority 0; policy accept; -> le filtre entrée sera de priorité maximale (s'appliquera avant d'autre filtre annexe).
4°) ... -> on définira les règles qui laisse passer les paquets
5°) drop -> on bloque tout le reste (tout pour le moment)
Voila le début de la réflexion, dans l'attente de vos précisions et rectifications
Hors ligne
Donc on bloque tout sauf les 3 ports, ou déjà la je fais fausse route ?
Tu fais fausse route en parlant de bloquer des ports, je l'ai déjà écrit. Il faut raisonner en flux.
Un exemple : si tu ne vas te connecter en SSH que depuis une adresse ou une plage d'adresses particulière (ex : le réseau local) alors tu ne devrais autoriser les connexions SSH entrantes que depuis cette source. Du coup on ne peut plus simplement parler de port ouvert ou bloqué. Mais on peut raisonner en flux, par exemple :
- autoriser les connexions SSH entrantes depuis telle adresse
- autoriser les connexions HTTP et HTTPS entrantes depuis n'importe quelle adresse
et ainsi de suite.
Il faudra aussi le suivi de connexion rien que pour faire les mises à jour (appelé contrack).
Quelles mises à jour ?
Autoriser les connexion sortantes et autoriser les connexions relatives à ces connexions (contrack).
Le suivi de connexion ne concerne pas que les connexions relatives, mais tous les paquets émis et reçus appartenant ou liés aux connexions autorisées entrantes et sortantes.
Il faut aussi autorisé certains paquets icmp (au moins les ping depuis ta machine).
Le ping ICMP est optionnel. Il n'est pas nécessaire d'un point de vue opérationnel. En revanche certains types de messages d'erreur ICMP sont indispensables au bon fonctionnement de TCP/IP.
Il vaut mieux montrer que raconter.
Hors ligne
Quelles mises à jour ?
À ton avis ?
e ping ICMP est optionnel. Il n'est pas nécessaire d'un point de vue opérationnel. En revanche certains types de messages d'erreur ICMP sont indispensables au bon fonctionnement de TCP/IP.
Alors il faudrait citer précisément quels sont ces messages ICMP. Et dire pourquoi cela, c'est à dire
le rapport entre TCP, UDP et ICMP et le rapport entre le routage et ICMP avec une explication claire.
(désolé, si ce n'est pas assez précis pour toi, voir le commentaire en dessous).
@raleur et puis tant qu'à faire, tu devrais rédiger une documentation dans le wiki en ce qui concerne
les concepts utilisés pour TCP/IP avec des exemples parlants et précis. Sinon tes interventions
me donnent le sentiment que tu nous prend du haut de ta connaissance, ce n'est vraiment pas
constructif.
Hors ligne
Dernière modification par fab34080 (27-07-2019 08:00:36)
Hors ligne
Hors ligne
Quelles mises à jour ?
À ton avis ?
Je ne sais pas, c'est pour cela que je demande. Si tu veux parler des mises à jour de paquets de la distribution, je ne vois pas le rapport particulier avec le suivi de connexion.
Je trouve que l’image avec le train, les wagons, les points d’aiguillages, les gares (ports) le tout roulant sur des lignes de chemin de fer (rj45) semble une image explicite
Cette image n'est pas très représentative car chaque paquet voyage indépendamment des autres, il n'y a pas de train avec des wagons accrochés les uns aux autres, et un port TCP ou UDP n'a rien à voir avec une gare.
Il vaut mieux montrer que raconter.
Hors ligne
Je ne sais pas, c'est pour cela que je demande. Si tu veux parler des mises à jour de paquets de la distribution, je ne vois pas le rapport particulier avec le suivi de connexion.
Ben essaies donc de mettre une machine à jour pour laquelle seul les connexions sur le port 22
est autorisées (en entrée donc), et aussi pour laquelle toutes les connexions sortantes sont autorisées
mais sans suivis de connexions. Les mises à jour des paquets seront impossibles. C'est un truc que j'ai déjà
vu, c'est pour ça que j'en parle.
Hors ligne
Cette image n'est pas très représentative car chaque paquet voyage indépendamment des autres, il n'y a pas de train avec des wagons accrochés les uns aux autres, et un port TCP ou UDP n'a rien à voir avec une gare.
Alors qu'elle est la bonne image ?
Hors ligne
Le ping ICMP est optionnel. Il n'est pas nécessaire d'un point de vue opérationnel. En revanche certains types de messages d'erreur ICMP sont indispensables au bon fonctionnement de TCP/IP.
Quelles sont ces messages ICMP absolument indispensables ?
Hors ligne
Le projet YunoHost pourrait vous intéresser.
Je ne vois pas le rapport ? J'ai peut-être mal cherché… ou alors c'est du spam ?
Hors ligne
toutes les connexions sortantes sont autorisées mais sans suivis de connexions
Autoriser les connexions sortantes (donc les paquets aller et retour appartenant à ces connexions) sans faire appel au suivi de connexion, c'est quelque peu risqué. Mais néanmoins faisable dans des conditions de sécurité relatives si les adresses des serveurs distants sont identifiées (ce qui peut être le cas des serveurs de mises à jour) : on peut alors filtrer sur l'adresse source, le port source et la plage de ports destination des paquets entrants, c'est mieux que rien.
Toutefois, cela ne répond pas à ma question : en quoi cela concerne-t-il spécifiquement les mises à jour de paquets (je rappelle que tu as écrit "rien que pour faire les mises à jour") ou même n'importe quel type de connexion sortante ? Le suivi de connexion est utile également pour les connexions entrantes. On ne va pas laisser passer n'importe quel paquet entrant sous prétexte qu'il est destiné à un port ouvert en écoute, ni n'importe quel paquet sortant sous prétexte qu'il a comme port source un port ouvert en écoute.
Alors qu'elle est la bonne image ?
Je ne suis pas sûr qu'il existe une analogie satisfaisante. Peut-être des coursiers qui utilisent différents moyens de transport pour livrer des colis à des destinataires (adresse du bâtiment = adresse IP, numéro de porte dans le bâtiment = port).
Quelles sont ces messages ICMP absolument indispensables ?
Les types d'erreur qui signalent un problème ayant empêché qu'un paquet atteigne sa destination :
- destination unreachable
- parameter problem
- time exceeded
J'en profite pour rappeler que la saine gestion de ces paquets par le pare-feu requiert également le suivi de connexion (état RELATED).
En IPv6, il y a un type d'erreur supplémentaire : packet too big. Selon le type de liaison et la méthode de configuration, il peut être aussi nécessaire d'accepter certains types du sous-protocole NDP.
Dernière modification par raleur (27-07-2019 20:06:34)
Il vaut mieux montrer que raconter.
Hors ligne
Autoriser les connexions sortantes (donc les paquets aller et retour appartenant à ces connexions) sans faire appel au suivi de connexion, c'est quelque peu risqué. Mais néanmoins faisable dans des conditions de sécurité relatives si les adresses des serveurs distants sont identifiées (ce qui peut être le cas des serveurs de mises à jour) : on peut alors filtrer sur l'adresse source, le port source et la plage de ports destination des paquets entrants, c'est mieux que rien.
Bref, c'est chiant à configurer tout étant peu sûr, je préfère le suivis de connexions.
Hors ligne
Toutefois, cela ne répond pas à ma question : en quoi cela concerne-t-il spécifiquement les mises à jour de paquets (je rappelle que tu as écrit "rien que pour faire les mises à jour")
Dans ma phrase je n'ai pas dit que c'était spécifiquement pour les mises à jour, mais que
pour celles-ci c'était nécessaire, et je sous-entend que ça peut être aussi pour être chose…
Évidemment ce n'est pas très précis, mais comme il est impossible d'énumérer tous les cas
possibles, cela me semblait une bonne formule, que tu n'as pas comprise.
Hors ligne
Je ne vois pas le rapport ? J'ai peut-être mal cherché… ou alors c'est du spam ?
Il faut cliquer sur le lien pour savoir qu’est-ce que c’est.
Je découvre debian et je souhaite donc sécuriser mon serveur.
Je débute et ne maitrise pas toutes les notions et principes.
J’en conclus que fab34080 débute
Mon serveur est derrière une box (internet et routeur)
J’en conclus que fab34080 auto-héberge son serveur
Débutant + auto-hébergement = une distribution Linux pour débutant pour faire ses propres serveurs.
Donc j’en conclus que Yunohost pourrait intéresser cette personne.
Petit extrait du site (au cas où)
YunoHost est un système d’exploitation serveur visant à rendre accessible l’auto-hébergement à autant de personne que possible, sans délaisser la qualité et la fiabilité du logiciel.
-> https://yunohost.org/whatsyunohost_fr
Mais peut-être que j’ai mal compris ce que cherche à faire fab34080.
Hors ligne
Donc j’en conclus que Yunohost pourrait intéresser cette personne.
Ce n'est pas le sujet du post. Mais bon je suppose que ça peut être intéressant.
Hors ligne
Hors ligne