Journal iptables, un futur firewall applicatif ?

Posté par  (site web personnel) .
Étiquettes : aucune
0
6
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  (site web personnel) . É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  . É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  (site web personnel) . É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  . É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  . É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  . É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  . É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  (site web personnel) . É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  . É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  . É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  (site web personnel) . É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  . É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  . É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  (site web personnel) . É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  . Évalué à 2.

        Tu vois ou un patch ? Il faut simplement rajouter le numero du port dans la registry.
  • # hum...

    Posté par  (site web personnel) . É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  (site web personnel) . É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  (site web personnel) . É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  (site web personnel) . Évalué à 2.

      Et le modèle OSI, il est standardisé par qui ? ;-)
    • [^] # Re: Petit détail

      Posté par  . É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  . É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  (site web personnel) . É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  . É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  . É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  (site web personnel) . Évalué à -3.

      Le nouvel Omo !

      Il lave plus blanc ;)
    • [^] # Re: Partagez votre sciences...

      Posté par  . Évalué à -2.

      je suis sérieu... ça va apporter quoi de passer de la couche 3 à la 7 ?
      • [^] # Re: Partagez votre sciences...

        Posté par  . É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  . É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  . É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  . É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  (site web personnel) . É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.