la partie sur les chaines utilisateur est a mon gout trop rapide.
Effectivement, je n'en n'ai que peu parlé. Mais je trouve qu'il est beaucoup moins simple de comprendre un FW Netfilter basé sur des chaînes utilisateurs. Il y a une logique qui, bien qu'efficace, n'est pas facile à appréhender. Et je n'ai pas voulu complexifier encore plus cette partie pour l'utilisateur néophyte.
Les chaines utilisateur peuvent aussi servir de compteur de paquets/octets pour faire des statistiques (et de beau graphes avec rrdtool).
Idem que plus haut : DMZ, extranet, compteur, etc... Cela sort du cadre de la documentation orientée vers les néophytes. Mais ce type de sujet peut faire partie d'un autre chapitre, plus spécifique, destiné aux utilisateurs plus "avancés". C'est une idée à creuser.
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
Je voulais "marteler" dans l'esprit de l'utilisateur néophyte la nécessité de faire des règles les plus strictes possibles. D'où l'importance du cumule des options "-i", "-o", "-s" et "-d". Ce n'est dont certes pas très optimum. Par contre, si l'utilisateur ne fait que copier/coller un seule règle d'un de mes scripts, il aura tout de même une protection acceptable, car elles sont plus ou moins indépendantes des unes des autres (au moins par paire de règles).
ton CPU sera content :-)
Ca va, ils sont loin d'être au taquet. Surtout avec une connexion RTC :=)
l'adresse est FORCEMENT la tienne
Pas si, comme je le dis, "l'attaque" vient du FAI lui-même: http://olivieraj.free.fr/fr/linux/information/firewall/firewall.htm(...)
Je suis d'accord que ce type de test est un peu de la paranoïa, mais je ne prendrai pas le risque de baisser la sécurité sur ce point-ci. Notamment dans le cas d'un réseau local en NAT et d'une règle de FORWARD un peu trop mal écrite. Un intrus peut théoriquement utiliser Netfilter pour passer de son réseau au réseau interne.
Ces 2 techniques permettent de supprimer la dépendance du script avec l'adresse ip externe (variable), donc de supprimer la commande "barbare" de lancement.
Qui peut le plus peu le moins, non ? En utilisant le "-s" / "-o" sur les règles ppp, on ne réduit pas la sécurité de la machine, et on la protège contre un accès, certes improbable, de l'extérieur.
En fait, pas si improbable que cela d'ailleurs. A supposer qu'un intrus prenne la main sur le modem ADSL lui-même (certains sont manageable via le coté WAN), il pourra forger lui-mêmes ses paquets à destination de la machine, et pourquoi pas à destination du reséau en NAT (voir ci-dessus). De mémoire, je crois que c'est Nessus qui référence un possible trou de sécurité de ce type pour les modems ADSL Alcatel.
et surtout perte du tracking de connection
Il n'y a pas longtemps, j'ai utilisé ma machine en temps que serveur FTP, et suite à une erreur de manipulation, j'ai relancé mon script "netfilter_cfg". Les upload/download en cours ont été perturbés pendant moins d'une minute, puis tout à repris normalement. Les "gros" fichiers échangés n'ont pas été endommagés. Donc je ne sais pas comment Netfilter a fait, mais il a restauré le suivi de connexion...
voire passage possible de paquets entre le stop/start de ton script netfilter
Le risque est très faible, du fait de l'ordre des règles "ipatbles -X", "-F" et "-P".
tu ne mentionnes pas les caractéristiques TROMPEUSES de l'etat NEW.
Je ne suis pas au courant. Je vais me renseigner de ce pas !
Mais avant tout, cela t'intéresse-t-il ?
Bien sûr ! Toutes amélioration est intéressante ! Et puis, c'est bien pour cela que ma documentation n'est pas une version 1.0.. :=)
Toutes ces remarques me font d'ailleurs penser qu'un chapitre supplémentaire (optimisation, DMZ, statistiques, etc ...) serait intéressant, au moins pour l'utilisateur un peu plus expert dans le domaine.
[^] # Re: Documentation: Firewall et sécurité d'un réseau personnel sous Linux
Posté par Olivier (site web personnel) . En réponse à la dépêche Documentation: Firewall et sécurité d'un réseau personnel sous Linux. Évalué à 4.
Effectivement, je n'en n'ai que peu parlé. Mais je trouve qu'il est beaucoup moins simple de comprendre un FW Netfilter basé sur des chaînes utilisateurs. Il y a une logique qui, bien qu'efficace, n'est pas facile à appréhender. Et je n'ai pas voulu complexifier encore plus cette partie pour l'utilisateur néophyte.
Les chaines utilisateur peuvent aussi servir de compteur de paquets/octets pour faire des statistiques (et de beau graphes avec rrdtool).
Idem que plus haut : DMZ, extranet, compteur, etc... Cela sort du cadre de la documentation orientée vers les néophytes. Mais ce type de sujet peut faire partie d'un autre chapitre, plus spécifique, destiné aux utilisateurs plus "avancés". C'est une idée à creuser.
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
Je voulais "marteler" dans l'esprit de l'utilisateur néophyte la nécessité de faire des règles les plus strictes possibles. D'où l'importance du cumule des options "-i", "-o", "-s" et "-d". Ce n'est dont certes pas très optimum. Par contre, si l'utilisateur ne fait que copier/coller un seule règle d'un de mes scripts, il aura tout de même une protection acceptable, car elles sont plus ou moins indépendantes des unes des autres (au moins par paire de règles).
ton CPU sera content :-)
Ca va, ils sont loin d'être au taquet. Surtout avec une connexion RTC :=)
l'adresse est FORCEMENT la tienne
Pas si, comme je le dis, "l'attaque" vient du FAI lui-même:
http://olivieraj.free.fr/fr/linux/information/firewall/firewall.htm(...)
Je suis d'accord que ce type de test est un peu de la paranoïa, mais je ne prendrai pas le risque de baisser la sécurité sur ce point-ci. Notamment dans le cas d'un réseau local en NAT et d'une règle de FORWARD un peu trop mal écrite. Un intrus peut théoriquement utiliser Netfilter pour passer de son réseau au réseau interne.
Ces 2 techniques permettent de supprimer la dépendance du script avec l'adresse ip externe (variable), donc de supprimer la commande "barbare" de lancement.
Qui peut le plus peu le moins, non ? En utilisant le "-s" / "-o" sur les règles ppp, on ne réduit pas la sécurité de la machine, et on la protège contre un accès, certes improbable, de l'extérieur.
En fait, pas si improbable que cela d'ailleurs. A supposer qu'un intrus prenne la main sur le modem ADSL lui-même (certains sont manageable via le coté WAN), il pourra forger lui-mêmes ses paquets à destination de la machine, et pourquoi pas à destination du reséau en NAT (voir ci-dessus). De mémoire, je crois que c'est Nessus qui référence un possible trou de sécurité de ce type pour les modems ADSL Alcatel.
et surtout perte du tracking de connection
Il n'y a pas longtemps, j'ai utilisé ma machine en temps que serveur FTP, et suite à une erreur de manipulation, j'ai relancé mon script "netfilter_cfg". Les upload/download en cours ont été perturbés pendant moins d'une minute, puis tout à repris normalement. Les "gros" fichiers échangés n'ont pas été endommagés. Donc je ne sais pas comment Netfilter a fait, mais il a restauré le suivi de connexion...
voire passage possible de paquets entre le stop/start de ton script netfilter
Le risque est très faible, du fait de l'ordre des règles "ipatbles -X", "-F" et "-P".
tu ne mentionnes pas les caractéristiques TROMPEUSES de l'etat NEW.
Je ne suis pas au courant. Je vais me renseigner de ce pas !
Mais avant tout, cela t'intéresse-t-il ?
Bien sûr ! Toutes amélioration est intéressante ! Et puis, c'est bien pour cela que ma documentation n'est pas une version 1.0.. :=)
Toutes ces remarques me font d'ailleurs penser qu'un chapitre supplémentaire (optimisation, DMZ, statistiques, etc ...) serait intéressant, au moins pour l'utilisateur un peu plus expert dans le domaine.