Ping niet mais internet fonctionne ?

Support Debian
#21

[quote=“panthere”]iptables -A INPUT -p 1 -m limit --limit 30/h --limit-burst 30 -j ACCEPT
suffi :slightly_smiling:[/quote]
Suffit pour quoi, au juste ?

Personnellement je ne vois pas l’intérêt de cette règle. À mon avis, elle n’est ni nécessaire ni suffisante à une politique de filtrage efficace de l’ICMP.

Les types de message ICMP peuvent se diviser en trois catégories :

  • Les messages de requête. Exemple : echo-request (ping). Ils ont l’état NEW. On peut écrire une règle pour chaque type de requête qu’on veut accepter, avec éventuellement des limites (en fréquence, taille…). Pour un usage classique, je ne vois guère que le type echo-request à prendre en compte si on veut autoriser le ping en entrée. Par contre une limite à 30/h me paraît très basse. Par exemple :
  • Les messages de réponse. Exemple : echo-reply (réponse au ping). Ils ont l’état ESTABLISHED lorsqu’ils correspondent à une requête émise qui a été autorisée, et l’état INVALID dans le cas contraire. Il n’y a pas lieu de les limiter puisqu’ils sont attendus. Ces messages sont pris en compte si on a la règle classique suivante :
  • Les messages d’erreur. Exemple : destination-unreachable. Ils ont l’état RELATED lorsqu’ils correspondent à une connexion existante qui a été autorisée, et l’état INVALID dans le cas contraire. Il n’y a pas lieu de limiter leur fréquence. Ces messages sont pris en compte si on a la règle classique précédente.
#22

autrement dit, puisque je n’ai qu’une utilisation classique de base, de mon internet, je me limite à supprimer la ligne -A INPUT -p icmp -j DROP
qui fait double emploi.

#23

[quote=“ricardo”]autrement dit, puisque je n’ai qu’une utilisation classique de base, de mon internet, je me limite à supprimer la ligne -A INPUT -p icmp -j DROP
qui fait double emploi.[/quote]
À mes heures perdues, j’avais étudié une approche selon laquelle si la politique par défaut d’une chaîne était à DROP, on pouvait se passer totalement de règles DROP. La motivation sous-jacente était le souhait qu’un jeu de règles ne devait pas devenir moins sûr si on lui enlevait n’importe laquelle de ses règles, par exemple à cause d’une erreur dans l’exécution du script qui ferait qu’une règle n’a pas été créée. Néanmoins dans certains cas cette approche conduisait à un jeu de règles assez compliqué.

#24

[quote=“PascalHambourg”][quote=“ricardo”]autrement dit, puisque je n’ai qu’une utilisation classique de base, de mon internet, je me limite à supprimer la ligne -A INPUT -p icmp -j DROP
qui fait double emploi.[/quote]
À mes heures perdues, j’avais étudié une approche selon laquelle si la politique par défaut d’une chaîne était à DROP, on pouvait se passer totalement de règles DROP. La motivation sous-jacente était le souhait qu’un jeu de règles ne devait pas devenir moins sûr si on lui enlevait n’importe laquelle de ses règles, par exemple à cause d’une erreur dans l’exécution du script qui ferait qu’une règle n’a pas été créée. Néanmoins dans certains cas cette approche conduisait à un jeu de règles assez compliqué.[/quote]
Là on entre ds le domaine de la haute philosophie, ce qui n’est pas pour me déplaire mais je n’ai pas le tps nécessaire actuellement pour ce genre d’échanges. :confused: