Très bien faite cette doc, je viens de la parcourir ...
Quelques commentaires:
- Il faudrait que les spécialistes du coupage de cheveux ortho-grammatico-français en fassent une relecture (supprimer les 'malgré que' et autres fautes).
- la partie sur les chaines utilisateur est a mon gout trop rapide.
LE gros avantage de netfilter sur les autres firewalls c'est justement ces chaines qui permettent d'optimiser le temps de parcours de l'arbre de décision. Or dans ce document les chaines utilisateur ne sont utilisées que pour éviter de répéter l'option de LOG par exemple (chaine DropLog). Exemple: Creer des chaines utilisateur par type de routage (exterieur vers dmz, intranet vers exterieur ...) permet d'optimiser le nombre de règles lues pour prendre une décision.
Les chaines utilisateur peuvent aussi servir de compteur de paquets/octets pour faire des statistiques (et de beau graphes avec rrdtool).
- La partie sur le filtrage avec l'adresse IP externe de la machine me semble aussi moyenne (mais c'est sujet a discussion).
Pour optimiser un peu, tu pourrais commencer le script par un test sur l'IP UNE FOIS POUR TOUTE et eviter ainsi de re-tester l'adresse IP dans chaque chaine, ton CPU sera content :-) . Sinon je ne comprends pas bien la remarque: si tu recois le paquet en PPP c'est qu'il a été ROUTE vers toi. Donc l'adresse destination est la tienne ou un broadcast. Comme tu commences tes chaines par jeter tous les broadcast (hein ?) l'adresse est FORCEMENT la tienne. si pas de PPP (cable ...), tu peux valider selon l'adresse MAC de ta carte. Ces 2 techniques permettent de supprimer la dependance du script avec l'adresse ip externe (variable), donc de supprimer la commande "barbare" de lancement. Et surtout de supprimer la necessité de relancer a chaque coupure ADSL (donc re-initialisation des compteurs et surtout perte du tracking de connection, voire passage possible de paquets entre le stop/start de ton script netfilter).
- tu ne mentionnes pas les caractéristiques TROMPEUSES de l'etat NEW. Personnellement je prefere ne pas utiliser du tout le "--state NEW" que je trouve étonament laxiste (je ne suis pas le seul.... google est ton amis)
si j'ai le temps je ferai une relecture exhaustive de ton doc qui est tout de meme très complet, et proposerai des ajouts/modifications ...
Mais avant tout, cela t'interesse-t-il ?
# Re: Documentation: Firewall et sécurité d'un réseau personnel sous Linux
Posté par PLuG . En réponse à la dépêche Documentation: Firewall et sécurité d'un réseau personnel sous Linux. Évalué à 8.
Quelques commentaires:
- Il faudrait que les spécialistes du coupage de cheveux ortho-grammatico-français en fassent une relecture (supprimer les 'malgré que' et autres fautes).
- la partie sur les chaines utilisateur est a mon gout trop rapide.
LE gros avantage de netfilter sur les autres firewalls c'est justement ces chaines qui permettent d'optimiser le temps de parcours de l'arbre de décision. Or dans ce document les chaines utilisateur ne sont utilisées que pour éviter de répéter l'option de LOG par exemple (chaine DropLog). Exemple: Creer des chaines utilisateur par type de routage (exterieur vers dmz, intranet vers exterieur ...) permet d'optimiser le nombre de règles lues pour prendre une décision.
Les chaines utilisateur peuvent aussi servir de compteur de paquets/octets pour faire des statistiques (et de beau graphes avec rrdtool).
- La partie sur le filtrage avec l'adresse IP externe de la machine me semble aussi moyenne (mais c'est sujet a discussion).
Pour optimiser un peu, tu pourrais commencer le script par un test sur l'IP UNE FOIS POUR TOUTE et eviter ainsi de re-tester l'adresse IP dans chaque chaine, ton CPU sera content :-) . Sinon je ne comprends pas bien la remarque: si tu recois le paquet en PPP c'est qu'il a été ROUTE vers toi. Donc l'adresse destination est la tienne ou un broadcast. Comme tu commences tes chaines par jeter tous les broadcast (hein ?) l'adresse est FORCEMENT la tienne. si pas de PPP (cable ...), tu peux valider selon l'adresse MAC de ta carte. Ces 2 techniques permettent de supprimer la dependance du script avec l'adresse ip externe (variable), donc de supprimer la commande "barbare" de lancement. Et surtout de supprimer la necessité de relancer a chaque coupure ADSL (donc re-initialisation des compteurs et surtout perte du tracking de connection, voire passage possible de paquets entre le stop/start de ton script netfilter).
- tu ne mentionnes pas les caractéristiques TROMPEUSES de l'etat NEW. Personnellement je prefere ne pas utiliser du tout le "--state NEW" que je trouve étonament laxiste (je ne suis pas le seul.... google est ton amis)
si j'ai le temps je ferai une relecture exhaustive de ton doc qui est tout de meme très complet, et proposerai des ajouts/modifications ...
Mais avant tout, cela t'interesse-t-il ?