Digression Installation parefeu (iptables & ip6tables) "pour les nuls"

Support Debian
#494

OK, je commence à saisir le débat sur ICMP, ouf :slight_smile:.

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) ?

#495

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 ACCEPT

Mon 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 :stuck_out_tongue: -
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 :wink:

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’

#496

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 :

  • Si vous utilisez SSH
  • libellé de la règle
  • Si vous installez un serveur HTTP
  • libellé de la règle
  • etc.

Questions subsidiaires :

  • Est-il souhaitable d’axer cette discussion sur la concaténation IPv4/IPv6, ou faut-il proposer aussi des réponse “IPv4 uniquement” ?
  • Si vous êtes de mon avis, doit-on continuer sur le présent fil, avec en tête, une référence à la page de début de cette discussion, ou est-il préférable d’ouvrir un autre fil ?

À votre sagacité !

#497

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 ?! :wink:

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 :stuck_out_tongue:

@la vôtre! (de sagacité)

#498

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 :slight_smile:.

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 !

1 J'aime
#499

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 :wink:

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 :wink:
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. :wink:

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’)

1 J'aime
#500

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.

1 J'aime
#501

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é :stuck_out_tongue:

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 -

#502

Je ne connaissais pas et je n’ai jamais porté ces deux ports sur mon parefeu.
Je viens de voir qu’ils géraient (certainement pas le bon terme) BOOTP server et BOOTP client.
Qu’est-ce exactement ?

#503

BOOTP est l’ancêtre de DHCP qui utilise les mêmes ports.

Réponse de Normand : une qui ne gêne pas l’usage normal que tu comptes faire tout en préservant les ressources. Non, je ne me mouille pas, mais il n’y a pas de réponse universelle.

Avec la correspondance length. Mais cela risque de ne pas être efficace en IPv6 si la limite de taille est supérieure à la taille maximum des paquets (MTU) car les paquets de taille supérieure sont fragmentés et chaque fragment a une taille inférieure ou égale à la MTU. (En IPv4 le problème est masqué par conntrack qui réassemble les fragments).

#504

A priori (mais ça m’étonne que tu sois passé à coté), il y a le module nf_conntrack_ipv6 qui peut/doit (?) procèder lui aussi à une defragmentation de l’ipv6.
Mais c’est juste ce que j’ai trouvé sur wikipedia par curiosité: je n’ai rien trouvé détaillant comment ça marche, et l’info peut dater de l’ipv6 expérimental et trainer là.

#505

[mode delirium:engage]
Bon, Monsieur le Normand, beh oui, Pascal Le Normand :stuck_out_tongue: - alors, là, PTDR :smiley: ; suis peut-être “sous influence”, mais ça ne m’empêche pas d’avoir de l’humour … hihihihihi-
mais non, pas Le Normand, puisqu’on te dit Hambourg … Quoi, de Hambourg ? mais non … tsss, laisse tomber, c’est pas grave :smiley: -
y comprend rien lui, alors … ouais, c’est normal, fais pas attention. :stuck_out_tongue:
[/mode delirium:ended]

Je me doute qu’il n’y a pas de réponse universelle, le propos est de comprendre justement comment “faire la recette”, quels éléments prendre en compte …
Exemple : choisir 3/s, soit, mais pourquoi, et pourquoi pas 10/s … etc, etc …

Or, ça, personne ne veut livrer ce genre d’informations.

Ok, creusons … un début de piste :stuck_out_tongue:
Merci

#506

C’est un point que je n’ai pas encore réussi à éclaircir. Du fait qu’un routeur IPv6 ne doit pas fragmenter, le conntrack IPv6 ne faisait qu’un réassemblage “virtuel”, et ensuite les fragments originels poursuivaient leur chemin. Ça a un peu changé depuis le noyau 3.7 et l’introduction du NAT IPv6, cf. la description suivante extraite du changelog :

