Journal Affiner le filtrage avec Iptables et d'autres choses aussi...

Posté par  .
Étiquettes : aucune
0
25
oct.
2004
Bonjour à tous,

Voilà je cherche à affiner le filtrage avec Iptables, j'entends par là mettre à DROP la politique par défaut des tables nat et mangle et autoriser vraiment au cas par cas les paquets respectant ma propre politique de sécurité.

Cela me paraît quand même assez long à faire, et est-ce vraiment utile ?

A partir du moment où FORWARD est bien paramétrée, on risque pas grand chose ?

Et puis faut pouvoir prévoir toutes les formes de paquets qui sont succeptibles de traverser la machine...

Je me posais aussi une question sur l'utilité des states NEW, RELATED, ESTABLISHED avec le protocole UDP, comme il n'y a pas de suivi de connexion avec ce protocole, Linux intègre t'il un système de timer ?

Une dernière question, cette fois sur la table mangle, quelles sont les limites de son utilisation, j'avais trouvé un exemple sur le net qui permettait d'analyser les en-tête de protocole (couche:application), et qui détectait si vous faisiez du kazaa ou autre chose mais en ne se basant pas sur le numéros de port bien sûr ;-)

merci pour vos réponses

  • # L'utilite des states avec l'UDP

    Posté par  . Évalué à 1.

    Si tu n'as pas d'etat, tu ne sais pas vers qui renvoyer le paquet que tu recois en reponse lorsque tu fais du nat. Donc oui, les etats sur l'UDP c'est utile, et oui, linux implemente un mecanisme de timer, de 20 min je crois par session, pour garder en memoire les infos d'etats.

  • # Ne pas DROPper n'importe où

    Posté par  . Évalué à 1.

    Vouloir adopter une politique de DROP pour toutes les tables de netfilter, c'est aller à contre-sens de la division en plusieurs tables. Plus clairement, c'est à filter de faire ce boulot là, et ce devrait donc être la seule table avec une politique bloquée sur DROP [à moins que j'ai râté un gros train].

    Plus d'info dans les docs là : http://www.frozentux.net/(...)
    et en particulier : http://iptables-tutorial.frozentux.net/iptables-tutorial.ps.gz(...) [qui n'a pas bougé depuis que j'ai fait ma config, donc pour le train, ça doit être bon ;) ]

    Pour mangle, ma config est trop basique pour que j'en aie la moindre utilité.

  • # Trop de complexité nuit à l'éfficacité ?

    Posté par  (site web personnel) . Évalué à 2.

    Bonjour,

    mettre à "DROP" les rêgles par défaut de la table "mangle", c'est effectivement efficace. Mais il te faudra ré-écrire toutes tes rêgles en double, dans FILTER et MANGLE, pour que tes paquets puissent passer.

    Bref, cela va doubler l'occupation CPU pour le fonctionnement de Netfilter, et ralentir un peu tes temps de réponse sur le réseau. Je ne pense pas que ce soit une bonne solution. En terme de sécurité, je ne pense pas que le gain soit important, a moins qu'il n'existe des exploits contre la couche "filter" de Netfilter, et que ceux-ci ne marchent pas pour "mangle".

    A mon avis, le plus simple est de :
    - mettre à "DROP" les rêgles par défaut de "FILTER"
    - laisser à "ACCEPT" les rêgles par défaut de "NAT" et "MANGLE"
    - ne laisser passer que ce que as besoin, via les INPUT, OUTPUT et FORWARD de "FILTER".

    J'ai écris une doc assez complète sur Netfilter et la sécurité sous Linux : http://olivieraj.free.fr/fr/linux/information/firewall/(...)

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.