Avec un peu de chance, je devrais pouvoir m'en sortir avec la version "non commerciale" de QT (2.3) pour Windows, et ainsi que Wine pour l'environnement utilisateur.
A propos de QT : J'ai en projet de développer une appli GPL sous QT, qui puisse fonctionner sous Linux et Windows.
Pour ce qui est de la compilation sous Linux, je pense que cela ne devrait pas trop poser de problème. Mais comment est-ce que je peux compiler (et éventuellement débugger) la version Windows, sachant que je n'ai ni Windows, ni Visual Studio ? Est-ce que je peux faire de la cross-compilation de la version Windows du programme tout en étant sous Linux ? Vous avez des liens sur le sujet ?
Ou faut t'il passer par une solution "lourde" comme wmWare et avoir un environnement Windows complet ? :=(
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.
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 ! :=)
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 ...).
Qq erreurs/oublis a droite a gauche :
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...
Pourquoi avoir également fait un fichier powerpoint ? Je pense que ce format n'a vraiment pas besoin de publicité (et ne le mérite pas d'ailleurs).
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.
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.
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".
espèce de Frontpage Express :p
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.
Je suis d'accord avec toutes argumentations, et je me rends compte d'ailleurs que je n'ai pas écrit le paragraphe que j'avais prévu, sur le choix de la stratégie de filtrage dont tu parles.
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.
après traceroute, lsof, nmap, ifconfig, et autres, who aurait bien pu figurer dans les outils standards cités
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"
argument accepté mais tout de meme tordu amha :-))
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".
Une autre amélioration possible, à la fin du document, c'est de donner une petite liste de ports avec l'application qui l'utilise, par exemple.
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
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".
Vraiment ? Ça m'étonne un tout petit peu, t'es sûr que ça ne rentrait pas dans le cadre d'une utilisation normale ?
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.
est-ce que les règles iptables sont persistantes ou est-ce qu'il faut les relancer à chaque reboot de mon portable ? Si oui (et j'ai l'impression que c'est oui), comment faire pour l'automatiser ?
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 !
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.
En revanche, c'est effectivement à cette date qu'il a été officiellement mergé au noyau. Maintenant cette "nouvelle" fonctionnalité est en marche(développement) depuis 2000.
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.
Excellent le topo sur les firewall applicatifs ! ... je ne savais même pas que c'était possible...
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.
Bravo et Merci de nous amener ou rafraîchir nos connaissances.
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: Sortie de Qt 3.2
Posté par Olivier (site web personnel) . En réponse à la dépêche Sortie de Qt 3.2. Évalué à 1.
[^] # Re: Sortie de Qt 3.2
Posté par Olivier (site web personnel) . En réponse à la dépêche Sortie de Qt 3.2. Évalué à 1.
http://www.trolltech.com/developer/compilers/bcpp.html(...) :
Qt supports Borland C++ Builder 5 (bcc32 5.5) and newer Qt versions (Qt 3.0.5 or higher) support Borland C++ Builder 6 (bcc32 5.6) as well.
Or, la version du compilateur bc32 5.5 est librement téléchargement sur le site de Borland :
http://www.borland.com/products/downloads/download_cbuilder.html(...) et http://community.borland.com/article/0,1410,20633,00.html(...) :
Our latest ANSI C/C++ compiler technology, the Borland® C++ 5.5 Compiler and associated command line tools, is now available for free download on our Web site.
Avec un peu de chance, je devrais pouvoir m'en sortir avec la version "non commerciale" de QT (2.3) pour Windows, et ainsi que Wine pour l'environnement utilisateur.
Merci à tous pour vos posts
[^] # Re: Sortie de Qt 3.2
Posté par Olivier (site web personnel) . En réponse à la dépêche Sortie de Qt 3.2. Évalué à 1.
[^] # Re: Sortie de Qt 3.2
Posté par Olivier (site web personnel) . En réponse à la dépêche Sortie de Qt 3.2. Évalué à 1.
Pour ce qui est de la compilation sous Linux, je pense que cela ne devrait pas trop poser de problème. Mais comment est-ce que je peux compiler (et éventuellement débugger) la version Windows, sachant que je n'ai ni Windows, ni Visual Studio ? Est-ce que je peux faire de la cross-compilation de la version Windows du programme tout en étant sous Linux ? Vous avez des liens sur le sujet ?
Ou faut t'il passer par une solution "lourde" comme wmWare et avoir un environnement Windows complet ? :=(
[^] # Re: Autres Petites erreurs
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é à 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 ! :=)
[^] # Re: Documentation: Firewall [...] que du bonheur ;o)
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é à 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 ...).
[^] # Re: Autres Petites erreurs
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é à 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: 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é à 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 Olivier (site web personnel) . En réponse à la dépêche Documentation: Firewall et sécurité d'un réseau personnel sous Linux. É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: Orthographe
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é à 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: 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é à 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 [...] que du bonheur ;o)
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.
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: IP spoofing suite
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é à 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 Olivier (site web personnel) . En réponse à la dépêche Documentation: Firewall et sécurité d'un réseau personnel sous Linux. É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".
[^] # 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é à 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 !
# Mise à disposition de la documentation
Posté par Olivier (site web personnel) . En réponse à la dépêche Conférence: Firewall et sécurité d'un réseau personnel sous Linux. Évalué à 1.
La news a été publié aujourd'hui sur Linux FR : http://linuxfr.org/2003/07/21/13334.html(...)
[^] # Re: Orthographe
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é à 2.
Bah, c'est des RFC quoi.. :=)))
Pas de problème, je corrigerais tout cela.
[^] # 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é à 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 Olivier (site web personnel) . En réponse à la dépêche Documentation: Firewall et sécurité d'un réseau personnel sous Linux. É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 Olivier (site web personnel) . En réponse à la dépêche Documentation: Firewall et sécurité d'un réseau personnel sous Linux. É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) . 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.
[^] # Re: Orthographe
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é à 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: 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é à 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 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.
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.
[^] # 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.
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 !