commit 4cdd34084d539c758d00c5dc7bf95db2e4f2bc70
Author: Patrick McHardy kaber@trash.net
Date: Sun Aug 26 19:13:58 2012 +0200

netfilter: nf_conntrack_ipv6: improve fragmentation handling

The IPv6 conntrack fragmentation currently has a couple of shortcomings.
Fragmentes are collected in PREROUTING/OUTPUT, are defragmented, the
defragmented packet is then passed to conntrack, the resulting conntrack
information is attached to each original fragment and the fragments then
continue their way through the stack.

Helper invocation occurs in the POSTROUTING hook, at which point only
the original fragments are available. The result of this is that
fragmented packets are never passed to helpers.

This patch improves the situation in the following way:

- If a reassembled packet belongs to a connection that has a helper
  assigned, the reassembled packet is passed through the stack instead
  of the original fragments.

- During defragmentation, the largest received fragment size is stored.
  On output, the packet is refragmented if required. If the largest
  received fragment size exceeds the outgoing MTU, a "packet too big"
  message is generated, thus behaving as if the original fragments
  were passed through the stack from an outside point of view.

- The ipv6_helper() hook function can't receive fragments anymore for
  connections using a helper, so it is switched to use ipv6_skip_exthdr()
  instead of the netfilter specific nf_ct_ipv6_skip_exthdr() and the
  reassembled packets are passed to connection tracking helpers.

The result of this is that we can properly track fragmented packets, but
still generate ICMPv6 Packet too big messages if we would have before.

This patch is also required as a precondition for IPv6 NAT, where NAT
helpers might enlarge packets up to a point that they require
fragmentation. In that case we can't generate Packet too big messages
since the proper MTU can't be calculated in all cases (f.i. when
changing textual representation of a variable amount of addresses),
so the packet is transparently fragmented iff the original packet or
fragments would have fit the outgoing MTU.

Le plus sûr, c’est encore de faire des tests pour vérifier.

Parce que c’est suffisant pour ton besoin que tu es le seul à pouvoir définir.

#507

Si on doit débattre sur le présent fil, il serait souhaitable que tu ajoute une réponse dans ce sens avec le lien vers ici.
Sinon, les demandes vont fuser dans T&A.

Ton œuvre me semble parfaite mais j’attends la vérification et le feu vert du Chef pour l’appliquer à mon futur serveur.

#508

C’est fait !

Loin s’en faut, je suis justement en train de me relire et corriger pour essayer de prendre en compte tout ce qui a été dit par PascalHambourg et PengouinPdt au-dessus.

#509

Je n’ai pas encore tout lu mais une petite info mineure en passant à prendre en compte pour la partie réinitialisation du script (clean), assez ancienne mais peut-être méconnue. Depuis le noyau 2.6.36, la table nat a aussi une chaîne INPUT.

#510

OK, merci à @PascalHambourg et @PengouinPdt pour les conseils :slight_smile:.

J’ai tenté de tout intégrer dans le T&A, et je pense qu’on est bons ! La seule chose que je ne comprends toujours pas (et qui n’est donc qu’un bête copier/coller d’un post de Pascal) sont les règles NDP en icmpv6. Il y a donc peut-être des choses à y corriger.

Si vous pouviez faire une petite relecture, ça me rassurerait ! À vot’ bon cœur !

Édit : rappel de l’URL du T&A : https://www.debian-fr.org/t/pare-feu-ipv4-ipv6-versions-bureau-et-serveur.

#511

Tu as lu cela où ?
Le manpage 1.4.21 n’en parle pas !

#512

@seb-ksl: ça me semble correct …
Juste un léger détail, dans les règles ND-IPv6 pour serveur, ajoute une ligne vide entre les écritures INPUT et celles concernant OUTPUT … il m’a fallu quelques secondes pour comprendre la différence ténue … histoire d’aérer :wink:

#513

C’est fait :wink: