Journal iptables, un futur firewall applicatif ?

Posté par mcjyc (site web personnel) le 06 octobre 2004 à 15:24.

Étiquettes : aucune

oct.

2004

bonjour cher journal,

voila 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

# options iptables

Posté par Colin Leroy (site web personnel) le 06 octobre 2004 à 15:38. Évalué à 9.

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)
# proxy transparents..

Posté par Pierre le 06 octobre 2004 à 15:47. Évalué à 7.

ce qui peut etre utile, c'est pour les proxy transparents..

iptables -A FORWARD -m layer7 --l7proto http -j DNAT --to-destination myproxy
# pareil

Posté par TImaniac (site web personnel) le 06 octobre 2004 à 15:53. Évalué à 1.

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. le 06 octobre 2004 à 16:21. É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...
  - [^] # Re: pareil
    
    Posté par Victor le 07 octobre 2004 à 07:32. É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 octobre 2004 à 10:02. É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 octobre 2004 à 16:43. É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 (site web personnel) le 06 octobre 2004 à 19:34. É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 octobre 2004 à 19:07. É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 octobre 2004 à 19:29. É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 Benjamin (site web personnel) le 06 octobre 2004 à 20:10. Évalué à 3.
      
      non, tout est crypte en https. Par contre le firewall applicatif peut filtrer sur du 'ssl'. Mais dans ce cas, il verra de la meme maniere ssh, https, imaps ...
      - [^] # Re: pareil
        
        Posté par Pierre le 07 octobre 2004 à 11:33. Évalué à 2.
        
        Il y a forcément qq trames d'échange de clef publique certifiées qui doivent avoir un fingerprint spécial
  - [^] # Re: pareil
    
    Posté par PLuG le 09 octobre 2004 à 14:54. É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 (site web personnel) le 07 octobre 2004 à 09:55. É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 octobre 2004 à 03:41. Évalué à 2.
    
    Tu vois ou un patch ? Il faut simplement rajouter le numero du port dans la registry.
# hum...

Posté par mcjyc (site web personnel) le 06 octobre 2004 à 16:11. Évalué à 4.

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 (site web personnel) le 06 octobre 2004 à 17:27. É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

Posté par Sixtiz (site web personnel) le 06 octobre 2004 à 17:39. Évalué à 3.

> 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 (site web personnel) le 06 octobre 2004 à 17:56. Évalué à 2.
  
  Et le modèle OSI, il est standardisé par qui ? ;-)
- [^] # Re: Petit détail
  
  Posté par JoeBar le 06 octobre 2004 à 18:20. É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
    
    Posté par Alvarez le 06 octobre 2004 à 19:13. Évalué à 5.
    
    Non, OSI veut dire ici Open Systems Interconnection et on parle bien du modèle OSI (même s'il est effectivement standardisé par l'ISO).
  - [^] # Re: Petit détail
    
    Posté par Amand Tihon (site web personnel) le 06 octobre 2004 à 19:21. É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
      
      Posté par JoeBar le 13 octobre 2004 à 19:05. Évalué à 2.
      
      Ah bon. Et pourtant j'étais sincère !
      Merci de ces précisions, je me coucherai moins bête ce soir.
# Partagez votre sciences...

Posté par Seneque Xavier le 06 octobre 2004 à 23:07. Évalué à -4.

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 (site web personnel) le 07 octobre 2004 à 00:00. Évalué à -3.
  
  Le nouvel Omo !
  
  Il lave plus blanc ;)
- [^] # Re: Partagez votre sciences...
  
  Posté par Seneque Xavier le 07 octobre 2004 à 07:42. É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 le 07 octobre 2004 à 08:05. É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 octobre 2004 à 09:50. É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

Posté par _seb_ le 07 octobre 2004 à 11:31. Évalué à 3.

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
  
  Posté par jigso le 07 octobre 2004 à 12:04. Évalué à 3.
  
  Tiens une idée en passant, on pourrait étendre le concept et faire un firewall applicatif qui ne laisse passer que les pages html valides, ça allègerait sacrément le web !
- [^] # Re: Protocoles supportés par L7-filter
  
  Posté par Foxy (site web personnel) le 07 octobre 2004 à 14:42. É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.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.