Firewall toujours en fonction sur un Linux arrêté!

Posté par  . Modéré par Fabien Penso.
Étiquettes :
0
11
fév.
2002
Sécurité
Voici un super article sur le site de l'excellent magazine "Samag" des SysAdmins qui présente une approche unique pour améliorer la sécurité de réseaux.

"Exécutez votre firewall dans un état d'exécution stoppé sur votre linux, c'est à dire en runlevel 0 : aucune exécution de processus et aucun disque monté, mais le filtrage de paquets IP est toujours en fonction!"

Cela protège des tentatives d'introduction de vers sur le firewall, puisque le hacker n'a plus d'espace disque pour poser ses
programmes de surveillance et d'intrusion. Mais cela ne protège évidemment pas des attaques de type "denial of service".

L'auteur a entendu une rumeur de cette capacité d'exécution arrétée sur les noyaux Linux 2.0, il est parvenu à obtenir ce fonctionnement aussi bien sur une 2.2. Reste à tester sur un noyau 2.4...

NB : Merci à Alain pour la news

Aller plus loin

  • # Attention au changement de règles

    Posté par  . Évalué à 10.

    Ce système possède quand même un inconvénient notable, c'est que l'on est obligé de redémarrer la machine pour modifier les règles du firewall, ce qui peut être extrèmement génant.

    • [^] # Re: Attention au changement de règles

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

      J'allais le dire. Si justement un plaisantin s'amuse a faire joujou avec la machine (DoS en fait), pas moyen de le bloquer sans rebooter.

      • [^] # Re: Attention au changement de règles

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

        Malheureusement, le bloquer ne liberera pas la bande passante qu'il occupe !
        Tous ce que tu bloquera pas ce sont les DOS du a des bug kernel.

        Mais en fait rien n'interdit de faire un module du kernel qui detecte les DOS, SCAN ou autre et qui met les regle ipchain de lui meme !

        • [^] # Re: Attention au changement de règles

          Posté par  . Évalué à 3.

          a la condition que les regles soient bien stoquees en 'kernelland' et pas en 'userland'
          mais je crois que c'est le cas

        • [^] # Re: Attention au changement de règles

          Posté par  . Évalué à 10.

          Mais en fait rien n'interdit de faire un module du kernel qui detecte les DOS, SCAN ou autre et qui met les regle ipchain de lui meme !

          ... ce module etant probablemement composé d'environ 500 lignes de code C soit approximativement 50 bugs possible , soit environ 50 failles de securité possibles ...
          Bref .. tu vient de bouger le probleme de securité du userspace au kernelspace ...

          • [^] # Re: Attention au changement de règles

            Posté par  . Évalué à 3.

            environ 500 lignes de code C soit approximativement 50 bugs possible

            Quelle vision pessimiste des choses ! Sur un programme de 500 lignes il est facile d'éviter les bugs quand même, en tous cas pas 50 !
            Quand à la question des failles de sécurités, on peut les éviter si on respecte une règle de base qui est de ne jamais faire confiance à ce qui arrive, vérifier les valeurs, utiliser strncpy au lien de strcpy, etc...
            J'avais vu un article qui expliquait comment Daniel Bernstein (celui de qmail et djbdns) utilisait une lib particulière pour le traitement des chaines de caractères, et qu'il y avait un prix pour si on découvrait une faille dans son code. On n'en a pas encore trouvé...
            Peu de gens programment bien, mais c'est possible de ne quasiment pas faire de bug.

    • [^] # RE: Attention au changement de règles

      Posté par  . Évalué à 10.

      Dans le meme registre, on n'a pas de log. Se qui rend les choses difficiles sur une attaque de type DOS.

      Pas tres interessant. Mais rigolo a connaitre.

      • [^] # Re: RE: Attention au changement de règles

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

        Dans tous les cas, un syslog peut tout à fait "forwarder" ses logs vers une machine distante...

      • [^] # Re: RE: Attention au changement de règles

        Posté par  . Évalué à -3.

        ok, mais avec les procs actuel, les DoS, ca doit plus faire grand chose, et pour un ptit serveur sans admin, ca doit suffir,et puis, ca reste tjrs très très fun.
        Shad
        -----
        tuxpuck roulez

        • [^] # Re: RE: Attention au changement de règles

          Posté par  . Évalué à 10.

          Quand on parle de DoS, on ne parle pas nécéssairement de saturation du processeur ! Une pile IP, ça peut s'exploser,
          la table contenant la liste des sessions TCP ouvertes est de taille limitée (donc saturable, donc DoS), etc...
          Donc si, les DoS ca existe toujours, malgré les performances processeur !

      • [^] # Re: RE: Attention au changement de règles

        Posté par  . Évalué à 7.

        Tu rediriges tes logs sur une bonne vieille imprimante matricielle... vu que le driver pour le port // est en kernelland ca marchera. Et je mets au defi qqn d'effacer ces logs la.

        • [^] # Re: RE: Attention au changement de règles

          Posté par  . Évalué à 5.

          Rah oui !! mais va falloir isoler le tout, alors, parce qu'il y a pas de copie... et donc on oublie pas d'avoir une salle bien fermée. En plus, il faut se protéger du bruit...

          Et pis le problème, c'est qu'une imprimante, ça va pas vite. Alors, si il y a trop de log, gare au buffer plein !

          Donc, le dos passera inaperçu quand même. Nan, mieux vaut une console connectée via le port série. Comme il n'y a rien en userland, on peut pas pirater la console, tant qu'il n'y a pas de bug au niveau du kernel. Et rien n'interdit la console d'être munie d'un support de sauvegarde.

          • [^] # Re: RE: Attention au changement de règles

            Posté par  . Évalué à 5.

            tankaf, la console sur port série peut être un autre ordinateur, ça évite de compliquer ...
            how about faire tourner :
            tail -f /dev/ttyS2 |ma_moulinette_qui_parse_les logs
            sur cette machine-là ?

          • [^] # Re: RE: Attention au changement de règles

            Posté par  . Évalué à 2.

            >Et pis le problème, c'est qu'une imprimante, ça va pas vite. Alors, si il y a trop de log, gare au buffer plein !

            Apres faut jouer avec le -m limit d'iptables par exemple... Inutile de faire un log de tous les paquets, tu log disons les 30 premiers et ensuite tu craches un reminder toutes les minutes sur l'imprimante.

          • [^] # Re: RE: Attention au changement de règles

            Posté par  . Évalué à 4.

            Et pis le problème, c'est qu'une imprimante, ça va pas vite. Alors, si il y a trop de log, gare au buffer plein !

            "Ca imprime pas..."
            - "Ca imprime pas?"
            - "Ben non, ça imprime pas..."
            - "C'est encore Henry."
            - "Henry?"
            - "Oui. Il a mit un buffer overflow dans l'imprimante..."

            désolé --->[*aïe*

    • [^] # script runlevel 0

      Posté par  . Évalué à 10.

      Une petite question : au démarrage le noyau lance init qui à partir du initab lance les scripts rc.X.

      Donc si je crée un niveau init qui ne lance aucun process (même pas de getty), juste exécute les commandes pour initialiser les règles du fw, j'obtient le même résultat.

      Le runlevel de départ dépends de lilo non. Donc, dans ce cas, je peux laisser le choix au menu de démarrage de booter dans le runlevel "Firewall only" ou dans le runlevel multiutilisateur complet pour l'administration facile de la bécane.

      Je suppose que c'est comme ça que doit marcher les fw embarqués dans une boite tournant sous Linux.

      • [^] # Re: script runlevel 0

        Posté par  . Évalué à 10.

        Bah non, puisque tu as un process de lancé : init.

        Dans cette état machine arreté, même init n'est plus lancé.

        • [^] # Re: script runlevel 0

          Posté par  . Évalué à 9.

          init n'est plus lancé, je dirais plutôt qu'il s'est arrêté.

          En fait, le noyau lance le programme /sbin/init ou /etc/init ou /bin/init ou /bin/sh en dernier recours (voir /usr/src/linux/init/main.c:init()

          Il suffit donc dans ce cas de faire un script /sbin/init contenant toute la config TCP/IP, la config des règles de filtrage, puis de laisser ce script se terminer bien sagement, sans faire de halt -f ou reboot -f. Et ça devrait bien marcher.

          • [^] # Re: script runlevel 0

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

            disons plutôt de faire un script /sbin/faïreoual et de l'appeler via "lilo linux init=/sbin/faïreoual", histoire de garder un init fonctionnel sous le coude.
            (le script doit se trouver sur la partition racine)

            • [^] # raté, enfin presque.

              Posté par  . Évalué à 2.

              Pour lancer /sbin/faïreouale, tu lis dans /, donc, il est monté, gaffe à ce qu'il le reste pas, à moins que tu le démontes une fois le script en mémoire.

              • [^] # Re: raté, enfin presque.

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

                à ce stade, la racine est seulement montée en lecture seule. Donc tu peux tout arrêter violemment sans que ça gêne (lilo linux init=/bin/bash pour s'en convaincre (pratique pour dépanner un Linux en carafe))

                • [^] # Re: raté, enfin presque.

                  Posté par  . Évalué à 1.

                  Puis un petit mount /dev/hdxx / -o remount,rw et hop, à nous le disque.
                  Un simple mount /dev/hdxx / -o remount,ro permet ensuite d'arrêter violemment.

                • [^] # Re: raté, enfin presque.

                  Posté par  . Évalué à 1.

                  C'est pas la peine de chercher, il y a aucun process (en user space) qui tourne donc on peut au pire exploiter un buffer overflow (ou n'importe quelle autre type de faille du même genre) dans le noyau lui-même et donc exécuter un "shellcode" (qui ne lance pas de shell d'où les guillemets) dans le kernel mais surement pas ailleurs.

                  D'ailleurs, le-dis shellcode n'aurait pas accès à la librairie C, ni aucun appel système (a priori un appel système c'est une interruption, pour basculer en mode noyau, et là on y est déja en mode noyau).
                  Par contre, il tournerait en ring level 0 (pour ceux qui ont lu les doc ASM 386), donc aurait le droit de TOUT faire, même causer avec les périphériques, bref il aurait plus de droit qu'un programme tournant sous ROOT.
                  Il serait possible d'utiliser comme librairie les routines du noyau(les fonctions qui miment la libc genre printk, kmalloc...) à condition de connaître leurs addresse mémoire, donc en gros de savoir exactement quel binaire de noyau est utilisé ce qui est possible sur les distribs standards.

                  En théorie, quelqu'un devrait pouvoir écrire un "shellcode" qui ouvre une pseudo backdoor réseau dans la pile TCP/IP mais bon ça serait pas mal de travail je suppose, et encore faut-il trouver une faille dans le noyau ...

  • # OS de base

    Posté par  . Évalué à 6.

    En fait ca revient a avoir un OS qui ne fait tourner qu'un firewall.

    Developper un firewall pour MS-DOS pourrait revenir au meme, non ?

    Cependant ca reste interessant, puisque le firewall existe deja sous linux...

    • [^] # Re: OS de base

      Posté par  . Évalué à 10.

      La question est : es-ce encore un OS. Il n'y a quasiment plus de gestion de la machine, plus de userland, plus d'interaction.

      On est dans le domaine de l'info embarquée là. On peut coller cette image de noyau dans une EPROM, et on a un micro firewall.

      Faudrait que j'essaye ce truc moi :)

    • [^] # Re: OS de base

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

      Euuh je croit que MS-DOS n'est pas multi-tache alors je voit mal comment mon firewall va faire avec deux packet qui arrivent en meme temps ...

      • [^] # Re: OS de base

        Posté par  . Évalué à 10.

        La notion de tache n'existe pas non plus à l'intérieur du noyau linux. Met un while (1) dans le noyau (dans un driver par exemple), et tout se blo

        • [^] # Re: OS de base

          Posté par  . Évalué à 10.

          La notion de tache n'existe pas non plus à l'intérieur du noyau linux.
          Qu'est-ce pour toi qu'une tâche ?

          Un processus, dans ce cas il est normal que le noyau ne soit pas un processus à part entière car son rôle est justement de gérer les processus (donc qui le gérerait lui si c'en était un).

          Il y a aussi des processus qui résident dans l'espace d'adressage du noyau (au lieu de l'espace d'addressage utilisateur), on appelle ça des threads kernel, je crois que les démons commençant par un k (comme kswapd) sont comme ça.

          Le noyau est réentrant, donc si à un instant donné, plusieurs processus appellent une routine du noyau alors, il y a plusieurs exécutions concurrentes au sein du noyau.

          Celà ne peut arriver que sur une machine SMP puisque sur une machine monoprocesseur un seul processus tourne à chaque instant, simplement à expiration de la tranche de temps (10 ms par exemple), l'ordonanceur commute d'un processus à un autre donnant une impression d'exécution simultanée à l'échelle humaine.

          Le noyau linux standard est non préemptible, ce qui veut dire qu'une boucle "while(1)" dans le noyau ne sera pas interrompue si sa tranche de temps est écoulée par contre elle peut-être interrompue par une interruption matérielle.

          Les problèmes de concurrence sur une machine non-SMP, ne peuvent donc survenir qu'entre une routine traitant une interruption matérielle, et une routine "standard" du noyau.

          Une routine traitant une interruption ne peut elle-même être interrompue par une autre interruption (car les processeurs Intel masquent automatiquement toutes les interruptions lors du traitement de l'une d'entre-elles).

          Or les routines d'interruptions sont généralement très courte, lorsqu'elles doivent faire quelque chose de compliqué, elles enregistrent un callback qui sera appelé plus tard.

          De plus si une routine standard doit modifier une structure de donnée qui est affectée par un handler d'interruption (rare puisque les handler sont très très court), elle peut bloquer les interruptions temporairement avec un CLI().

          Donc, les problèmes de concurrence au niveau du noyau sur une machine non-SMP sont minimes, par contre ce système de callback implique que le noyau soit non-préemptible car lorsque la tranche de temps arrive à expiration, il se déclenche une IRQ timer, dont le handler qui doit rester très court, ne peut lancer directement un autre processus, non il ne peut qu'enregistrer un callback dans une file d'attente pour rappeler qu'il faut appeller le scheduler.

          Or ce callback ne sera exécuté que lorsque quelqu'un ira regarder le contenu de cette fichu file d'attente, une solution serait donc d'aller regarder de temps en temps si elle contient quelque chose. C'est la technique dite des points de préemptions, qui consiste à insérer un peu partout dans le kernel à des points clés des bout de code pour faire cela.

          Une solution serait de dire que toute cette histoire de callback enregistré maintenant, pour être appelé plus tard, c'était pour que les routines du kernel puisse garder continuer de se reposer sur l'assertion "les handler d'interruptions ne modifient pas grand chose donc pas beaucoup (quasiment pas) de problème de concurrence à gérer et quand il y en a (très rarement) on fait un CLI()".

          Or de toute façon, les problèmes de concurrence on est bien obligé de se les taper en mode SMP, et donc les routines de verouillage qui protégent les structure du noyau elles existent mais dans la version SMP.

          Une idée serait donc, je compile mon noyau monoprocesseur en mode SMP et j'appelle la routine de callback tout de suite, juste après avoir réactivé les interruptions dans le handler et avant de faire le return, et j'ai un kernel préemptible.
          Je crois que c'est plus ou moins ça que fait le patch kernel préemptible.

          Donc quand tu dis qu'un while(1) dans le noyau bloque tout, je dirais :
          - sur une machine monoprocesseur avec un kernel standard (SMP ou pas) ou avec des points de préemption : ça bloque la machine
          - en mode SMP sur une machine multiprocesseur, ça bloque un processeur mais les autres tournent normalement
          - avec le patch kernel préemptible, ça fait rien de plus qu'un "while(1)" dans la libc, le processus concerné est bloqué pour toujours et ne pourra plus recevoir de signaux mais tout le reste continue de tourner normalement.

          • [^] # merci, j'ai compris (non contributif, -1)

            Posté par  . Évalué à 0.

            Clap clap clap j'ai compris, donc, je remercie de la contribution.
            SMP rocks, je le sentais, désormais, je le sais, mais je promet de jouer avec le patch preemptible sur mon firewal, histoire de voir si qui peux le plus, peu le moins (plain old PPro 200 des familles)

            --
            -1 car non contributif

      • [^] # Re: OS de base

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

        Moi, je vois mal ma carte reseau recevoir deux paquets en meme temps !! Par contre, elle peut a la rigueur en envoyer et en recevoir en meme temps.

        Enfin, n'oublions pas les buffers.

        • [^] # Re: OS de base

          Posté par  . Évalué à -8.

          Par contre, elle peut a la rigueur en envoyer et en recevoir en meme temps.

          Sur de l'ethernet (CSMA/CD) ça s'appelle une collision, et ça rend le paquet invalide et à réemmettre. Donc je pense pas que les cartes le fassent.

          • [^] # Re: OS de base

            Posté par  . Évalué à 6.

            Sur de l'ethernet (CSMA/CD) ça s'appelle une collision, et ça rend le paquet invalide et à réemmettre. Donc je pense pas que les cartes le fassent.

            Si si, çà s'appelle le full duplex !!!

          • [^] # BaseT

            Posté par  . Évalué à 9.

            et le full-duplex c'est quoi ? c'est quand on utilise une paire pour Rx et une autre pour Tx.
            donc je pense (enfin moi j'en suis sur :p) que certaines cartes le font.

            • [^] # Re: BaseT

              Posté par  . Évalué à -3.

              Ah, ok, j'avait pas pensé à la séparation RX/TX, j'en suis resté au BNC.

              [jesors]

          • [^] # Re: OS de base

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

            Sur coaxial mais pas sur paire torsadée ! ( mode full duplex)

            Ne mixont pas tout !

            "La première sécurité est la liberté"

      • [^] # Re: OS de base

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

        Mais là on s'en fout, la carte réseau envoie des interruptions, donc pas besoin d'être multi-tâche, c'est juste une gestion d'interruptions et le Dos sait trés bien le faire (timer, clavier hd, son, etc...).
        D'ailleurs la base du multi-tâche, c'est essentiellement mettre un "scheduleur" (ordonanceur de tâche) sur l'interruption horloge de plus haute priorité (irq 0) appellé tous les X millisecondes (et puis après faire pleins de trucs derrière, mais c'est le principe).
        Sans interruption périodique, je ne connais pas et je ne vois pas de moyen de faire du multi-tâche efficace sur une archi classique (mais si vous connaissez je veux bien savoir).

        • [^] # Il ne faut pas confondre...

          Posté par  . Évalué à 1.

          Sans interruption périodique, je ne vois pas de moyen de faire du multi-tâche efficace

          s/efficace/préemptif/

  • # Ça vaut pas un bon bridge filtrant

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

    Il vaut mieux monter un bon vieux bridge filtrant, qui n'a pas d'IP, mais tous les services de log, car la sécurité ce n'est pas uniquement de bloquer les intrusions, mais aussi de pouvoir connaitre les tentatives.

    De plus un bridge peut être transparent (indétectable), ce qui n'est pas le cas du firewall linux sans process.

    • [^] # Re: Ça vaut pas un bon bridge filtrant

      Posté par  . Évalué à 2.

      <mode newbie>
      Comment on monte ce genre de choses sous Linux ? J'avais entendu parler de ça sous OpenBSD, mais pas sous Linux. Est-ce possible ? Une petite URL à se mettre sous le clic ?
      </mode>

      • [^] # Re: Ça vaut pas un bon bridge filtrant

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

        Comme dirait mon T-Shirt,

        RTFM :-)

        En effet, il y a un Linux Bridge+Firewall Mini-HOWTO...

        http://www.google.com/search?hl=fr&ie=utf-8&oe=utf-8&q=(...)

        • [^] # Re: Ça vaut pas un bon bridge filtrant

          Posté par  . Évalué à 3.

          Bon j'ai lu "ton" machin bridge+firewall et j'avoue que cela me laisse perplexe.

          dans son Howto le mec monte un linux en bridge. ok
          puis il ajoute des IP et du routage (? bizarre pour un bridge !!).
          enfin il le configure en proxy-arp (???)

          bref a la fin cela marche. ok. mais c'est un curieux mélange de genres. Il s'est surement marré en faisant cela, mais je ne vois pas d'application pratique.
          un bridge filtrant si il n'a pas d'IP je comprends, mais son setup ne fonctionne pas sans IP. Du coup c'est un firewall - proxy ARP.

          Bon j'ai peu etre pas capté l'astuce. Si tu veux bien éclairer ma lanterne ...

          PS: cela dit, c'est pas plus tordu que le coup du firewall arreté.

Suivre le flux des commentaires

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