Non, excepté DNS dans la plupart des cas.
Non, pas obligatoirement.
Et arrêtez de parler de port “ouvert”, c’est ambigu. Ce sont les sockets qui ouvrent des ports, pas le pare-feu. Celui-ci ne fait qu’autoriser ou bloquer des paquets ou des connexions. D’autre part il faut préciser si c’est en entrée ou en sortie. Un poste client qui fait des connexions HTTPS sortantes n’a pas besoin d’autoriser les paquets entrants à destination du port 443.
@PascalHambourg : merci, j’intègre tout ça dans la journée !
Je ne connaissais pas, je vais l’ajouter en facultatif.
Comme déjà répondu par PascalHambourg, il ne faut pas confondre l’entrée (INPUT) et la sortie (OUTPUT). Pour une machine de bureau, je propose une stratégie (POLICY) OUTPUT sur ACCEPT. Donc tout est autorisé à sortir de la machine. En revanche, à moins que cette machine ne soit un serveur HTTP(S), DNS, DHCP, NTP ou autre, elle n’a aucune raison d’accepter des requêtes en INPUT sur ces ports-là.
Personnellement, je connais très bien la différence entre les deux … et, il est vrai que j’ai oublié de le préciser dans mon post précédent. Désolé, quand on a l’habitude de certains sujets, et de certaines évidences - où l’on n’oublie que nos évidences ne sont pas celles des autres 
@Pascal, toujours dans la précision ultime, tu es 
En effet, tu as raison de préciser - cela s’appelle de notre part un abus de language.
@seb-ksl: Par contre, là où je ne suis pas d’accord - et je viens de relire plus précisément ton tuto - en effet, tu as autorisé par défaut toutes tes sorties sur les stations.
Personnellement, je ne le ferais pas - c’est pourquoi dans mon post précédent, j’ai écrit d’ouvrir certains ports par défaut, et là je le précise, en sortie …
@Pascal, je suis d’accord avec toi de ne pas préciser les ports en sortie, seulement et si seulement, toutes les sorties sont autorisées - ce qui est le cas dans le tuto de seb-ksl - que j’avais seulement survolé.
Concernant la partie serveur, autorisée en sortie le port 443 est rarement utile, dans la pratique, cela te servira pour surfer sur Internet … les serveurs de package ne sont accessibles que sur le port 80, voire FTP, mais pas HTTPS ; donc, surfer sur Internet depuis le serveur, sans besoin réel, personnellement je n’en vois pas l’utilité - mais là, encore, je peux me tromper
En tout cas, je tiens à le dire à nouveau, c’est du bon boulot de présentation, voire d’explications. Merci !
Quel terme suffisamment court employer :
autoriser ?
autre ?
Sur mon serveur j’ai besoin des 80/443 sortants parce que j’ai une page (un agrégateur de flux RSS) qui envoie des requêtes HTTP et HTTPS à travers wget pour récupérer le contenu des flux.
Libre à toi de régler la POLICY d’OUTPUT à DROP et d’autoriser les sorties port par port, je l’avais fait au début 
.
Mais ça fait un moment que je suis repassé en ACCEPT, pour une simple raison : trop prise de tête sur une machine de bureau classique. À chaque installation d’un nouveau programme tu dois faire attention à ce qu’il soit bien autorisé à communiquer sur un/des port(s) particulier(s), ce qui n’est pas toujours bien documenté par l’auteur du programme d’ailleurs. Mon dernier exemple en date : qarte. Dans son cas, il fallait “simplement” le lancer depuis un terminal en mode debug pour suivre ses requêtes, et notamment le port. Pour d’autres programmes je me suis retrouvé à enchaîner des netstat pour voir ce qu’ils essayaient de faire qui était bloqué de mon côté. C’est vite pénible, d’autant que je ne suis pas persuadé de l’utilité de la chose. Si quelqu’un a une bonne raison à avancer… ?
En revanche je me suis contraint à l’exercice sur mon pare-feu serveur : si tu as bien regardé, toutes ses POLICY sont à DROP. Je l’ai fait parce que je pense que c’est une bonne chose de “tout” contrôler sur un serveur, en tout cas ça force à savoir quel service fait quoi à travers quel port. Je peux me tromper, mais je pense aussi que ça évite d’être transformé trop facilement en bot, puisque la machine ne peut pas envoyer ce qu’on veut à travers tous les ports (bien que le 80 ouvert en sortie doive pouvoir être suffisant pour ça).
Voilà, évidemment ce sont des choix personnels qui peuvent tout à fait se discuter .
Sans la règle iptables -A INPUT -p icmp -j ACCEPT, la machine répondra toujours au ping ? Ou peut-être que tu veux suggérer d’être plus fin dans le filtrage des paquets ICMP ? J’avoue mon incompétence à ce sujet.
Idem, j’ai peur de ne pas comprendre. Je me suis basé sur ce qui a été dit dans le post sur IPv6 ici, visiblement maladroitement. Je vais essayer de me rencarder un peu sur l’ICMPv6, en attendant n’hésite pas à proposer des corrections.
Pour être + fin relativement à ICMP, et donc ne pas autoriser tout le flux correspondant, ta règle se transforme ainsi, pour ta station :
iptables -A INPUT -p icmp --icmp-type echo-reply -m conntrack --ctstate ESTABLISHED -j ACCEPT
iptables -A INPUT -p icmp --icmp-type echo-request -m conntrack --ctstate ESTABLISHED -j ACCEPT
iptables -A OUTPUT -p icmp --icmp-type echo-request -m conntrack --ctstate NEW,ESTABLISHED -j ACCEPTBien sûr, si tu veux autoriser qu’une machine quelconque te ping, il faut rajouter l’état ‘NEW’ à la deuxième règle …
Sauf que si tu places ces règles d’entrées liées à ICMP, après l’écriture définissant l’acceptation des règles relatives aux états ‘RELATIFS’, ‘ETABLIES’, elles n’ont plus lieu d’être … d’ailleurs personnellement, j’aurais mis en premier cette règle, juste après celles relatives à localhost.
De même, dans le contexte de station la règle de sortie n’a pas lieu, puisque tu as écrit que tout devait sortir
…
Juste pour info, voici les règles before écrite dans le projet ufw lors de l’installation :
# règles INPUT
-A ufw-before-input -p icmp --icmp-type destination-unreachable -j ACCEPT
-A ufw-before-input -p icmp --icmp-type source-quench -j ACCEPT
-A ufw-before-input -p icmp --icmp-type time-exceeded -j ACCEPT
-A ufw-before-input -p icmp --icmp-type parameter-problem -j ACCEPT
-A ufw-before-input -p icmp --icmp-type echo-request -j ACCEPT
Il n’y a pas de règles en sortie, car par défaut les ‘policies’ sont allouées.
Voili, voilou … si ça peut aider
Et, oui, comme le dit PascalHambourg, je suis surpris aussi que tu les ai écrites pour icmpv6, et pas icmp … ?
Mais tu l’expliques toi-même 
Réponses en vrac.
Je ne me rappelle pas avoir écrit cela. Si tu fais référence à ma réponse “Non, excepté DNS dans la plupart des cas”, cela n’avait rien à voir, je contestais seulement que DHCP, NTP, mDNS fassent partie du minimum obligatoire.
Au risque de te contredire encore, il existe un transport HTTPS optionnel pour APT : cf. paquet apt-transport-https.
Oui, ou accepter, laisser passer. Et surtout, préciser de quoi on parle. Comme si le filtrage n’était déjà pas assez compliqué en soi, les règles iptables traitent des paquets individuels alors que les humains ont tendance à raisonner avec des connexions (qui mettent en oeuvre des paquets émis et reçus).
Oui, je suggère d’être plus fin. Sinon, à quoi bon toutes les autres règles pour des types ICMP et ICMPv6 spécifiques ?
A propos de cette règle, à quoi sert-elle au juste sans l’état NEW ?
D’autant plus qu’il y a déjà une règle générale qui accepte tous les paquets dans l’état ESTABLISHED. (Au passage, les paquets ICMP echo-request dans l’état ESTABLISHED sont plutôt rares).
Juste pour info, le type source-quench a été déclaré dangereux, obsolète et déconseillé.
Question bête, dont la réponse à due être déjà donnée mais …
Quels sont les dangers qu’il y a à être “pingué”, pour vouloir l’empêcher ?
Oui, optionnel … confidentiel … etc, etc, etc …
Qui est réellement informé ?!
Tu n’as pas le sentiment de pinailler, un peu là
Oui, je parlais de cette réponse …
Et, tu peux contester ; mon expérience sait qu’il faut un minima pour une station, en output … 53, 67, 68 …
Et, certains utiles, tels que 80, 443, mDNS, certains ICMP, etc … etc …
Merci de la précision.
Comme quoi, même dans les projets libres officiels, on peut faire certaines bêtises, n’est-ce pas ?!
Et, en effet, le draft IETF 2014 rappelle ceci :
De ce que j’ai compris, simplement le fait de renseigner que ta machine est bel et bien fonctionnelle !
Et, ainsi de “cartographier” ton réseau …
C’est encore et toujours l’histoire du renseignement, ni plus ni moins, et de ce qui peut en être fait, ensuite …
Mais c’est toute la différence, entre un autodidacte - très certainement mal averti -, et un GRAND professionnel comme Pascal, qui encore une fois, corrigera le propos
@Pascal: Je sais pertinemment que je ne fais pas le poids - au moins, je participe avec plaisir ; et tes remontrances nous permettront à tous de nous améliorer réellement. Merci
@ricardo: Je te réponds avec la documentation sus-mentionné ci-dessus :
Comme quoi, c’est mieux de laisser répondre les docs intéressantes …
PS : Si jamais besoin de traduction, c’est avec plaisir que je m’y essayerais, tant bien que mal !
À peu près compris mais la semaine de défense de la langue française, tu pourrais faire l’effort de placer des liens en français.
Faudrait-il qu’ils existent encore
Quoiqu’il en soit le document en question, dit que plutôt de bloquer le flux correspondant au ping, mieux vaut limiter son flux… là, c’est l’usage de l’option ‘-m -limit --limit 1/second’, par exemple.
Sinon, la revue Hackin9 avait sorti en 02/2006 un article intéressant sur l’utilisation et les abus ICMP possibles. Très explicite. Si tu le veux, mail-me, tu sais où me trouver
OK, je commence à saisir le débat sur ICMP, ouf .
Avant d’écrire une bêtise sur le T&A, je vous soumets une version revue des règles relatives à ICMP et ICMPv6, j’attends vos avis pour corriger le T&A.
Ancienne version :
## IPv4 ##
iptables -A INPUT -p icmp -j ACCEPT
## IPv6 ##
ip6tables -t filter -A INPUT -p icmpv6 --icmpv6-type echo-request -j ACCEPT
Nouvelle version :
## IPv4 ##
iptables -A INPUT -p icmp --icmp-type echo-request -m conntrack --ctstate NEW -m limit --limit 1/s --limit-burst 1 -j ACCEPT
# Uniquement pour le script serveur, puisque sur la machine de bureau je laisse tout sortir
iptables -A OUTPUT -p icmp --icmp-type echo-request -m conntrack --ctstate NEW -j ACCEPT
## IPv6 ##
ip6tables -A INPUT -p icmpv6 --icmpv6-type echo-request -m conntrack --ctstate NEW -m limit --limit 1/s --limit-burst 1 -j ACCEPT
# Uniquement pour le script serveur, puisque sur la machine de bureau je laisse tout sortir
ip6tables -A OUTPUT -p icmpv6 --icmpv6-type echo-request -m conntrack --ctstate NEW -j ACCEPT
J’ai un petit doute quand même : en OUTPUT, c’est bien les echo-request qu’il faut laisser passer, pas les echo-reply ?
Si j’ai bien compris, pas besoin de toucher aux règles NDP broadcast ?
En cherchant des sources, je suis tombé sur ce jeu de règles proposé pour limiter le DoS : https://petermolnar.eu/hardening-iptables-config-with-limit-rates/. Vous pensez que ça vaut le coup, dans le script config_firewall pour serveur que je propose, d’ajouter ces limites un peu partout (je pense surtout à 80 et 443) ?
Oui, en effet …
De toute façon, vu les règles que tu as écrites, si un machine interroge ton serveur, elle lui répondra car :
iptables -A OUTPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
(...)
ip6tables -A OUTPUT -m state --state RELATED,ESTABLISHED -j ACCEPTMon avis est que ces règles-ci, tu devrais les mettre bien plus haut, après celles gérant le localhost …
En effet, cela peut être intéressant - sauf si les personnes ne comprennent pas l’intérêt faut d’abord les instruire -
Un autre manière est de filtrer ainsi, par exemple :
$IPT -A intcp -p tcp -m multiport --dports ${HTTP_ports} -m conntrack --ctstate NEW -m recent --name HTTP --set
$IPT -A intcp -p tcp -m multiport --dports ${HTTP_ports} -m conntrack --ctstate NEW -m recent --name HTTP --update --seconds 60 --hitcount 10 -j LOG --log-prefix "IPv4 BAD HTTP: "
$IPT -A intcp -p tcp -m multiport --dports ${HTTP_ports} -m conntrack --ctstate NEW -m recent --name HTTP --update --seconds 60 --hitcount 10 -j DROP
$IPT -A intcp -p tcp -m multiport --dports ${HTTP_ports} -m conntrack --ctstate NEW -m limit --limit 900/s -j ACCEPT -m comment --comment "HTTP,HTTPS"Explications à donner :
=> 1ère règle : toute nouvelle connexion est enregistré dans une variable HTTP
=> 2ème : si dans la minute qui vient, j’ai 10 tentatives de connexion, je log - parce qu’en soit, ce n’est pas normal d’avoir un nombre important de connexions d’une même adresse ip
=> 3ème : le nombre atteint, je DROP - cela peut-être un REJECT avec connexion TCP fermé: '-j REJECT --reject-with tcp-reset’
=> 4ème : le nombre de connexion limit acceptée …
C’est un exemple qui vaut ce que ça vaut … et, là, je m’attends à ce que Pascal le corrige
Mon avis est que tu peux informer d’un laïus sur l’intérêt de l’option ‘limit’, sans pour autant l’écrire - n’oublions pas que c’est un tuto à destination de débutant. Si la personne veut aller plus loin, elle a été informé que cela existe, soit elle viendra en demander plus, et/ou, soit elle ira chercher plus d’informations sur le web.
C’est moi ou le site inetdoc.net est bel et bien tombé, voire fermé définitivement … - c’est bizarre, le ndd a été acheté jusqu’en septembre 2021 -
Autrement, on aurait pu linker justement vers l’information relative à l’option ‘limit’
Je pense que tout ça va tourner à la “cacophonie écrite”.
Ne pensez-vous pas qu’il serait souhaitable de reprendre toutes ces règles générales, UNE par UNE et en deux temps : 1/ Machine Bureau, puis, une fois que l’accord a été trouvé, on passe à - 2/ Serveur.
Quelle serait la liste de ces règles que j’appelle ‘générales’ (mais si vous préférez un autre adjectif : communes, incontournables, etc.) et dans quel ordre devrait-elle être établie ?
-A INPUT -i lo -j ACCEPT
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -p icmp -j ACCEPT
J’en oublie ?
Je ne parle pas là des règles d’autorisation ou de rejet de port ou autres, qui seraient traitées dans un second temps, sous forme :
Questions subsidiaires :
À votre sagacité !
Pour moi, c’est du pareil au même, discuter ici ou sur un autre fil, soit …
Mais si je ne me trompe pas, ce fil a été ouvert justement pour discuter du tuto, en question, n’est-ce pas ?!
Quoiqu’il en soit, je suis pour la clarification des idées - que @seb-ksl fasse le point, comme il l’a fait ce matin, c’est très bien, et vraiment utile.
La concaténation du sujet me va très bien - mais je comprendrais parfaitement que cela soit plus complexe pour d’autres.
Bref, je suis la tendance - et j’espère vraiment ne pas importuner par mes interventions “lettrées”, dont le but est vraiment de partager et de discuter de ce que, même moi, je dois modifier dans ma compréhension des choses
@la vôtre! (de sagacité)
En ce qui me concerne, ça me va comme ça ! J’estime qu’on est précisément en train de débattre d’une version correcte d’un pare-feu basique pour débuter. Si tu veux qu’on crée un fil ceci dit, ça ne me dérange pas outre mesure .
Merci PengouinPdt pour tes interventions, je vais prendre un petit moment ASAP pour relire le script de config entier. Là je m’acharne sur des petits bouts et je perds la vision d’ensemble, ce qui me fait effectivement écrire des règles redondantes et en oublier d’autres. Je reviens rapidement quand j’ai mis tout ça à plat !
De rien, c’est vraiment avec plaisir.
Je n’ai pas la prétention de maîtriser le sujet, mais je dois avouer qu’il m’intéresse
Il y a quelques semaines, j’ai ouvert cet autre fil, que j’ai complété hier soir de mes dernières recherches concernant imcpv6.
J’y ai intégré les commentaires relatifs aux recommandations de filtrage, selon les deux documents cités.
En espérant que cela fasse avancer le débat - sachant qu’on n’est plus dans un contexte débutant
Je ne cache pas que j’attends avec une certaine impatience ce que pourrait en dire @PascalHambourg, sur le fil en question, bien-sûr.
Juste pour info, si j’ai bien compris il y a deux manières d’écrire à-propos d’ICMP IPV6, je cite :
Donc, on peut utiliser invariablement ‘icmpv6’ ou ‘ipv6-icmp’.
De fait, ne pas être surpris de trouver l’une ou l’autre de ces écritures, selon l’auteur d’un tutoriel.
Personnellement, je préfère la deuxième écriture, plus courte … mais c’est mon choix.
Concernant source-quench, dans ufw, je viens de lever un bogue de sécurité :
https://bugs.launchpad.net/ufw/+bug/1558068 (mode privé, car nommé ‘security bug’)
Au moins les lecteurs de cette discussion.
J’assume entièrement de bonne grâce.
Mon expérience me dit le contraire (à l’exception du port 53, je l’ai déjà indiqué).
Une station configurée en statique et non en DHCP n’a pas besoin d’autoriser les ports 67 et 68. D’autre part, les clients DHCP envoient et reçoivent les paquets directement sur l’interface réseau, sans passer par la couche IP et donc sans devoir traverser les règles iptables.
Utiles dans certains cas, oui. Indispensables, non. Je n’ai jamais eu besoin de mDNS et je suis loin d’être le seul. Quant aux messages ICMP, les seuls indispensables sont les types d’erreur qui sont dans l’état RELATED, donc qui n’ont pas besoin de règle spécifique.
En plus de la cartographie, il y a deux types de risques. L’un est lié à l’existence d’éventuelles failles de sécurité qui peuvent être exploitées par tout paquet reçu non sollicité, l’un des exemples les plus connus bien qu’ancien étant le fameux “ping of death” de Windows. L’autre est lié au fait que cette requête déclenche l’émission d’une réponse de même taille, pouvant servir à divers abus du réseau, dénis de service… L’exemple bête avec une victime qui a une connexion ADSL typique 16 Mbit/s descendant 1 Mbit/s montant : il suffit de lui envoyer un flux de ping à 1 Mbit/s pour qu’elle sature elle-même sa voie montante avec les réponses. Il y a d’autres attaques basées sur l’usurpation d’adresse, le broadcast (bien que les OS modernes sont configurés par défaut pour ne pas répondre au ping broadcast). J’approuve la recommandation de limiter le ping entrant. Par contre 1 par seconde, c’est un peu juste puisque c’est la fréquence par défaut des programmes ping. On peut aussi limiter la taille des requêtes à une valeur pas trop basse (2000 octets suffit généralement pour analyser les problèmes de MTU et de fragmentation).
IPv6 n’utilise pas de broadcast mais du multicast.
Je n’ai pas étudié les versions récentes du protocole HTTP, mais une page web pouvant contenir un nombre d’éléments externes (images, feuilles de style, frames…) important, si le navigateur fait une connexion séparée pour télécharger chaque élément ça peut faire beaucoup en pas longtemps. Certes un navigateur peut réutiliser la même connexion pour télécharger plusieurs éléments si le serveur le permet, mais est-ce une obligation ?
D’autre part, comme je l’ai déjà écrit dans d’autres discussions à plusieurs reprises, les limitations basées sur iptables sont sensibles à l’usurpation d’adresse et peuvent être exploitées pour causer des dénis de service. De plus, la correspondance recent a une faiblesse qui permet à un attaquant utilisant l’usurpation d’adresse de se “faire oublier” sans attendre le délai.
PS : Je ne suis pas un “professionnel” du filtrage réseau.
Statique est le mot …
Dans beaucoup de cas, c’est plus le contraire. Il est vrai que mes propos sous-entendaient ce fait -ahhh l’implicite m’a encore piégé
Ahhh ???
Là, tu m’apprends quelque chose. Donc, les règles iptables en question ne servent pas alors ?
Tu conseillerais quoi comme fréquence de limitation ?
Et, tu limites comment la taille des requêtes ?
- désolé, de poser la question, suis sous codéine, là, en ce moment … donc, j’ai un peu plus de mal à réfléchir, je vais quand même essayé de voir ce que je peux trouver -