Oui le troll GNOME merci.
Je suis chez un client ou les postes (portables la plupart) sont sous windows principalement. Ceux qui sont sous linux (une dizaine autour de moi déjà) sont en redhat avec Gnome.... AUCUN KDE a l'horizon (ou alors je l'ai pas vu).
les serveurs sont en redhat mais sans X11 ...
comme quoi faut pas tirer des conclusions basées sur un échantillon trop restreint hein :-)
à l'inverse, les conséquences négatives de la copie illégale ne sont pas démontrées, et en fait pas du tout soutenues par les chiffres
HS mais le deploiement de force contre les exces de vitesse sur voies rapides (autoroutes) ne part pas non plus d'une *démonstration* ni ne sont soutenues par les chiffres (sinon des gains en taxe pour l'état).
Les autoroutes ou l'ont roule le plus vite sont les routes les moins meurtrières ... a peine 6% des tués pour des millions de km effectués tous les ans.
Ramené au nombre de km la différence penche encore plus pour ces voies "rapides".
Bref, ici on s'occupe de la liberté de copie , sur d'autres forum on s'occupe de la liberté de "rouler" et je veillerai a ne plus me tromper de forum :-))
Par contre tous les serveurs sont des redhat... sauf un: windows 2000 ?!??
un autre truc: l'hebergement mis a dispo par COLT: lien vers les internautes: 2Go ??
2Go soit 16Gb/s ???
ouaou !! faudrait faire héberger un serveur UT sur ces machines redhat :-))
l'avantage de l'open source (après le cout - evident en licenses):
+ repondre finement aux besoin ("modèle mixte entre le produit et le developpement spécifique")
+ cout de maintenance : ils veulent parvenir a faire integrer leurs modifications/apports au produit GPL de manière a ne plus avoir a maintenir ces portions de code... et de pouvoir continuer a utiliser les versions suivantes des produits.
Boarf.
bugzilla n'est pas *si* compliqué que ca.
par contre certains bugs sont plus facile a décrire que d'autres.
par exemple
- "le driver ibmtr_cs" ne compile pas c'est facile a écrire :-))
- le driver synaptics (touchpad) devrait integrer les derniers patchs c'est plus dur (ca veut dire que t'a testé les patchs ...)
Pour les emails j'utilise MailScanner qui s'interface avec plein d'antivirus....
dont mcafee viruscan (version linux) avec updates en ftp sur leur site (dans un cron ...) et qui doit pouvoir scanner tes partitions samba.
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.
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 ?
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).
Certes mais c'est un choix stratégique que tu fais la:
"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.
Une connection c'est IPsource+Portsource->IP dest+PortDest.
donc sur les connections deja etablies (--state ESTABLISHED) y a plus grand chose a dire sinon faire du filtrage applicatif !!
>>ton CPU sera content :-)
>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.
Il n'est pas besoin d'utiliser --state NEW pour reperer les paquets de "demande de connexion" et faire du tracking.
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.
Tu as tout a fait raison, il y avait d'ailleur des packetages kernel-uml distribués avec les RedHat 7.x
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 ??
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 ?
Tu n'as pas été voir le lien que je te donne, MailScanner detache les pièces jointes pour les passer a l'antivirus. il y a donc dans MailScanner (en perl) toute la logique dont tu as beosin pour ton projet.
non.
la première c'est la SLS avec laquelle j'ai commencé linux (et qui a disparu depuis).
dailleur si tu lis le message de 93 posté avec la news, le createur de la slackware annonce que sa distribution est basee sur la SLS et que ses packages "A" (une serie de disquettes) sont en fait la compilation des packages "A"+"B"+"C" de la SLS originale.
Exactement.
Avec NFS ton filesysteme (ext3 par exemple) est monté par un serveur qui va l'exporter a plusieurs clients (en NFS).
Si tu veux fiabiliser cela et le rendre scalable (montée en charge), tu va etre tenté de multiplier les serveurs NFS en parallele.
Probleme: un filesysteme ext3 ne peut pas etre monté en parallele par plusieurs machines sinon il y a risque de corruption de données (en fait il y a corruption de données garantie :-)).
D'ou GFS qui est un filesysteme qui résoud exactement ce probleme: plusieurs machines peuvent le monté en parallele, voir meme le ré-exporter en NFS si tu veux le rendre dispo a travers ton réseau.
==> redondance, montée en charge ... ou simple partage de data de clusters.
[^] # Re: Un journaliste de Micro Hebdo a passé une semaine avec Linux
Posté par PLuG . En réponse à la dépêche Un journaliste de Micro Hebdo a passé une semaine avec Linux. Évalué à 4.
Je suis chez un client ou les postes (portables la plupart) sont sous windows principalement. Ceux qui sont sous linux (une dizaine autour de moi déjà) sont en redhat avec Gnome.... AUCUN KDE a l'horizon (ou alors je l'ai pas vu).
les serveurs sont en redhat mais sans X11 ...
comme quoi faut pas tirer des conclusions basées sur un échantillon trop restreint hein :-)
[^] # Re: up2date cassé
Posté par PLuG . En réponse au journal up2date cassé. Évalué à 2.
-> c'est lent (beaucoup plus lent)
-> impossible de preciser la version des packages que l'on veut installer
...
alors que apt-get pour rpm a fait de net progrès ces derniers temps
(plus de fork de rpm en sous main mais linké avec la librpm ....)
alors quand RedHat aura amélioré yum on re-testera le biniou mais pour le moment "nous" (moi,mes potes, ma boite) restons avec apt-get :-)
de plus yum c'est en pyhton ... ok -->[]
[^] # Re: La commission Européenne juge Microsoft coupable "d'abus de position extraordinairement dominante"
Posté par PLuG . En réponse à la dépêche La commission européenne accuse Microsoft d'être coupable "d'abus de position extraordinairement dominante". Évalué à -1.
comme celui-ci d'ailleur.
[^] # Re: Gentoo 1.4 est (enfin) sortie
Posté par PLuG . En réponse à la dépêche Gentoo 1.4 est (enfin) sortie. Évalué à 1.
il y a un article qui explique comment sur IBM: http://www-106.ibm.com/developerworks/linux/library/l-dll.html?dwzo(...)
bon ben y'a plus qu'a patcher joyeusement la plupart des applis pour que ca dlopen en masse :-)
[^] # Re: L'Empire du disque contre-attaque, cette fois en Europe !
Posté par PLuG . En réponse à la dépêche L'Empire du disque contre-attaque, cette fois en Europe !. Évalué à -1.
HS mais le deploiement de force contre les exces de vitesse sur voies rapides (autoroutes) ne part pas non plus d'une *démonstration* ni ne sont soutenues par les chiffres (sinon des gains en taxe pour l'état).
Les autoroutes ou l'ont roule le plus vite sont les routes les moins meurtrières ... a peine 6% des tués pour des millions de km effectués tous les ans.
Ramené au nombre de km la différence penche encore plus pour ces voies "rapides".
Bref, ici on s'occupe de la liberté de copie , sur d'autres forum on s'occupe de la liberté de "rouler" et je veillerai a ne plus me tromper de forum :-))
--> []
[^] # Re: Pas mal les arguments!!
Posté par PLuG . En réponse à la dépêche Projet de refonte du site Internet de la ville de Lyon. Évalué à 1.
un autre truc: l'hebergement mis a dispo par COLT: lien vers les internautes: 2Go ??
2Go soit 16Gb/s ???
ouaou !! faudrait faire héberger un serveur UT sur ces machines redhat :-))
# Pas mal les arguments!!
Posté par PLuG . En réponse à la dépêche Projet de refonte du site Internet de la ville de Lyon. Évalué à 1.
l'avantage de l'open source (après le cout - evident en licenses):
+ repondre finement aux besoin ("modèle mixte entre le produit et le developpement spécifique")
+ cout de maintenance : ils veulent parvenir a faire integrer leurs modifications/apports au produit GPL de manière a ne plus avoir a maintenir ces portions de code... et de pouvoir continuer a utiliser les versions suivantes des produits.
[^] # Re: Le noyau 2.6-test2 est disponible
Posté par PLuG . En réponse à la dépêche Le noyau 2.6-test2 est disponible. Évalué à 1.
bugzilla n'est pas *si* compliqué que ca.
par contre certains bugs sont plus facile a décrire que d'autres.
par exemple
- "le driver ibmtr_cs" ne compile pas c'est facile a écrire :-))
- le driver synaptics (touchpad) devrait integrer les derniers patchs c'est plus dur (ca veut dire que t'a testé les patchs ...)
[^] # Re: Le noyau 2.6-test2 est disponible
Posté par PLuG . En réponse à la dépêche Le noyau 2.6-test2 est disponible. Évalué à 4.
[^] # Re: tout le temps online
Posté par PLuG . En réponse au sondage Ma connexion haut débit est active en moyenne :. Évalué à 1.
Comme le pppoe en userspace est conseillé j'y suis resté.
# Re: Des Antivirus dans ma Debian ?
Posté par PLuG . En réponse au journal Des Antivirus dans ma Debian ?. Évalué à 1.
dont mcafee viruscan (version linux) avec updates en ftp sur leur site (dans un cron ...) et qui doit pouvoir scanner tes partitions samba.
[^] # Re: Documentation: Firewall [...] que du bonheur ;o)
Posté par PLuG . En réponse à la dépêche Documentation: Firewall et sécurité d'un réseau personnel sous Linux. É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 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é à 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 PLuG . En réponse à la dépêche Documentation: Firewall et sécurité d'un réseau personnel sous Linux. É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 PLuG . En réponse à la dépêche Documentation: Firewall et sécurité d'un réseau personnel sous Linux. É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 PLuG . En réponse à la dépêche Documentation: Firewall et sécurité d'un réseau personnel sous Linux. É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 PLuG . En réponse à la dépêche Documentation: Firewall et sécurité d'un réseau personnel sous Linux. É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 PLuG . En réponse à la dépêche Documentation: Firewall et sécurité d'un réseau personnel sous Linux. É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 . En réponse à la dépêche Documentation: Firewall et sécurité d'un réseau personnel sous Linux. É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 PLuG . En réponse à la dépêche Documentation: Firewall et sécurité d'un réseau personnel sous Linux. É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 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 ?
[^] # Re: Bijour, bijour
Posté par PLuG . En réponse au journal Bijour, bijour. Évalué à 1.
# Re: Comment enregistrer une émission en flux real rm
Posté par PLuG . En réponse au journal Comment enregistrer une émission en flux real rm. Évalué à 3.
reglez realplay pour qu'il utilise le daemon esd comme sortie son
enregistrez avec esdmon ...
c'est la meme chose sans compiler/installer rien de plus :-))
[^] # Re: Slackware a 10 ans !
Posté par PLuG . En réponse à la dépêche Slackware a 10 ans !. Évalué à 4.
non.
la première c'est la SLS avec laquelle j'ai commencé linux (et qui a disparu depuis).
dailleur si tu lis le message de 93 posté avec la news, le createur de la slackware annonce que sa distribution est basee sur la SLS et que ses packages "A" (une serie de disquettes) sont en fait la compilation des packages "A"+"B"+"C" de la SLS originale.
[^] # Re: Sistina announce Sistina GFS 5.2
Posté par PLuG . En réponse à la dépêche Sistina announce Sistina GFS 5.2. Évalué à 1.
Avec NFS ton filesysteme (ext3 par exemple) est monté par un serveur qui va l'exporter a plusieurs clients (en NFS).
Si tu veux fiabiliser cela et le rendre scalable (montée en charge), tu va etre tenté de multiplier les serveurs NFS en parallele.
Probleme: un filesysteme ext3 ne peut pas etre monté en parallele par plusieurs machines sinon il y a risque de corruption de données (en fait il y a corruption de données garantie :-)).
D'ou GFS qui est un filesysteme qui résoud exactement ce probleme: plusieurs machines peuvent le monté en parallele, voir meme le ré-exporter en NFS si tu veux le rendre dispo a travers ton réseau.
==> redondance, montée en charge ... ou simple partage de data de clusters.