Le OpenBSD Packet Filter HOWTO est sorti

Posté par  (site web personnel) . Modéré par Val.
Étiquettes : aucune
0
25
sept.
2001
OpenBSD
Suite aux problèmes de licences du filtre de paquets (système de firewalling) IPFilter sur OpenBSD, un nouveau filtre PF le remplace.

La première version du HOWTO de ce nouveau filtre de paquets, vient de sortir. En gros, PF reprend la syntaxe d'IPFilter et permet donc une migration facile.

Aller plus loin

  • # Bonjour, je viens foutre la merde

    Posté par  . Évalué à -5.

    Désolé, c'etait une feinte !

  • # Portage Linux?

    Posté par  . Évalué à 8.

    Et peut on esperer que la bete soit portée sur linux aussi (comme cela a été fait pour openssh)?
    Ou est ce trop dépendant du kernel et il faudrait tout réécrire?

    • [^] # Re: Portage Linux?

      Posté par  (site web personnel) . Évalué à 10.

      Ce serait effectivement intéressant car perso, je trouve la syntaxe de IPF/PF plus simple que celle de IPTables/Netfilter.

      Mais l'implémentation des piles TCP/IP Linux et BSD* sont assez différentes et cela obligerait à un gros travail de portage.

      Il faut savoir qu'Ipfilter fonctionnait jusqu'aux noyaux de la série 2.0 mais que le portage fût abandonné pour les séries suivantes car le dvpt était trop important et que Linux a son propre système de FW :-(

      De plus, IPFilter nécessitait des modifs pour compiler et fonctionner sur OpenBSD par rapport à la branche de développement général. Donc l'implémentation OpenBSD est déjà une particularité, alors celles entre Linux et BSD*, bonjour la masse de boulot. (enfin à mon avis, car je ne me suis jamais penché en détail sur les différences des codes des piles TCP/IP).

      • [^] # Re: Portage Linux?

        Posté par  (site web personnel, Mastodon) . Évalué à 4.

        Pourquoi le porter alors que iptables est; je crois; plus puissant ?

        • [^] # Re: Portage Linux?

          Posté par  (site web personnel) . Évalué à 10.

          La syntaxe d'Ipf est très largement plus compréhensible que celle d'IPTables, et dans le cadre de la configuration d'un firewall, c'est un point non négligeable, car la simplicité de la mise en oeuvre réduit sérieusement les risques d'erreurs, chose primordialement pour un élément de sécurité comme un firewall.

          (et puis en plus iptables n'est pas supérieur à ipf en ce qui concerne le filtrage ip, cf les bugs "de jeunesse" d'IPtables http://www.securityfocus.com/bid/2602(...) ).

          • [^] # Re: Portage Linux?

            Posté par  . Évalué à 5.

            Les bugs c'est vite dit. Il y a en eu un seul. Quand a PF, il est trop recent pour qu'on puisse juge. Quand au bug de Netfilter, il etait sur le protocole helper des connexions FTP. Je ne sais meme pas si PF possede un protocol helper (ils n'en parlent pas sur leurs sites).

            Quand a lisibilite des regles, c'est une histoire de gout... Moi je ne trouve les regles IPTables complexes a lire.

            entre
            block in quick on kue0 from 10.0.0.0/8 to any
            et
            iptables -I INPUT -i eth0 --source 10.0.0.0/8 -j DROP

            je ne vois pas trop en quoi l'une est plus simple ou plus complexe

            • [^] # Re: Portage Linux?

              Posté par  . Évalué à -1.

              Oups... j'ai ripper sur mon clavier (j'suis plus habitue au qwerty ca me trouble)

              > Quand a lisibilite des regles, c'est une histoire de gout... Moi je ne trouve les regles IPTables complexes a lire.
              Quand a la lisibilite des regles, c'est une histoire de gout... Moi je ne trouve pas les regles IPTables complexes a lire.

            • [^] # Re: Portage Linux?

              Posté par  (site web personnel) . Évalué à 5.

              "block in ..." est une règle, tandis que "iptables..." est une commande, ce n'est pas du tout la meme souplesse. Je préfère un bon fichier de config à un script plus ou moins branlant. Faudrait faire un sondage pour savoir ce que la majorité préfère...

              • [^] # Re: Portage Linux?

                Posté par  . Évalué à 4.

                Rien ne t'empeche de faire un script shell qui parse un fichier de conf et appelle iptables avec les options qui faut. Tu en as deja plusieurs qui existent (cf http://www.freshmeat.net(...)).

                En plus l'avantage d'une commande est qu'il est tres facile d'enlever ou de rajouter des regles en live.
                Par exemple chez moi root n'a pas le droit de faire sortir des paquets (iptables -A OUTPUT -m owner --uid-owner 0 -j DROP) mais quand je fais un apt-get je l'y autorise temporairement.

                Ou bien tu veux loguer temporairement certains paquets pour faire un test quelconque.

              • [^] # oui mais non...

                Posté par  . Évalué à 5.

                les fichiers de conf ont clairement des avantages, mais le fait qu'iptables (et son prédécesseur, ipchains, ce qui n'est pas étonnant, car c'est la même personne, Rusty Russel, qui est l'auteur des deux outils) soit sous forme de programme permet un plus grand dynamisme. Je m'explique : je créé une chaine "mechants" qui contient des règles pour bloquer les vilains qui foutent leurs doigts où il faut pas (finger, netbios-ssn, rpc et consors...). je peux facilement dans mon cron ou avec atd flusher cette chaine quand je le veux... Et pluis il est plus facile/pratique de lancer une commande depuis un script/programme que de modifier un fichier de conf puis de le faire relire par le programme adéquate... Ce n'est qu'un exemple simpliste, car les aplications sont nombreuses... Enfin c'est mon avis, et ca n'engage que moi.
                Je vais rechercher justement un mail ou Rusty Russel (le 'kernel_firewall_hacker' ou 'iptables/netfilter_hacker', au choix) expliques ce choix d'une commande et non d'un fichier de conf... C'est relativement interessant à lire...
                Dans le même esprit, ceux qui sont interessés par netfilter/iptables peuvent lire http://netfilter.samba.org/unreliable-guides/netfilter-hacking-HOWT(...) : "The Linux netfilter Hacking HOWTO"...
                Allez aussi jeter un oeuil sur
                http://netfilter.samba.org/unreliable-guides/(...) , c'est très interessant...

                • [^] # Re: oui mais non...

                  Posté par  . Évalué à 0.

                  Sous PF on peut aussi creer des groupes (cf le howto) de facon simple et aussi les modifier tout aussi simplement.
                  De plus lorsque tu fais des modifs c'est quand meme plus simple de lire un fichier dans un editeur que d'avoir a faire un 'ipchains -L -n | less' a chaque modification.
                  Et puis tu compares le fait de lancer une commande a celui d'editer un fichier, mais tu oublierais pas volontairement la consultation des chaines existantes avant de lancer la commande ?
                  Resultat je prefere largement un fichier de regles :)

                  • [^] # Re: oui mais non...

                    Posté par  . Évalué à 1.

                    attention, je n'ai pas dit que PF n'étais pas bien, et ne gère pas les groupes...
                    Quand à vérifier les règles avant de les modifier/ajouter dynamiquement, si tu te contente d'interdire une IP en haut de la chaine, il n'y a pas de problèmes...

                  • [^] # Re: oui mais non...

                    Posté par  . Évalué à 1.

                    Mais l'un n'empeche pas l'autre.
                    Libre a toi de faire un fichier avec tes regles dedans et un script shell ipt.sh:

                    #!/bin/sh
                    IPTABLES=/sbin/iptables

                    while read line
                    do
                    $IPTABLES $line
                    done

                    Et apres tu fais ipt.sh < ruleset

                    • [^] # Re: oui mais non...

                      Posté par  . Évalué à 1.

                      c'est un peut le système iptables-save & iptables-restore

                    • [^] # Re: oui mais non...

                      Posté par  . Évalué à 0.

                      Donc on est bien d'accord, il faut se faire chier sous linux pour faire quelque chose de simple :)
                      Merci pour la confirmation.

            • [^] # Re: Portage Linux?

              Posté par  . Évalué à -1.

              Au lieu de dire que PF est trop recent, teste le :)

              PF il booste trop ta mere !

          • [^] # Re: Portage Linux? (non, pitié pas ça ;-)

            Posté par  (site web personnel) . Évalué à 6.

            > La syntaxe d'Ipf est très largement plus compréhensible que celle d'IPTables

            Tu as oublié de préciser que cette assertion est vraie uniquement pour les gens qui changent leur sendmail.cf à la volée.

            Plus sérieusement, la syntaxe de ipf est somme toute honnête (pour écrire une règle de filtrage), mais il lui manque la souplesse de l'appel en ligne de commande d'iptable:

            • rajout de règles

            • insertion de règles

            • retrait de règles


            Ceci permet de faire des scripts iptable modulable et très efficace.

            • [^] # Re: Portage Linux? (non, pitié pas ça ;-)

              Posté par  (site web personnel) . Évalué à 5.

              Ah, mais je proteste, on peut très bien ajouter ou retirer des règles au vol, avec une ligne de commande, il suffit de savoir faire. ipf peut prendre ses règles sur l'entrée standard, donc echo+ipf et le tour est joué.

              Par contre, un truc que j'aime bien et que je ne sais pas si netfilter fait, c'est la possibilité d'avoir un jeu de règles actif et un passif. On insère les règles dans le second, on échange les deux pour tester et on remets le premier ensuite pour continuer le bidouillage.

          • [^] # Re: Portage Linux?

            Posté par  . Évalué à 0.

            Au dela de la syntaxe le gros avantage d'ipf et de pf sur les systèmes de filtrage sous Linux que je connais (ipfw et ipchains je ne connais pas iptable) est qu'il est possible de charger l'ensemble des règles en une seule commande.

            • [^] # Re: Portage Linux?

              Posté par  . Évalué à 1.

              Sous Linux aussi
              /etc/init.d/iptables {start,stop,restart}

              Suffit de faire un script shell, c'est bien compliquer

              • [^] # Re: Portage Linux?

                Posté par  . Évalué à 1.


                Sous Linux aussi
                /etc/init.d/iptables {start,stop,restart}

                Suffit de faire un script shell, c'est bien compliquer

                Je sais bien que l'on peut faire un script mais cela ne change rien.

                Dans le cas de pf/ipf la configuration s'effectuant avec une seule commande le firewall passe immédiatement de l'état avant configuration à l'état après configuration (pour couper les cheveux en 4 on peut aussi ajouter un état pendant).

                Avec iptables même si l'on utilise un script, il y aura des états intermédiaires après chaque ajout de règle. Pour être vraiment paranoïaque il faudrait dans la conception de son firewall prendre en compte les états intermédiaires pour s'assurer que quelque soit la situation la machine ne se retrouve pas dans un état bizarre ou que ces états intermédiaires ne peuvent pas être utilisés par des méchants.

            • [^] # Re: Portage Linux?

              Posté par  . Évalué à 2.

              avec netfilter, tu peux toujours utiliser le couple iptables-save/iptables-restore (existe aussi pour ipchains) qui permet de sauver tes règles actuelles dans un fichier pour les recharger après...
              exemple :
              'iptables-save > mes_reges_a_moi' pour sauver et 'iptables-restore < mes_reges_a_moi' pour restaurer... ca sauve toutes les règles, user-defined chains, defaults policies, et autres...

          • [^] # Re: Portage Linux?

            Posté par  . Évalué à 5.

            Il ne faut pas oublier que ce fameux 'bug' d'IPTables est du à un problème venant directement d'un protocole connu pour être mal concu et connu aussi pour être la plaie des firewalls et de leurs administrateurs... Je n'excuses pas ce bug/security_flaw, je dis juste qu'un bug concernant un protocole problématique dans la jeunesse d'un firewall ne doit pas t'ammener à rayer Netfilter de la liste des bons firewalls.
            Quand à savoir si ce qu'a dit Fabien sur Netfilter est vrai, c'est très compliqué, car très subjectif. Mais l'on peut parler de certains avantages de netfilter sur ses concurents directs :
            */ modularitée/flexibilitée qui permet d'étendre les fonctions/targets.
            */ système de chaines très pratique et très fonctionnel
            */ statefull
            */ permet de matcher les adresses mac
            */ système de matching par limites, pour éviter les DDOS par exemple (système inteligent : edge et limit-burst)
            */ matching par owner (propriétaire), cad la personne qui a créé le paquet...
            */ rajout de targets (notement LOG qui est très pratique pour la lisibilitée de ses fichiers de logs...)

            Attention, je n'ai pas dit qu'il était le seul à posséder ces attributs (ie de nombreux firewalls sont statefull de nos jours), juste qu'il a l'avantage de les réunir tous, et d'être facilement extenssible.

        • [^] # Re: Portage Linux?

          Posté par  . Évalué à 0.

          En quoi est-il plus puissant ???

      • [^] # Re: Portage Linux?

        Posté par  . Évalué à 3.

        S'il s'agit juste de la syntaxe des outils d'admin, il serait sans doute plus simple d'ecrire un programme convertissant les regles PF en regles Netfilter.

        Ce qui compte surtout dans un firewall, AMHA, c'est d'abord sa fiabilite et ensuite ses differentes possibilites (nat, statefull, fitre des portscan, detection des paquets malformes, ...). Quelqu'un sait-il quels sont les fonctionnalites permises par PF et pas par Netfilter et reciproquement?

    • [^] # Re: Portage Linux?

      Posté par  . Évalué à 4.

      Pourquoi pas ? Mais c'est loin d'être une tâche facile...

      En ce qui concerne OpenSSH, le travail était somme toute relativement simple : il s'agissait d'adapter petit à petit le code aux subtilités de chaque système, au besoint en fournissant des fonctions de remplacement (très peu de systèmes ne dérivant pas de 4.4BSD fournissent les fonctions err(), errx(), warn() et warnx() dans libc, pour prendre un exemple simple).

      Ce travail a été réalisé par un groupe de personnes indépendantes d'OpenBSD. Il a été reconnu et officialisé car il s'agit d'un travail de qualité.

      Refaire la même chose avec PF est bien entendu théoriquement possible, mais, outre le fait que PF évolue plutôt vite pour l'instant, il est volontairement très lié aux particularités d'OpenBSD. Il ne devrait pas être trop difficile d'en effectuer un portage sur un autre système BSD, car les piles tcp/ip sont proches (et même identiques pour la pile ipv6 qui est KAME). Par contre, pour un autre système, ce sera beaucoup plus délicat...

      • [^] # Re: Portage Linux?

        Posté par  . Évalué à 10.

        J'ai traduit la FAQ en français de PF (je l'ai transmise à son auteur) et ya deux trucs vachement bien dans PF qu'on découvre dans la FAQ.

        Le premier c'est que PF optimise la table de règles tout seul, suffit de mettre par interface, prototocole et tout et un truc qui s'appelle le "skip step" optimise.

        Le meilleur : le state modulation
        OpenBSD dispose d'un excellent niveau de production de nombres aléatoires, et donc comme les numéros de séquence de paquets en dépendant, ça permet d'obtenir une bonne distribution. Bref, il y a cette étude à consulter d'abord :

        http://razor.bindview.com/publish/papers/tcpseq.html(...)

        Ensuite, on peut demander au parfeu de remplacer les ISN des machines par celles de la machine parefeu sous OpenBSD. Ensuite la normalisation de paquets, un peu plus consommateur de ressources mais tout aussi intéressant.

        Imaginez : un OpenBSD sur une bonne machine, agissant comme routeur/parefeu et qui remplace les ISN par les siens, ça permet de disposer d'une bonne sécurité pour les machines dont les piles TCP/IP sont un peu moins bonnes :) Cool non ?

        Ya plein de bonnes idées et quelques unes pourraient trouver une appréciable place dans Linux, sans doute. Faut lire la FAQ de PF c'est pas long du tout (40 Ko) et tout est expliqué. Espérons que l'auteur placera la FAQ en français rapidement sinon je peux la donner à Penso pour qu'il la colle quelque part ici.

        J'adore voir naître des softs quand ils sont prometteurs comme ça.

        --
        Gilbert
        (gilbertf@posse-press.com)

      • [^] # Re: Portage Linux?

        Posté par  . Évalué à 6.

        Non, ce n'étais pas si simple que tu peux le pensser... Les auteurs d'OpenSSH (les auteurs, pas les porteurs) ont utilisés des propriétées propres à OpenBSD et à son noyeau en codant, entres autres au niveau de la génération de nombres aléatoires non prédictibles, mais aussi de la génération de digests et autres fingerprints (genre md5, ...). Et les porteurs se sont faits chier pour porter certains algos vers des systèmes qui n'avaient pas de tels générateurs... D'ailleurs dans certains cas, ils ont utilisés des algos plutots moyens...
        OpenSSH est donc vachement plus secure sous OpenBSD que la version portée, et oui monssieur (et je fait pas de troll à 3 francs, les gens ici qui me connaissent savent que je suis plutôt pro-Linux que l'inverse).

        • [^] # Re: Portage Linux?

          Posté par  . Évalué à 1.

          Regarde bien son nom avant de critiquer ce qu'il peut penser :)

        • [^] # Re: Portage Linux?

          Posté par  . Évalué à 0.

          C'est vrai, j'ai lu de la doc et ils expliquent qu'OpenSSH ailleurs que sous OpenBSD pourrait être un peu moins bon :P

          C'est dommage, car OpenSSH est vraiment un bon petit soft et qu'il faudrait consacrer autant de soin à le porter sous Linux qu'à le développer sous OpenBSD. Je suis sous OpenBSD mais bon j'ai mes camarades autour de moi sous Linux et OpenSSH pour se créer des tunnels c'est trop bon.

          Je pense m'acheter une carte Wireless et voir ce qu'on peut faire avec SSH dessus histoire d'avoir un petit réseau LAN à Posse (ils mélangent tellement les Windows ici qu'on accède à rien sans problèmes même avec Samba.. ! :-(

          Merci pour ta remarque ;->

          --
          Gilbert
          (gilbertf@posse-press.com)

  • # IPFilter > netfilter ?

    Posté par  . Évalué à 0.

    Arrétez de troller comme des porcs, ca ne fait pas avancer le schmilblick !

    Le fait est que netfilter est encore beaucoup trop jeune par rapport à ipfilter. Il n'y a qu'a voir les commentaires dans les sources de netfilter :

    fichier : net/ipv4/netfilter/ip_conntrack_proto_tcp.c

    /* FIXME: Examine ipfilter's timeouts and conntrack transitions more closely. They're more complex. --RR */

    Je ne dit pas que netfilter c'est pas bien mais juste que AMHA un firewall en milieu critique devrait utiliser OpenBSD avec ipfilter. Pour un firewall chez vous netfilter est très bien.

    (merci Amon pour l'info ... m**** je suis demasqué maintenant :)

Suivre le flux des commentaires

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