Derniers journaux de dunain :
- [11/06@13:16] mon sympa n'est pas sympa...
- [14/05@13:40] turck mmcache...
- [05/02@10:27] recherche CMS non java...
- [30/01@17:54] internet et microsoft...
- [13/06@14:45] eh eh eh
- [13/06@14:43] weblog !
Journal : iptables, un futur firewall applicatif ?
Posté par mcjyc (page perso, ) le 06 octobre 2004voila l'aventure que j'ai vécue aujourd'hui...
un collègue jouant avec son AP wifi m'a fait découvrir le projet layer7...
ça commence toujours de la même manière...
"tu connais layer7 ?"...
"euh... non, ça parle de quoi ?"
et c'est la que ça commence...
c'est comme une recette de cuisine, ça fait saliver...
il existe des patchs disponible sur http://l7-filter.sourceforge.net(...)
qui permettent à iptables de se comporter en partie comme un firewall applicatif.
ce qui signifie pour ceux qui le découvriraient, qu'il pourrait taper sur la couche 7 du modèle iso, et non plus seulement sur la couche 3...
(c'est plus clair hein ? :-) )...
voila ce que j'ai fait.
j'ai téléchargé un noyau 2.4.27 ftp://ftp.kernel.org(...)
j'ai téléchargé le patch ebtables (pour en faire un bridge-firewall transparent) à l'adresse suivante :
http://ebtables.sourceforge.net/(...)
et le patch l7layer à l'adresse suivante : http://sourceforge.net/projects/l7-filter/(...)
on obtient les fichiers suivants :
l7-protocols-2004_09_13.tar.gz
linux-2.4.27.tar.gz
netfilter-layer7-v0.9.1.tar.gz
ebtables-brnf-7_vs_2.4.27.diff.bz2
pour patcher tout cela, ce n'est pas bien difficile, et c'est plutot bien expliquer dans la doc :
on se place dans /usr/src/linux
puis, on lance un
patch -p1 avec le fichier qui va bien (voir doc)
on fait de meme pour netfilter.
à la compilation du noyau, on demande à acceder aux modules experimentaux.
on choisit d'avoir le support du bridge, et du layer7, ainsi que tout ce qu'il faut pour un firewall...
mais ce journal n'est pas l'endroit pour apprendre ca, n'est il pas ?
on recompile le tout, on modifie son lilo, on reboot.
paf... deux cartes reseaux...
en avant pour les tests !
(pour ce qui est de la configuration du bridge, je vous conseillerais de lire la doc tres bien faite sur http://ebtables.sourceforge.net/(...))
en gros, il faut les bridge-tools... et taper qqch comme ca
brctl addbr br0
brctl addif br0 eth0
brctl addif br0 eth1
brctl setfd br0 1
ifconfig br0 up
ifconfig eth0 up
ifconfig eth1 up
on verifie son iptables :
which iptables
/usr/local/sbin/iptables
ca roule !
iptables -A FORWARD -m layer7 --l7proto http -j LOG
on se lance un apache sur le port 81...
on verifie qu'il marche bien...
que ca loggue bien au niveau firewall...
ensuite, on ferme !
iptables -A FORWARD -m layer7 --l7proto http -j DROP
et la, Ô miracle !
plus de web !
bon, c'est encore experimental encore...
mais c'est une tres bon debut.
c'est pas bien compliqué à mettre en place, j'ai moi meme reussi...
il y a environ une soixantaine de 60 protocoles plus ou moins detectés...
à vous de jouer !
ps : desolé pour les accents perdus...
ps/2: merci à mon collegue de m'avoir fait decouvrir ce nouveau jouet
> Lire le journal (31 commentaires, moyenne: 2,5).
options iptables
voir aussi les options iptables qui permettent de faire des règles spécifiques par utilisateur et/ou processus:
--uid-owner userid
Matches if the packet was created by a process with the given
effective user id.
--gid-owner groupid
Matches if the packet was created by a process with the given
effective group id.
--pid-owner processid
Matches if the packet was created by a process with the given
process id.
--sid-owner sessionid
Matches if the packet was created by a process in the given ses-
sion group.
--cmd-owner name
Matches if the packet was created by a process with the given
command name. (this option is present only if iptables was com-
piled under a kernel supporting this feature)
pareil
tiens ça me fait penser que je viens de lire celà : http://www.presence-pc.com/news/ISA-le-firewall-de-Microsoft-n5268.(...)
(je ne cherche pas à troller, c'est juste rigolo comme hasard :) )
-
[^]Re: pareil
Posté par Ju. (Jabber id, ) le 06/10/2004 à 14:21. (lien). Évalué à 5.(je ne cherche pas à troller, c'est juste rigolo comme hasard :) )
En effet par contre, le gars de Microsoft ne se prive pas du troll :
Si un train va de la Gare du Nord à celle de Waterloo (Londres), par l'Eurostar, vous lui accordez la permission de rentrer dans le pays parce que vous lui faites confiance. C'est ce que font actuellement les firewall. Ils ne regardent pas si Al Quaeda est à l'intérieur.
C'est assez limite comme propos...
Je ne dis pas qu'il n'y a jamais eu de terroriste en France, mais prendre cet exemple n'est pas anodin et c'est déplacé, meme si on parle de sécurité informatique.
Bon et moi je suis HS...--
Les fans de Ubuntu et leurs CD, c'est comme les Mormons avec leur évangile, ils en ont toujours sur eux à donner, au cas où.
Zorro.-
[+] [^]Re: pareil
Posté par kaouete (page perso, ) le 07/10/2004 à 05:32. (lien). Évalué à -4.Faut arreter, c'est une tres bonne image et rigolotte, on fait de l'info, pas de la politique !!
-
[^]Re: pareil
Posté par deftones_chris () le 07/10/2004 à 08:02. (lien). Évalué à 3.En effet par contre, le gars de Microsoft ne se prive pas du troll
En quoi c'est du troll ?
C'est une image qui est d'un goût douteux aux yeux de certaines personnes (dont tu fais partie apparemment).
-
-
[^]Re: pareil
Posté par sk () le 06/10/2004 à 14:43. (lien). Évalué à 3.D'autant plus que je ne sais pas vraiment d'ou il a pris ses sources...
La plupart des firewalls commerciaux (Checkpoint, Watchguard, etc.) le font déjà depuis pas mal de temps...
Tout l'art du marketing consiste à vendre un "vieux" concept comme s'il s'agissait d'une révolution :)-
[^]Re: pareil
Posté par TImaniac (page perso, ) le 06/10/2004 à 17:34. (lien). Évalué à 3.Pourtant c'est bizzare, celà me fait drôlement penser à ce que cherchait à faire je-sais-plus-quelle-étude qui visait à filtrer les protocoles P2P... Il n'existait que 2 ou 3 solutions techniques sur le marchée, et aucune situé au niveau utilisateurs Windows... Cependant je peux me tromper, la technique est peut-être complètement différent, d'ailleur si quelqu'un a plus d'infos à ce sujet.
-
-
[^]Re: pareil
Posté par pasPierre pasTramo () le 06/10/2004 à 17:07. (lien). Évalué à 1.Je vois mal comment vérifier le contenu du traffic s'il est chiffré, par exemple comment surveiller le traffic https ?
-
[^]Re: pareil
Posté par mr_moustache () le 06/10/2004 à 17:29. (lien). Évalué à 2.J'avoue ne pas être un spécialiste des trames réseaux, mais il me semble que c'est le contenu (les données) qui sont cryptées dans l'https. L'entête elle, doit être lisible non?
-
[^]Re: pareil
Posté par PLuG () le 09/10/2004 à 12:54. (lien). Évalué à 1.> Je vois mal comment vérifier le contenu du traffic s'il est chiffré, par exemple comment surveiller le traffic https ?
le produit commercial que je connais qui fait cela (verifier le https) ne se gène pas: il est installé sur le proxy http/https et fait "tout simplement" une attaque "man in the middle": le client se connecte sur le proxy en question au lieu du serveur distant (mais avec un certificat reconnu dans l'entreprise ...), et le proxy dechiffre tout pour controler le contenu.
-
-
[^]Re: pareil
Posté par Karles Nine (page perso, ) le 07/10/2004 à 07:55. (lien). Évalué à 2.En même temps ISA faut le patcher simplement pour ouvrir un port non standard en https:
http://support.microsoft.com/default.aspx?scid=kb;fr;283284(...)
Deux jours de galère avec un con certifier MS qui accusait mon serveur apache, sacré souvenir.
Enjoy-
[^]Re: pareil
Posté par pasBill pasGates () le 08/10/2004 à 01:41. (lien). Évalué à 2.Tu vois ou un patch ? Il faut simplement rajouter le numero du port dans la registry.
-
hum...
je ne sais pas quel est l'idiot qui a ecris "une soixantaine de 60"...
mais c'est un sacré bouffon...
allez, hop ! -1
;-)
j'aurais du mieux me relire...
-
[^]Re: hum...
Posté par chl (page perso, ) le 06/10/2004 à 15:27. (lien). Évalué à 3.je ne sais pas quel est l'idiot qui a ecris "une soixantaine de 60"...
mais c'est un sacré bouffon...
C'est clair !
j'aurais du mieux me relire...
Ça n'aurait rien changé, t'est qu'un sacré bouffon de toute façon /o\.
Petit détail
> il pourrait taper sur la couche 7 du modèle iso
Attention, c'est le modèle OSI dont il s'agît, et non ISO.
-
[^]Re: Petit détail
Posté par Matthieu Moy (page perso, ) le 06/10/2004 à 15:56. (lien). Évalué à 2.Et le modèle OSI, il est standardisé par qui ? ;-)
-
[+] [^]Re: Petit détail
Posté par JoeBar () le 06/10/2004 à 16:20. (lien). Évalué à -2.ISO = International Standardisation Organism
OSI = Organisme de Standardisation International
Donc ce n'est pas faux, et ISO est plus répandu, même si en parlant francais on devrait dire OSI.
(NB c'est peut etre Organisation et pas Organisme... mais bon c'est pas le propos)
P.S : "il s'agit" ne prend pas de " î " :)-
[^]Re: Petit détail
-
[^]Re: Petit détail
Posté par Amand Tihon (page perso, ) le 06/10/2004 à 17:21. (lien). Évalué à 2.Perdu.
ISO = International Organization for Standardization.
Ce n'est pas une abréviation, c'est un nom (dont la recherche de l'étymologie est laissée au lecteur). Ca permet de garder le même terme dans toutes les langues.
OSI, lui, est bien une abréviation, mais alvarez en a déjà parlé.-
[^]Re: Petit détail
-
-
[+] Partagez votre sciences...
et dites moi, en gros, ce que ça va changer ?
iptables filtrait deja bien ?
il va filtrer mieu ?
quelle serait la difference ?
-
[+] [^]Re: Partagez votre sciences...
Posté par Benjamin (Jabber id, page perso, ) le 06/10/2004 à 22:00. (lien). Évalué à -3.Le nouvel Omo !
Il lave plus blanc ;)
-
[+] [^]Re: Partagez votre sciences...
Posté par Seneque Xavier (page perso, ) le 07/10/2004 à 05:42. (lien). Évalué à -2.je suis sérieu... ça va apporter quoi de passer de la couche 3 à la 7 ?
-
[^]Re: Partagez votre sciences...
Posté par PedroLane (page perso, ) le 07/10/2004 à 06:05. (lien). Évalué à 7.deja netfilter fait de la couche 4 (tu peux jouer sur les ports tcp et udp)
faire du niveau 7 permet d éviter que qqun profite que le port 80 est ouvert pour passer autre chose dedans. par exemple si je mets un serveur ssh sur ma machine chez moi, je la mets en ecoute sur tcp/80 au lieu de tcp/22. depuis ma boite (qui ne laisse sortir que du tcp/80) je peux me connecter à mon serveur ssh en faisant du ssh sur le port 80.
cette fonctionnalité permet d aller vérifier que ce qui passe au niveau 7 est bien de l http et rien d autre.
les fonctionnalités qui manquent à netfilter par rapport au gros FW commerciaux (checkpoint) :
- analyse applicative (layer 7)
- stateful failover (mirroring des tables de connexions entre deux FW actif/passif)
- fonctionnement en "cluster" (il y a des solutions mais bon)
packet filter (noyau bsd) inclut le staeful failover par exemple
c est donc un très bon point pour linux
Pedro-
[^]Re: Partagez votre sciences...
Posté par jigso () le 07/10/2004 à 07:50. (lien). Évalué à 10.cette fonctionnalité permet d aller vérifier que ce qui passe au niveau 7 est bien de l'http et rien d autre.
Reste toujours la possibilité d'utiliser httptunnel... Et là un firewall applicatif ne verra rien - a moins qu'il filtre également sur le contenu, mais il suffit de changer le système d'encapsulation pour que le firewall n'y voit que du feu (tiens c'est marrant ça). Bref, c'est pas si simple en fait.
-
-
Protocoles supportés par L7-filter
Plusieurs des protocoles supportés par L7-filter sont notés "parfait". Par exemple, le protocole HTTP.
L7-filter reconnaît le protocole via des expressions régulières enregistrées dans des fichiers .pat. Pour le protocole HTTP, ça se résume à une ligne (voir http://l7-filter.sourceforge.net/layer7-protocols/protocols/http.pa(...)).
Je crois qu'il est tout à fait possible de créer des paquets non-conformes à la RFC et qui serait pourtant acceptés par les expressions régulières.
En fait, les expressions régulières ne me semblent pas suffisantes pour décrire un protocole entier. Une grammaire plus formelle (avec Lex/Yacc par exemple) permettrait sans doute de dire que le protocole est parfaitement conforme à la RFC.
Enfin, je me trompe peut être.
-
[^]Re: Protocoles supportés par L7-filter
-
[^]Re: Protocoles supportés par L7-filter
Posté par Foxy (page perso, ) le 07/10/2004 à 12:42. (lien). Évalué à 3.Tout à fait, tu ne te trompes pas de tout.
Les expressions régilières utilisées par le projet Layer7 sont beaucoup trop faciles à contourner : le filtre layer7 ne vérifie que la présence de données applicatives correspondant à une regexp dans l'ensemble des données.
Il n'y a pas de notion de "contexte" applicatif !
Par exemple pour HTTP, il faudrait vérifier :
- que les commandes sont dans la liste des commandes reconnus en HTTP d'après la RFC (GET, POST, HEAD, OPTIONS...)
- qu'après une commande valide, on doit avoir un URL ou non (pas après HEAD par exemple, mais obligatoire après GET...)
- qu'une URL a une syntaxe valide...
Enfin voila pourquoi, le projet Layer7 n'atteint pas aujourd'hui la qualité et la pertinence des firewalls applicatifs "industriels".
Layer7 peut être bien pour faire de la QoS (avec tc) car se tromper sur de l'analyse de protocole n'est pas "trop" génant, pas contre pour faire du filtrage, c'est trop facile à mettre en échec avec quelques outils simples.
C'est d'ailleurs pour cela que les devs principaux du projet PF (packet filter d'OpenBSD) ont toujours refusés d'ajouter ce genre de fonction à PF : pas sûr si ça n'utilise que des regexp.
Les journaux sont destinés à des informations qui ne sont pas suffisamment intéressantes
pour être validées en dépêche (sinon n'hésitez pas à proposer votre information en
dépêche), qui sont sans rapport avec Linux ou le libre, ou simplement pour donner votre
avis. Si vous désirez poser une question, merci d'utiliser 

Cette discussion est archivée, il n'est plus possible de laisser des commentaires.
Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.