Il s'agit d'un tutoriel assez long (39 pages en HTML, 48 pages en PDF) qui décrit comment configurer une machine Linux de type personnelle, ayant un réseau local et un accès à Internet. J'y parle de contrôle et de fermetures de ports IP, et bien sûr de configuration de Netfilter.
Cette documentation est résolument tournée vers un public connaissant peu ou pas le sujet, donc elle est abordable par tout le monde. J'y explique aussi quelques "trucs" de configuration, qui pourraient intéresser ceux qui maîtrisent plus le sujet.
Enfin, je mets à disposition un script de configuration de Netfilter (Netfilter_cfg) qui permet de configurer très simplement le firewall d'un kernel 2.4 et plus, avec le suivi de connexion et tout ce qui va bien.
Bonne lecture à tous ! Voici le plan du document :
Introduction
I Rappels sur les réseaux IP
* I-1 Adresses IP
* I-2 Ports
* I-3 Masque de sous-réseau
* I-4 Réseaux IP
* I-5 Passerelle
* I-6 Type de trames
* I-7 La poignée de mains (hand check)
* I-8 Interface réseau
* I-9 Résumé
II Sécurité de base
* II-1 Présentation du réseau
* II-2 Outils d'analyse et de détection
* II-3 Démons, serveurs et démons de service
* II-4 Risques
* II-5 Fermeture des ports
* II-6 Bilan
III Netfilter / Iptables
* III-1 Introduction
* III-2 Pré-requis
* III-3 Vue générale de Netfilter
* III-4 Les tables
* III-5 Chaînes, règles et iptables
* III-6 Un premier script simple
* III-7 Le suivi de connexion (conntrack)
* III-8 IP masquerading / Port forwarding
* III-9 Log (LOG / ULOG)
* III-10 Autres astuces
* III-11 Firewall applicatif
* III-12 Bilan
IV Outils et liens
* IV-1 Outils de configuration de firewalls Linux
* IV-2 Un exemple : Netfilter_cfg
* IV-3 Liens
Conclusion
Remerciements
Versions de ce document
Il est disponible en versions HTML mono ou multi page, PDF, et TGZ
Aller plus loin
- Le site du document (172 clics)
- L'annonce précédente sur LinuxFR (20 clics)
- Le site de la GUILDE (association Linux du Dauphiné) (17 clics)
- Un script de configuration de Netfilter (32 clics)
# Re: Documentation: Firewall et sécurité d'un réseau personnel sous Linux
Posté par madko (site web personnel) . Évalué à 10.
il en faudrait plus souvent de la bonne doc comme ça.
[^] # Re: Documentation: Firewall et sécurité d'un réseau personnel sous Linux
Posté par Christophe Lucas (site web personnel) . Évalué à 5.
Bravo et Merci de nous amener ou raffraichir nos connaissances.
Christophe.
[^] # Re: Documentation: Firewall et sécurité d'un réseau personnel sous Linux
Posté par Olivier (site web personnel) . Évalué à 4.
Merci
N'hésitez pas a diffuser cette doc, version pdf, tgz, ou autre. Le but étant de monter qu'il n'est pas si difficile que cela de mettre en place un bon système de sécurité sous Linux !
[^] # Re: Documentation: Firewall et sécurité d'un réseau personnel sous Linux
Posté par iouri . Évalué à 6.
http://olivieraj.free.fr/fr/linux/information/firewall/archives/fir(...)
a l'air défectueux :
gzip: stdin: invalid compressed data--crc error
gzip: stdin: invalid compressed data--length error
À propos du .pdf, je signale juste que la license n'apparaît nulle part dans le document, et l'URL du lien n'est pas visible.
Beau boulot en tout cas.
[^] # Re: Documentation: Firewall et sécurité d'un réseau personnel sous Linux
Posté par Olivier (site web personnel) . Évalué à 1.
gzip: stdin: invalid compressed data--crc error
gzip: stdin: invalid compressed data--length error
Damned, un problème lors du transfert FTP... Je mettrais en ligne une nouvelle version ce soir.
À propos du .pdf, je signale juste que la license n'apparaît nulle part dans le document, et l'URL du lien n'est pas visible.
Je le rajouterai à la fin
Beau boulot en tout cas.
Merci !
[^] # Re: Documentation: Firewall et sécurité d'un réseau personnel sous Linux
Posté par Olivier (site web personnel) . Évalué à 10.
Cela rallonge effectivement un peu le document, mais l'avantage est qu'il peut être lu d'un bout à l'autre par une personne connaissant peu ce domaine, sans pour autant avoir besoins d'autres sources d'informations.
On trouve sur Internet beaucoup de documentation sur le sujet, mais en général il faut déjà avoir un bon niveau pour pouvoir les appréhender.
# Re: Documentation: Firewall et sécurité d'un réseau personnel sous Linux
Posté par spart . Évalué à 7.
Sinon, qu'est-ce que vous pensez de Shorewall (http://www.shorewall.net/(...)) ?
Je dois dire qu'au début, j'ai été assez déconcerté de le trouver dans la Mandrake, mais à l'usage, c'est ultra simple et très puissant...
Ca limite très sérieusement les bêtises, quand on est pas un pro de netfilter, et la répartition en fichiers de confs bien structurés aide beaucoup à y voir clair...
[^] # Re: Documentation: Firewall et sécurité d'un réseau personnel sous Linux
Posté par Olivier (site web personnel) . Évalué à 4.
Cette info était passée sur LinuxFr il y a quelques temps déjà ( http://linuxfr.org/2003/02/21/11439.html(...) ). Mais j'ai appris qu'il existe au moins un autre projet que "FireFlier" qui permet aussi le filtrage applicatif, sans pour autant de quel projet il s'agit.
Sinon, qu'est-ce que vous pensez de Shorewall
Pour être honnête, je ne l'ai pas testé. J'ai préféré m'investir directement dans le paramétrage de Netfilter et de l'utilisation d'iptables, afin de mieux comprendre le fonctionnement du firewall sous Linux.
De plus, du fait de mes besoins particuliers en terme de connexion Internet (ma machine bouge beaucoup, et se connecte sur des réseaux différents), je voulais une solution complètement transparente pour moi, et qui se configure le plus automatiquement possible. C'est pourquoi j'ai développé "netfilter_cfg" (voir le dernier lien), qui répond à mes besoins spécifiques, mais aussi à ceux plus standards.
J'ai prévu à terme d'autres améliorations pour ce programme, afin de le rendre encore plus simple d'utilisation.
# Orthographe
Posté par Sixel . Évalué à 4.
de type personnel -le-
donc elle -s- est abordable
je mets à disposition
"Il faut" (Ezekiel 18:4) "forniquer" (Corinthiens 6:9, 10) "avec des chiens" (Thessaloniciens 1:6-9) "morts" (Timothée 3:1-10).
[^] # Re: Orthographe
Posté par domi . Évalué à 1.
Autant les corriger toutes :-)
[^] # Re: Orthographe
Posté par domi . Évalué à -1.
Heureusement que personne ne l'a vu :-)
Ne pas écrire :
le document écrit qui y est associée.</i/ s/iée/ie/
Mais :
le document écrit qui y est associée.</i/ s/iée/ié/
[^] # Re: Orthographe
Posté par QS . Évalué à -2.
-> j'ai un doute : le verbe est accordé au sujet "je"="Olivier"=masculin
(a priori :-)
la phrase d'origine doit être correcte.
[^] # Re: Orthographe
Posté par Yohann (site web personnel) . Évalué à 1.
[^] # Re: Orthographe
Posté par Guinns . Évalué à 2.
On a le verbe avoir, donc on s'accorde avec le COD s'il est situé avant le verbe ... ce qui est le cas ici ...
Donc : "la conférence que j'ai donnée"
[^] # Re: Orthographe
Posté par farib . Évalué à 0.
"suivit de connexion."
[^] # Re: Orthographe
Posté par Sixel . Évalué à -1.
Pas trouvé d'entrée pour suivi de connexion, mais celui-ci devrait convenir :
suivi de bogues n. m.
Définition :
Activité qui consiste à attribuer à chaque bogue relevé dans un programme une adresse permettant d'accéder à un fichier décrivant les caractéristiques de ce bogue, de manière à évaluer leur importance et à contrôler les dommages qu'ils pourraient causer.
"Il faut" (Ezekiel 18:4) "forniquer" (Corinthiens 6:9, 10) "avec des chiens" (Thessaloniciens 1:6-9) "morts" (Timothée 3:1-10).
[^] # Re: Orthographe
Posté par farib . Évalué à 0.
-> réussi
[^] # Re: Orthographe
Posté par Piksou . Évalué à 0.
dans l'intro à Netfilter: la tournure "malgré que" est discutable et discutée. "bien que" est tjs préférable :)
et pour le Netbios, il a vraiment été inventé par une boite appelée IMB ? ou c'est IBM avec une coquille ? (j'en sais rien, hein, c au cas où)
[^] # Re: Orthographe
Posté par Piksou . Évalué à 0.
"III-4-3 La table Mangle"
Mais l'application de cette technique est assez complexe, et sort complètement du cadre de cette documentation. Cela sera, peut-être, l'occasion pour moi de faire une nouvelle documentation ? Qui sait, le sujet n'est pas dénudé d'intérêt...
ouais mais non :D
le problème n'est pas de savoir si QoS est à poil mais de savoir si il a de l'intérêt
dénuder verbe transitif
(latin denudare ; de nudus, nu)
1. Laisser à nu une partie du corps. Robe qui dénude le dos.
Crâne dénudé, crâne dégarni, chauve.
2. Dépouiller un arbre de son écorce, un os ou une veine de la chair qui les recouvre, un conducteur électrique de son isolant.
se dénuder verbe pronominal
Se mettre partiellement ou totalement nu.
dénué adjectif
(féminin dénuée)
Dépourvu, privé de. (petit Larousse 2003)
[^] # Re: Orthographe
Posté par Olivier (site web personnel) . Évalué à 1.
Question de gout ! :=)
et pour le Netbios, il a vraiment été inventé par une boite appelée IMB ? ou c'est IBM avec une coquille ? (j'en sais rien, hein, c au cas où)
Oups, coquillette... ;-)
[^] # Re: Orthographe
Posté par Piksou . Évalué à 3.
En revanche, encore que de nombreux écrivains aient utilisé la locution conjonctive Malgré que dans le sens de Bien que, quoique, il est recommandé déviter cet emploi.
http://www.academie-francaise.fr/langue/questions.html#malgre_que(...)
:p
[^] # Re: Orthographe
Posté par Olivier (site web personnel) . Évalué à 2.
Bah, c'est des RFC quoi.. :=)))
Pas de problème, je corrigerais tout cela.
[^] # Re: Orthographe
Posté par Piksou . Évalué à 2.
espèce de Frontpage Express :p
tiens, encore une petite:
Pour ce qui sont des cibles par défaut des chaînes de la table NAT, nous acceptons toutes les connexions. Il n'est pas nécessaire de faire pointer ces cibles sur "DROP", car la sécurité est établie au niveau de la table "Filter", par le "DROP" par défaut de la chaîne FORWARD :
( III-8-1 IP masquerading )
"Pour ce qui est..." me semble mieux ;-)
PS: je veux pas relancer une discussion à la con, mais le moinssage des remarques orthographiques sur un topic qui vise à parler d'une doc, donc nottement à la critiquer en bien ou en mal et à corriger ce qui en va pas, heu.....
[^] # Re: Orthographe
Posté par Olivier (site web personnel) . Évalué à 1.
QUOI !!! Les recommandations du W3C sont mon livre de chevet, et ma home page est http://www.w3.org/(...) !! ;=))
PS: je veux pas relancer une discussion à la con, mais le moinssage des remarques orthographiques sur un topic qui vise à parler d'une doc, donc nottement à la critiquer en bien ou en mal et à corriger ce qui en va pas, heu.....
Je te rassure, ce n'est pas moi qui t'ai "moinisé". J'ai d'ailleurs noté les différents commentaires de chacun, afin de corriger tout cela pour la prochaine version.
[^] # Re: Orthographe
Posté par Dulbi . Évalué à 1.
La seule façon d'avoir "malgré" et "que" ensembles passe par "malgré le fait que"...
Au final, je te rejoins donc, "bien que" est toujours préférable ;-))
# Re: Documentation: Firewall et sécurité d'un réseau personnel sous Linux
Posté par Christophe Lucas (site web personnel) . Évalué à 5.
En revanche, c'est effectivement à cette date qu'il a été offciellement mergé au noyau. Maintenant cette "nouvelle" fonctionnalité est en marche(développement) depuis 2000.
Bon maintenant, j'ai lu cela en diagonal et rapidement.
Si mon avis est totalement faux sur ce point, veuillez m'excuser. Au contraire, si cela est vrai, je n'avais pour but que de faire avancer cette documentation.
--
Christophe
[^] # Re: Documentation: Firewall et sécurité d'un réseau personnel sous Linux
Posté par PLuG . Évalué à 2.
Très simples a installer/utiliser c'est comme ca que j'avais commencé a jouer avec uml !!
je ne sais pas pourquoi ils n'existent plus en redhat 8/9 ??
[^] # Re: Documentation: Firewall et sécurité d'un réseau personnel sous Linux
Posté par Olivier (site web personnel) . Évalué à 3.
Tout à fait, mais il m'a semblé que, du point de vue de l'utilisateur final, c'est la date d'intégration officielle dans le noyau qui était la plus importante. Ma documentation étant orienté vers les utilisateurs néophytes, la notion de patch et de compilation du kernel a été le plus possible évité ! :=)
Lorsque le kernel 2.6 sortira, je pense que le UML sera largement plus utilisé qu'actuellement, entre autre pour sécuriser les démons sensibles .
Si mon avis est totalement faux sur ce point, veuillez m'excuser. Au contraire, si cela est vrai, je n'avais pour but que de faire avancer cette documentation.
Merci, j'écrirai une correction qui éclaircira un peu plus ce point.
# Re: Documentation: Firewall et sécurité d'un réseau personnel sous Linux
Posté par PLuG . É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 ?
[^] # Re: Documentation: Firewall et sécurité d'un réseau personnel sous Linux
Posté par farib . Évalué à 1.
en (très) gros être moins sévère et regardant sur les connections déja établies ?
[^] # Re: Documentation: Firewall et sécurité d'un réseau personnel sous Linux
Posté par PLuG . Évalué à 2.
donc sur les connections deja etablies (--state ESTABLISHED) y a plus grand chose a dire sinon faire du filtrage applicatif !!
[^] # Re: Documentation: Firewall et sécurité d'un réseau personnel sous Linux
Posté par Vanhu . Évalué à 1.
Euh..... si tu utilises pas le --state NEW, ca ne crée pas les nouvelles entrées dans la table de connexion, donc tu peux pas non plus utiliser les --state ESTABLISHED, donc tu utilises pas le moteur stateful de Netfilter.
Ou j'ai loupé quelquechose ?
En fait, je dirais que l'ideal est d'utiliser des regles qui font --state NEW ET des tests sur les différents flags (TCP) des paquets.
[^] # Re: Documentation: Firewall et sécurité d'un réseau personnel sous Linux
Posté par remi . Évalué à 1.
Le stateful est quand même bien pratique pour définir simplement les choses, surtout dans une config ou l'on filtre dans les deux directions traversant le firewall.
Alors ?
[^] # Re: Documentation: Firewall et sécurité d'un réseau personnel sous Linux
Posté par PLuG . Évalué à 3.
imagines ces règles:
1/ --state ESTABLISHED,RELATED --> ACCEPT
2/ connection au serveurs web (dst=tcp/80) --> ACCEPT.
la 2 va matcher pour les paquets non traités par la 1 (les nouvelles connexions) et la 1 va matcher pour les connexions existantes.
le probleme du --state NEW c'est qu'il est volontairement laxiste pour permettre de garder la trace de connections malgré un reboot de la machine (c'est a dire qu'il considère comme NEW des paquets qui semblent legitimes mais ne le sont pas forcement).
Pour faire du statefull, l'interessant c'est le --state ESTABLISHED.
RELATED pour certains protocoles (FTP) et on pourrait le limiter a ceux la aussi.
[^] # Re: Documentation: Firewall et sécurité d'un réseau personnel sous Linux
Posté par Vanhu . Évalué à 1.
Des que j'ai 5 minutes de courage, je verifie par l'experimentation :-)
[^] # Re: Documentation: Firewall et sécurité d'un réseau personnel sous Linux
Posté par PLuG . Évalué à 1.
ca fait des annees que mes firewalls iptables n'utilisent pas le --state NEW.
[^] # Re: Documentation: Firewall et sécurité d'un réseau personnel sous Linux
Posté par Fulgrim . Évalué à 1.
Ca parle de la commande "chmon +x exemple-02.sh" alors qu'on veut faire un chmod. Un utilisateur pas trop neuneu comprendra (surtout avec la référence à man chmod juste après), mais ca coute rien à corriger
Sinon très interessante cette doc, ca faisait longtemps que je cherchais une bonne doc en français et acessible sur netfilter (et pas juste un exemple de script pas adapté à mon cas, ou une liste de commande pas expliquée). merci à l'auteur.
[^] # Re: Documentation: Firewall et sécurité d'un réseau personnel sous Linux
Posté par Goon . Évalué à 2.
Juste histoire de faire mon chieur aussi : la page n'est pas valide XHTML ;)
[^] # Re: Documentation: Firewall et sécurité d'un réseau personnel sous Linux
Posté par Olivier (site web personnel) . Évalué à 2.
Pour une Mandrake, tout est expliqué ici:
http://olivieraj.free.fr/fr/linux/information/firewall/firewall.htm(...)
Et ici aussi:
http://olivieraj.free.fr/fr/linux/programme/netfilter_cfg/index.htm(...)
Sinon, le plus simple est de modifier le script de connexions réseau ou ADSL, afin de lancer le script netfilter après l'établissement de la connexion réseau.
Personnellement, pour mes connexions RTC j'utilise l'option "Exécution" de kppp
Juste histoire de faire mon chieur aussi : la page n'est pas valide XHTML ;)
Effectivement. La version du validator ( http://validator.w3.org/source/(...) ) qui tourne sur ma machine n'a pas vu une erreur. Il est temps pour moi de la mettre à jour !
[^] # Re: Documentation: Firewall et sécurité d'un réseau personnel sous Linux
Posté par Olivier (site web personnel) . É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.
[^] # Re: Documentation: Firewall et sécurité d'un réseau personnel sous Linux
Posté par PLuG . Évalué à 3.
>Ca va, ils sont loin d'être au taquet. Surtout avec une connexion RTC :=)
bon ben ton temps de ping a UT alors :-)
non j'admet completement l'argument martelage et regles independantes meme si cela finit par faire des scripts un peu "lourds".
Pas si, comme je le dis, "l'attaque" vient du FAI lui-même
humm ok.
argument accepté mais tout de meme tordu amha :-))
les règles de firewall, surtout sur l'interface externe doivent commencer par de l'antispoofing. Et l'antispoofing tu peux l'ecrire de 2 facons: soit tu rejette tout ce qui ne t'es pas destiné (ne fontionne que pour les acces particuliers avec une seule adresse IP a-tout-faire). Soit tu rejette tous les reseaux RFC1918, y compris et surtout ceux que tu utilises en interne (et ca c'est une invariante, donc independant de l'IP de ta machine, qui fontionne meme en entreprise).
Donc je ne sais pas comment Netfilter a fait, mais il a restauré le suivi de connexion...
c'est ce que je critique avec le --state NEW. il essaye de deviner les paquets qui devraient faire partie d'une connection en cours. c'est a dire que ce n'est pas un match de SYN/SYN+ACK mais que des paquets *au milieu* d'un connection peuvent aussi servir a ajouter la connection au tracking. Pour moi c'est litigieux comme comportement et je n'utilises pas le --state NEW.
Le risque est très faible, du fait de l'ordre des règles "ipatbles -X", "-F" et "-P"
A noter que si tu te débarasse de la dépendance entre tes règles et ton IP, le script netfilter est a lancer une seule fois au demarrage de la machine et AVANT de configurer les interfaces eth et ppp... cette fois plus de doutes TOUS les paquets seront filtrés.
[^] # Re: Documentation: Firewall et sécurité d'un réseau personnel sous Linux
Posté par PLuG . Évalué à 2.
http://msgs.securepoint.com/cgi-bin/get/netfilter-0304/138/1/1.html(...)
ou meme ca !! tres bien expliqué:
http://iptables-tutorial.frozentux.net/chunkyhtml/newnotsyn.html(...)
[^] # Re: Documentation: Firewall et sécurité d'un réseau personnel sous Linux
Posté par Olivier (site web personnel) . Évalué à 1.
Dans ce type de boulot, mieux vaut être parano ! :=)
les règles de firewall, surtout sur l'interface externe doivent commencer par de l'antispoofing.
C'est ce que je fais justement dans "netfilter_cfg". Il y a un paramètre "--spoofing-filter" qui est activé par défaut. J'ai rajouté une 2nd protection anti-spoofing, basé sur une autre couche du kernel
(KERNEL_SPOOFING_PROTECTION=y), qui est activé aussi par défaut.
c'est ce que je critique avec le --state NEW. il essaye de deviner les paquets qui devraient faire partie d'une connection en cours. c'est a dire que ce n'est pas un match de SYN/SYN+ACK mais que des paquets *au milieu* d'un connection peuvent aussi servir a ajouter la connection au tracking. Pour moi c'est litigieux comme comportement et je n'utilises pas le --state NEW.
Effectivement, c'est ce que je viens de voir avec les liens que tu as envoyé. Le patch "tcp-nopickup" résout réellement ce problème ?
A noter que si tu te débarasse de la dépendance entre tes règles et ton IP, le script netfilter est a lancer une seule fois au demarrage de la machine et AVANT de configurer les interfaces eth et ppp... cette fois plus de doutes TOUS les paquets seront filtrés.
En fait, je lance mon "netfilter_cfg" dès le démarrage de ma machine, avant même de lancer ma connexion Internet. Donc par défaut, tout mes interfaces réseaux sont protégées. Une fois la connexion Internet établie, je relance mon script qui redéfinie les règles Netfilter, et rajoute les règles de ppp0. Entre l'établissement de la connexion et l'exécution de mon script, les paquets entrant sont rejetés dans le log et détruits, car ils arrivent par une interface réseau (ppp0) dont Netfilter n'a aucune règle en "ACCEPT".
[^] # IP spoofing suite
Posté par Quzqo . Évalué à 2.
Dans WanSpoofingFilterRules(), il y a
un réseau de classe D en 224.0.0.1/4 : est-ce bien raisonnable ?
une règle iptables -A INPUT -i < interfaces > -s 240.0.0.0/4 -j DROP dupliquée
et je crois que le commentaire n'a pas trop de rapport avec la fonction... ;o)
[^] # Re: IP spoofing suite
Posté par Olivier (site web personnel) . Évalué à 1.
une règle iptables -A INPUT -i < interfaces > -s 240.0.0.0/4 -j DROP dupliquée
Oups, double boulette...
et je crois que le commentaire n'a pas trop de rapport avec la fonction... ;o)
Comment on dit déjà ? Jamais 2 (boulette) sans trois ? :=)
Merci pour les corrections !
[^] # Re: Documentation: Firewall et sécurité d'un réseau personnel sous Linux
Posté par PLuG . Évalué à 2.
je suppose oui mais je ne les ai pas essayé... et dans la doc ils previennent qu ele résultat est déroutant (coupure des connections a chaque relance du script netfilter -- ce qui est logique)
D'ailleur dans le cadre d'un doc visant les débutants je te déconseilles de commencer par leur demander de patcher le noyau :-))
Pour corriger ce probleme, il suffit de ne pas utiliser --state NEW puisqu'il ne fait pas ce que l'on veut/pense. De plus je trouve criticable ta facon d'utiliser --state NEW sans le dire. Le jour ou les developeurs de netfilter ajoutent un etat de plus dans la liste des etats connus pour une connection, tu va la matcher par defaut egalement ... il vaudrait mieux explicitement choisir les etats qui t'interessent.
Honnetement je ne voit pas l'interet d'un etat --state NEW :
si tu as des règles dans cet ordre:
1/ rejet des etat non voulus (invalid)
2/ accept des etats souhaitables (connected)
3/ accept un a un des protocoles connus et voulus quel que soit l'etat
normalement le filtrage est ok et sans utiliser --state NEW. [jusqu'a preuve du contraire]. le --state NEW de netfilter est mal-nommé amha, il devrait s'appeler --state OPTIMISTICALNEW ou quelque chose du genre :-))
dans le <3> si on est un peu plus parano on peut preciser les flags souhaitables (SYN ...). Mais pour ma par, je pense que le role du firewall netfilter c'est de laisser passer ces paquets. Si mon serveur web tourne sur le port 80, je peux accepter any:any -> serveur:80. C'est a apache et son OS hote d'etre resistant (pile tcp et serveur applicatif).
[^] # Re: Documentation: Firewall et sécurité d'un réseau personnel sous Linux
Posté par Olivier (site web personnel) . Évalué à 2.
En fait, j'ignorai ce problème du --state NEW, et je pensais qu'il fonctionnait comme son nom l'indiquait, à savoir une nouvelle connexion partant de rien. D'où aussi mon étonnement lorsque mon serveur FTP avait réussi à reprendre la connexion. Merci donc pour tes précisions
Je rajouterai un paragraphe afin de soulever ce problème, voir un exemple d'exploitation de cette "faille".
[^] # Re: Documentation: Firewall et sécurité d'un réseau personnel sous Linux
Posté par jdh . Évalué à 1.
Beau travail de démocratisation du firewalling par Olivier !
Je relance un peu "Shorewall" car il incorpore une chaine "newnotsyn" dont je ne comprenais pas l'utilité vu que je n'avais pas cherché la signification des flags.
Il me semble que cela répond aux inquiétudes de PLuG.
Par ailleurs, "Shorewall" utilise aussi les chaînes "user" avec des noms évocateurs "loc2net", "net2fw", ...
Enfin, le dynamisme des développeurs (voir les news) fait plaisir à voir tant ils veulent faire des choses sympas : TC, Ipsec et autres PPtP, ... Il ne manque que le Load Balancing au travers des --count ?
Pour finir, je ne suis pas sur de l'utilité d'un exemple d'exploitation de faille ...
URL : http://www.shorewall.net/(...)
# Re: Documentation: Firewall et sécurité d'un réseau personnel sous Linux
Posté par Nicolas Stransky . Évalué à 2.
Vraiment ? Ça m'étonne un tout petit peu, t'es sûr que ça ne rentrait pas dans le cadre d'une utilisation normale ?
Quoiqu'il en soit, que les étudiants gérant le réseau de l'externat de l'université de Cachan qui lisent ce document ne se sentent pas l'esprit de justiciers, et n'aillent pas lui casser la tête !!
Ben là y'a pas assez d'infos pour le faire, de toutes façons ;)
Du fait de son caractère orienté sur la sécurité, la commande "traceroute" ne peut s'exécuter qu'en temps que root.
Pas vraiment, c'est juste que /usr/sbin n'est normalement pas dans le PATH du simple user.
Nico
[^] # Re: Documentation: Firewall et sécurité d'un réseau personnel sous Linux
Posté par Jérome K . Évalué à 2.
Effectivement traceroute comme ping et plein d'autre outil de _sécu_ nécessite les droits de root.
----------------------------------------------------------
ls -la /usr/sbin/traceroute
-rwsr-xr-x 1 root root /usr/sbin/traceroute
ls -la /bin/ping
-rwsr-xr-x 1 root root /bin/ping
----------------------------------------------------------
Et oui ils sont suid root :)
[^] # Re: Documentation: Firewall et sécurité d'un réseau personnel sous Linux
Posté par Vanhu . Évalué à 4.
Du fait de son caractère orienté sur la sécurité, la commande "traceroute" ne peut s'exécuter qu'en temps que root.
Pas vraiment, c'est juste que /usr/sbin n'est normalement pas dans le PATH du simple user.
Euh, traceroute a besoin des droits de root pour fonctionner, puisqu'il travaille "bas niveau" sur l'interface réseau.
Donc pour qu'un utilisateur "normal" puisse exécuter traceroute, il faut aussi un suid root.
[^] # Re: Documentation: Firewall et sécurité d'un réseau personnel sous Linux
Posté par Olivier (site web personnel) . Évalué à 1.
Je peux vérifier dans mes log, mais c'était soit une connexion au port 137/139 de ma machine (samba), soit une connexion venant d'un port 53 (dns) ou 80 (http). Dans les 2 cas, ce n'était pas moi qui avait initialisé de connexion sur cette machine, donc c'est forcément un port scan.
Ben là y'a pas assez d'infos pour le faire, de toutes façons ;)
Aucune importance de toute façon. J'ai pris cette adresse IP au hasard dans mon log Netfilter. Cela aurait pu être une IP venant des EU, de la Corée ou d'Australie !
Pas vraiment, c'est juste que /usr/sbin n'est normalement pas dans le PATH du simple user.
Vraiment ? Cela doit dépendre des systèmes alors. Passé un temps, j'ai travaillé sur Solaris (UNIX Sun), et le traceroute nous était refusé ("rwxr-x--- root root" si je me souviens bien). Je ferais une correction de la doc.
# Re: Documentation: Firewall et sécurité d'un réseau personnel sous Linux
Posté par Fulgrim . Évalué à 3.
Vous voulez utiliser Kopete/Gaim, ouvrez le port XXX
D'ailleurs je n'ai pas trouvé d'info pour utiliser proprement toutes les fonctionnalités des clients de messagerie instantannée avec netfilter (par exemple, les receptions de fichiers ne passent pas). Si qqn en a, je suis preneur ?
Pop : ouvrez le port 110
etc.
C'est souvent des informations pas toujours évidentes à trouver pour un débutant.
Sinon, expliquer comment trouver ces informations dans les logs, ca pourraient être pas mal.
[^] # Re: Documentation: Firewall et sécurité d'un réseau personnel sous Linux
Posté par jmfayard . Évalué à 4.
http://www.shorewall.net/ports.htm(...) me paraît très bien !
Il suffirait peut-être de rajouter ça dans les liens.
D'ailleurs je n'ai pas trouvé d'info pour utiliser proprement toutes les fonctionnalités des clients de messagerie instantannée avec netfilte
Et bien donc d'après le lien ci-dessus :
ICQ
UDP Port 4000. You will also need to open a range of TCP ports which you can spcify to your ICQ client. By default, clients use 4000-4100.
[^] # Re: Documentation: Firewall et sécurité d'un réseau personnel sous Linux
Posté par jmfayard . Évalué à 1.
qui peut être intéressante :
http://www.iss.net/security_center/advice/Exploits/Ports/(...)
[^] # Re: Documentation: Firewall et sécurité d'un réseau personnel sous Linux
Posté par Olivier (site web personnel) . Évalué à 2.
Avec le suivit de connexion, ce n'est pas vraiment la peine. Par défaut, tous les ports de la machine peuvent être ouverts, SI et SEULEMENT SI, les connexions sont initialisées par, par exemple, les processus locaux.
Dans la documentation (http://olivieraj.free.fr/fr/linux/information/firewall/firewall.htm(...)), les 2 règles suivantes donnent accès à Internet à toutes les connexions faites par les programmes tournant sur votre machine:
iptables -A OUTPUT -o eth1 -s 10.0.0.1 -d 0.0.0.0/0 -p all -m state --state ! INVALID -j ACCEPT
iptables -A INPUT -i eth1 -s 0.0.0.0/0 -d 10.0.0.1 -p all -m state --state RELATED,ESTABLISHED -j ACCEPT
Il faut voir le "conntrack / suivi de connexion" comme un miroir sans tain: Vous pouvez voir sans être vu... ;=)
Vous voulez utiliser Kopete/Gaim, ouvrez le port XXX
J'utilise de temps à autre "Kopete" avec les 2 règles ci-dessus, et cela marche très bien.
Au cas où, charger les modules de suivit de connexion FTP et IRC:
modprobe ip_conntrack_ftp
modprobe ip_conntrack_irc
Pour avoir la liste des modules de suivi de connexion de votre machine, voir l'explication écrite ici (rechercher "uname -a"): http://olivieraj.free.fr/fr/linux/information/firewall/firewall.htm(...)
Pop : ouvrez le port 110
La liste des ports usuels se trouve dans votre "/etc/services". Il y en a une copie ici:
http://olivieraj.free.fr/fr/linux/information/firewall/archives/ser(...)
Sinon, expliquer comment trouver ces informations dans les logs, ca pourraient être pas mal.
Une technique qui marche assez bien:
- Utiliser un script Netfilter qui log toutes les connexions non valide Par exemple: http://olivieraj.free.fr/fr/linux/programme/netfilter_cfg/index.htm(...)
- Demander à votre correspondant son adresse IP
- Regarder dans le log de Netfilter les connexions venant de cette adresse IP là (information "SRC="), et venant ("SPT=") ou à destination ("DPT=") de quels ports. En général, on trouve des connexions répétées à un port en particulier.
- A partir de là, il faudra écrire une règle adéquate, en utilisant les options "-p" (pour le Protocole: TCP/UDP par exemple), "--sport", "--dport".
[^] # Re: Documentation: Firewall et sécurité d'un réseau personnel sous Linux
Posté par PLuG . Évalué à 1.
"j'ouvre tous les protocoles sortants".
Comme tout choix, c'est certainement le résultat d'une réflexion poussée qui doit alors apparaitre dans ton document pour permettre aux lecteurs de faire le meme raisonnement (validation) ou de le contredire (et a ce moment la il faudra leur donner les moyens d'implementer d'autres politiques de filtrage).
Avec le filtrage décrit ci dessus:
- Quid des spyware qui tournent sur tes postes clients ?
ils etablissent des connections sortantes et ont donc tout loisir d'exporter toutes les informations qu'ils souhaitent.
- Quid des serveur FTP malicieux qui peuvent negocier des ouvertures de ports ENTRANT (grace au tracking de connection destinée au départ pour le ftp-data)
Si ils sont consultés ils peuvent établir des connections entrantes sur les ports TCP qu'ils veulent (negocier avec le client FTP donc on doit faire confiance au client pour etre restrictif ? je me demande si netfilter sait prendre cela en considération ... a voir).
N'importe quel nimbda tournant chez toi peut infecter l'exterieur (connection sortante port 80)
N'importe quel trojan va pourvoir passer, se connecter (connection sortante) sur un canal IRC et y attendre des ordres ... qu'il va executer depuis l'intérieur. Un remote shell en quelques sortes.
Pour moi, hors de question, les protocoles qui sont autorisés en sortie sont sur ma liste de choses impossibles a supprimer et passent par un proxy applicatif le plus possible, par un proxy "bete" (comme un socks) sinon de facon a delocaliser les flux et a valider qu'ils sont connus/maitrisés autant que faire se peu.
C'est pour cela que certaines personnes ont besoin de la relation Appli/Port ,
evidement si tu ouvres en grand, pas besoin de connaitre le détail.
[^] # Re: Documentation: Firewall et sécurité d'un réseau personnel sous Linux
Posté par Olivier (site web personnel) . Évalué à 1.
Pour l'instant, j'ai confiance dans les applications que je lance (il n'y a que du Linux qui accède à Internet via ma machine), et je passe par un proxy filtrant ( http://www.privoxy.org/(...) ) pour mes connexions HTTP (90% de mon activité sur Internet).
Mais j'ai prévu de rajouter à "netfilter_cfg" un paramétrage sur les règles de connexions sortantes, afin de limiter au maximum les "portes de sortie". Quelque chose du même type que le tableau "DROP[?]".
Quoi qu'il en soit, seul l'usage d'un firewall applicatif, tel que http://fireflier.sourceforge.net/(...) peut apporter une sécurité suffisamment efficace pour museler les spywares.
[^] # Re: Documentation: Firewall et sécurité d'un réseau personnel sous Linux
Posté par M . Évalué à 1.
la correspondance port appli pour les appli "classique"
# Re: Documentation: Firewall et sécurité d'un réseau personnel sous Linux
Posté par Bernez . Évalué à 2.
De la part d'un utilisateur du libre ça m'étonne pas mal.
[^] # Re: Documentation: Firewall et sécurité d'un réseau personnel sous Linux
Posté par Olivier (site web personnel) . Évalué à 1.
La version PPT de ce document n'avait pas pour but de faire une quelconque publicité à ce format. J'ai simplement voulu que la présentation soit disponible au plus grand nombre. Il se trouve que 90% des personnes qui ont des PC utilisent Windows, et la plus grande part possèdent MS Office. Le format OOo est complètement libre, mais MS Office ne sait pas l'ouvrir. Donc plutôt que d'obliger les utilisateurs à télécharger OpenOffice.org (ce qui risque d'être difficile si ils n'ont on comme moi un modem), je le met à disposition dans le format qu'ils utilisent. Comme l'indique le code source de la page principale de ce document, j'avais initialement prévu de fournir ce document en format PDF, qui est plus lisible par le plus grand nombre. Mais j'ai eu un problème avec l'exportation en PDF dans OOo, donc faute de mieux, je me suis rabattu sur l'exportation en PPT.
De la part d'un utilisateur du libre ça m'étonne pas mal.
Il s'agit simplement de fournir au plus grand nombre l'information sous la forme la plus pratique. La génération HTML des transparents OOo est un format intéressant, mais gère pratique et transportable. PPT est plus connu et transportable plus facilement.
D'ailleurs, si j'en crois les statistiques de Free, la version OOo de ce document a été 2 fois plus téléchargée que la version PPT. Et le nombre de téléchargements de la version PPT est loin d'être négligeable, ce qui prouve que c'était une bonne idée.
# Re: Documentation: Firewall et sécurité d'un réseau personnel sous Linux
Posté par Bernez . Évalué à 2.
MOUARF !
Je suppose qu'il fallait lire "handshake" ;-)
[^] # Re: Documentation: Firewall et sécurité d'un réseau personnel sous Linux
Posté par Foxy (site web personnel) . Évalué à 2.
# Documentation: Firewall [...] que du bonheur ;o)
Posté par Quzqo . Évalué à 5.
Il y a plusieurs points que je souhaite saluer :
- une vue d'ensemble de la problématique qui ne se focalise pas sur un problème particulier à une topographie réseau. Toutes les notions sont abordées et demeurent aisément compréhensibles
- un intéressant tour d'horizon des outils réseaux connexes permettant de réaliser la mise au point des règles iptables.
- les nombreux liens vers d'autres documentations sur les jail, détails des ports, ...
- les iptables -l -v -n -t < table > bien pratiques
Mais j'aurai tout de même quelques remarques (bah oui, faut bien ;o) relevant du détail :
- après traceroute, lsof, nmap, ifconfig, et autres, who aurait bien pu figurer dans les outils standards cités
- la possibilité pour xinetd d'interdire les futures tentatives de connexion sur échec
- toutes ces références aux trolls communs (choix de distribution, nommage,...) donne un ton pour "public averti" alors que l'ensemble du document est rézolument tourné vers le grand public
- le côté je-casse-du-sucre-sur-le-dos-de-Microsoft n'apporte pas grand chose à la qualité du discours si ce n'est parfois, expliquer les modes de fonctionnement différents, mais le plus souvent c'est un geste quelque peu gratuit.
- une référence au flag -Z (remise à zéro des conteurs) dans la partie initialisation des cibles par défaut ne ferait pas de mal au QoS je crois même si ce n'est pas (encore ?) utilisé. Sinon, partant de ce principe, autant ne pas charger les modules inutiles (référence à la table mangle)
Pour finir, mais tu le signales dans les paragraphes TODO, je crois que les aspects(1) "je fais confiance aux machines de mon réseau interne" et (2) QoS méritent d'être abordés très en détail... car
(1) les réseaux personnels mixtes Linux/Windows se démocratisent. Et il suffit d'un ver dans la pomme...
(2) le partage de connexion aussi avec ADSL/Câble et WIFI
--- netfilter_cfg
Pfffiouuu... je n'ai pas encore eu le temps de tout lire en détail le shell mais il me semble bien compliqué à première vue... un poil long en tous cas.
Vue sa complexité, je pense qu'il devrait s'étoffer d'un fichier de configuration et de "lib" (via FPATH en ksh/bash) afin d'accroître sa lisibilité et de ne pas tout "mélanger".
De là à envisager un véritable package shell + doc... il n'y a qu'un pas ;o)
Dernier détail, quelques commandes auraient mérite à être simplifiées avec un interpréteur bash
Mais c'est toujours plus facile de critiquer lorsqu'il s'agit juste de relire ;o))))
[^] # Re: Documentation: Firewall [...] que du bonheur ;o)
Posté par Olivier (site web personnel) . Évalué à 4.
who, nslookup, host, etc... effectivement. J'étais déjà fort en retard lors de l'écriture de cette partie, et j'ai dû en supprimer quelques uns.
toutes ces références aux trolls communs (choix de distribution, nommage,...) donne un ton pour "public averti" alors que l'ensemble du document est rézolument tourné vers le grand public
Ca permet de garder les geeks et trolleurs éveillés !
mais le plus souvent c'est un geste quelque peu gratuit.
J'en casse tellement du sucre ? :=) Il se trouve que je connais(sais) très bien le monde Windows, et qu'en terme de sécurité réseau et/ou respect de l'utilisateur, je trouve qu'il y en a beaucoup à dire. Ces petites phrases sont en générale teinté d'un brin d'humour, et sont soit :
- destinées à rendre la documentation un peu moins rébarbative à lire ;=)
- des incitations au lecteur (et peut-être utilisateur de Windows) à lui faire prendre en compte ce qu'il se passe sur son Windows.
Il n'y a qu'a par exemple faire un tour sur fr.comp.securite ( http://groups.google.fr/groups?hl=fr&lr=&ie=UTF-8&group(...) ) pour se rendre compte de la situation... Donc non, ces petites phrases ne sont pas de la méchanceté gratuite. Juste des petits "chocs électriques" histoire de mettre en avant ce que les vendeurs ou utilisateurs de Windows s'évertuent à ignorer.
Sinon, partant de ce principe, autant ne pas charger les modules inutiles (référence à la table mangle)
Initialement, je n'avais pas prévu de parler beaucoup de la table Mangle, et encore moins de l'intégrer à mes scripts. Mais il se trouve que lors d'un test et d'une fausse manipulation, j'ai court-circuité tous transferts IP en mettant des règles DROP par défaut sur la table Mangle. C'était un peu gênant, d'autant que "iptables -L -t filter" ne me donnait aucune information (par contre, "iptables -L -t mangle" était beaucoup plus instructif). Ainsi, et pour éviter que ce genre de situation ne se reproduise, j'ai rajouté les initialisations de la table Mangle à mes scripts.
Pour finir, mais tu le signales dans les paragraphes TODO, je crois que les aspects(1) "je fais confiance aux machines de mon réseau interne" et (2) QoS méritent d'être abordés très en détail
Sans doute dans le futur chapitre plus orienté pour les utilisateurs "experts". Pour QoS, je pense que cela fera parti d'une documentation à part.
il me semble bien compliqué à première vue... un poil long en tous cas
J'aurai pu l'écrire en beaucoup plus court, mais il aurait perdu de sa lisibilité, du moins pour moi. Une grosse partie est le composant réutilisable pour la gestion des paramètres en format long ("--nat" par exemple), qui aurait pu être remplacé par des "getop". Mais les options de type "-e", "-t", "-h" perdent en lisibilité pour l'utilisateur néophyte.
Je pense qu'il devrait s'étoffer d'un fichier de configuration
Oui, c'est prévu pour la prochaine version. Un fichier de configuration dans le "/etc" , "/usr/local/etc", ou en "~/.netfilter_cfg"
[^] # Re: Documentation: Firewall [...] que du bonheur ;o)
Posté par PLuG . Évalué à 1.
Pour un utilisateur qui ne veut pas developper son propre script je conseillerai plutot d'utiliser fwbuilder ou shorewall qui ne sont pas mal du tout.
L'interet de ta doc c'est de montrer la souplesse interne du mecanisme iptables et de susciter l'envie de se lancer dans son exploitation.
Shorewall a deja une grosse base d'utilisateurs, des fichiers de config pas si compliqués ...
De mon point de vue, ta doc doit etre parsemée d'exemples pour illustrer les possibilités de iptables et le meilleur moyen c'est d'accompagner le lecteur dans la redaction d'un script D'EXEMPLE.
Je ne pense pas du tout qu'il faille arriver a un script utilisable tel quel dans la majorité des situations et qui repose sur un /etc/netfilter.conf cachant les lignes iptables et donc ... le but initial d'exemple.
[^] # Re: Documentation: Firewall [...] que du bonheur ;o)
Posté par Olivier (site web personnel) . Évalué à 1.
Pour un utilisateur qui ne veut pas developper son propre script je conseillerai plutot d'utiliser fwbuilder ou shorewall qui ne sont pas mal du tout.
L'existance de "fwbuilder", "shorewall", et consort ne m'oblige pas à les utiliser, non ? ;=) Je peux donc bien développer mon propre script, qui répond à mes besoins, et je peux même le distribuer en GPL ! :=))
J'ai prévu d'apporter des améliorations à "netfilter_cfg", entre autre pour mon propre usage, mais de toute façon se sera toujours fait en marge de ma documentation. Ce sont 2 "sujets" séparés, et cela le restera toujours.
Bon, je pense que l'on excusera le fait que dans ma documentation, je fasse un peu de "pub" à mon programme "netfilter_cfg", non ? :=)
De mon point de vue, ta doc doit etre parsemée d'exemples pour illustrer les possibilités de iptables et le meilleur moyen c'est d'accompagner le lecteur dans la redaction d'un script D'EXEMPLE.
Oui, c'est bien pour cela que tout au long du document, divers petits scripts d'exemples sont proposés, chacun sur une fonctionnalité spécifique de Netfilter (conntrack, masquerading, etc ...).
# Autres Petites erreurs
Posté par Smith Elliot . Évalué à 2.
Netbios a besoin des 3 ports tcp/udp suivant : 137, 139 ET 138.
Sous RedHat (surement sous MDK), au lieu de creer de liens pour tes scripts rc, tu as chkconfig. Autant utiliser les outils fournis meme si j'avoue que le faire a la main est plus didactique...
A ma connaissance, ICMP est de niveau 3, ce qui fait sa particularité (proto de niveau 3 informant sur d'autres protos de niveau 3).
Voila voila...
Sinon, très bonne doc que j'aurais aimé trouver a mes débuts.
Seul les schema sont un peu cheaps, t'aurais au moins pu les faire sous OOImpress :)
Bonne continuation
[^] # Re: Autres Petites erreurs
Posté par Olivier (site web personnel) . Évalué à 1.
Netbios a besoin des 3 ports tcp/udp suivant : 137, 139 ET 138.
Effectivement, je n'ai pas parlé du "netbios-dgm". Je rajouterai cette information.
Sous RedHat (surement sous MDK), au lieu de creer de liens pour tes scripts rc, tu as chkconfig.
Je vérifierai si il existe aussi sous Mandrake.
A ma connaissance, ICMP est de niveau 3, ce qui fait sa particularité (proto de niveau 3 informant sur d'autres protos de niveau 3).
Je ne parlais pas du modèle OSI, mais du modèle IP. Cette partie manque de précision, je vais la changer et ceci :
<patch>
Je sais que je vais faire hurler les puristes d'IP en mélangeant dans un même paragraphe un élément de la couche 2(*) (ICMP) avec d'autres de la couche 3(*) (TPC et UDP), mais en fait, cette approximation n'est pas si primordiale que cela dans le cadre de cette documentation...
(*): Dans le modèle TCP/IP, et non le modèle OSI. Voir à ce sujet ce pages http://christian.caleca.free.fr/tcpip/les_protocoles.htm(...) et http://www.commentcamarche.net/internet/tcpip.php3(...) .
</patch>
> Voila voila...
> Sinon, très bonne doc que j'aurais aimé trouver a mes débuts.
Merci !
> Seul les schema sont un peu cheaps, t'aurais au moins pu les faire
> sous OOImpress :)
The Gimp powered !!! Avec Gimp, c'était beaucoup plus simple à modifier et à sauver sous forme d'images png/jpg. Et puis, je suis un fan des calques et des fonds transparents... Cela m'a permit de conserver les mèmes images entre ma documentation et ma présentation, ce qui a sauvé de nombreuses heures de boulot...
[^] # Re: Autres Petites erreurs
Posté par Smith Elliot . Évalué à 2.
Pour avoir bossé avec Impress, je t'avouerai avoir des aprioris mais essais tu verras, le vectoriel pour les schemas, c'est super intuitif et réutilisable. Par exemple, le copier/coller de ton groupe de dessin vectoriel vers ta presentation est tres simple :)
Juste un dernier petit conseil pour chipotter... pourquoi dis tu apres avoir annoncer que tu utiliserais 2 mdk et 1 debian qu'il ne faut pas troller?
Ca donne l'impression qu'une mdk n'est pas legitime pour le boulot que tu lui a confié. bien que je ne la connaisse pas, j'avoue en avoir marre que cette distrib soit considérée comme la distrib du neuneu. et ce genre de commentaire incite a avoir ce genre d'idées...
Encore une fois, bravo pour ta doc que j'eppluche ds le RER le
matin ;)
[^] # Re: Autres Petites erreurs
Posté par Olivier (site web personnel) . Évalué à 1.
Le seul truc qui m'intéressait, c'est la sauvegarde directe dans un format de type PNG ou JPG. Or, il ne m'a pas semblé que ce soit possible. J'ai utilisé OOImpress au moins une fois dans ma doc (pour "pictures/handcheck.jpg"), mais le copier-coller dans Gimp en passant par une capture d'écran, c'était moyennement pratique... :=(
Juste un dernier petit conseil pour chipotter... pourquoi dis tu apres avoir annoncer que tu utiliserais 2 mdk et 1 debian qu'il ne faut pas troller? Ca donne l'impression qu'une mdk n'est pas légitime pour le boulot que tu lui a confié. bien que je ne la connaisse pas, j'avoue en avoir marre que cette distrib soit considérée comme la distrib du neuneu. et ce genre de commentaire incite a avoir ce genre d'idées...
Non, ce n'était pas le but. J'utilise des Mdk depuis quelques années déjà, et j'en suis très satisfait. Avec ou sans outils GUI, elle marche bien. Et au moins, j'ai le support des matériels récents. Passé un temps, j'ai aussi testé la Debian Potatos, ainsi qu'une vielle RedHat, et j'ai sur mon DD les ISO de la Woody...
Le problème dans ce genre de document, c'est que si tu cites une distribution ou un autre, forcément il y en aura qui en profiterons pour lancer un troll. C'était plus une touche d'humour qu'autre chose !
Mais cette phrase peut en effet laisser à penser que la MDK n'est pas une "bonne" distribution, je reprendrai sa tournure.
Encore une fois, bravo pour ta doc que j'eppluche ds le RER le matin ;)
Merci. J'espère que tout le monde ne l'a pas imprimé en version papier, sinon je vais avoir la responsabilité du massacre de la forêt Amazonienne sur le dos ! :=)
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.