Module d'audit SNARE

Posté par  (site web personnel) . Modéré par dumonteil jerome.
Étiquettes : aucune
0
10
nov.
2001
Sécurité
La société Intersect Alliance (spécialisée dans la sécurité) vient de rendre disponible les sources et les binaires du module noyau SNARE (System iNtrusion Analysis and Reporting Evironment).

Ce module dynamique du noyau permet d'obtenir un niveau de sécurité C2 pour notre OS préféré, en ajoutant des capacités d'audit et de détection d'intrusion au niveau 'host' (et non réseau comme des projets tel que Snort).

SNARE se compose d'un module noyau à installer ou à recompiler (snare-core) et d'une interface graphique (snare-gui) pour définir le paramétrage de l'audit et avoir un journal d'événements (voir screenshots très ressemblant au journal événement de NT).

Aller plus loin

  • # les modules et la securite

    Posté par  . Évalué à 10.

    franchement c'est pas un peu dangereux d'ajouter le support des modules dans le noyau etant donne tous les pbs dus aux rootkits qui justement utilisent le detournement des appels systemes par l'insertion de modules ?

    je sais qu'il existe St Michael pour surveiller ca mais quand meme je me pose des questions

    il s'agit donc de reduire son niveau de securite d'un cote pour l'augmenter de l'autre

    au final, de quel cote penche la balance ?
    • [^] # Re: les modules et la securite

      Posté par  . Évalué à 10.

      A partir du moment où tu actives le support des modules dans le noyau, le risque d'un kernel-rootkit existe. Si tu veux éviter, la solution c'est un noyau monolithique, ce qui n'est pas forcément une bonne chose... et surtout qui est beaucoup plus compliqué à administrer.

      Par exemple, si ton noyau est monolithique, tu ne peux rajouter de nouveaux modules pour Netfilter (un protocol helper, le module port-scan detection, ...) sans recompiler le noyau et rebooter la machine. Ca peut être très génant.
      • [^] # On peut charger des modules avec un noyau monolithique !

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

        Je dis HALTE : ce n'est pas parce que tu as compilé ton noyau sans le support des modules qu'il n'est pas possible d'insérer un module ou du code en mémoire !

        Le support des modules donne accès à des utilitaires qui te permettent de charger/décharger des modules. Maintenant, si tu parviens à mettre du code dans la mémoire "kernel", les instructions seront exécutées quand même. Pour cela, il "suffit" d'attaquer le fichier /dev/kmem.

        L'article qui explique ceci : http://www.big.net.au/~silvio/runtime-kernel-kmem-patching.txt(...)

        Il date un peu, mais l'idée est encore très intéressante :)
        • [^] # Re: On peut charger des modules avec un noyau monolithique !

          Posté par  . Évalué à 10.

          juste pour clarifier les choses

          supposons que mon kernel (un 2.4 vanilla) soit compile sans le support des modules, qu'un intrus ait reussi a s'introduire chez moi et qu'il ait tous les droits. d'apres l'article precedent, il pourrait donc charge du code en memoire
          je suppose alors qu'il pourrait alors aussi detourner tous les appels systemes et tout ca sans passer par la fonction init_module

          merci de me corriger si j'ai encore ecrit une connerie plus grosse que moi
          • [^] # Re: On peut charger des modules avec un noyau monolithique !

            Posté par  . Évalué à 10.

            Tu ne te trompes pas, c'est parfaitement possible... /dev/kmem permet d'accéder à la zone mémoire contenant le noyeau chargé, et donc de jouer avec ca... tu peux le modifier, et tout et tout... De mémoire, il y a même un programme qui te permet de jouer avec, et ce, avec plein d'options... Mais je le retrouves plus :'(
            • [^] # Re: On peut charger des modules avec un noyau monolithique !

              Posté par  . Évalué à 7.

              je dis ptet une connerie mais, pour toucher au noyau ou/via la mémoire, faut être root... or si un "méchant" devient root sur une machine c'est qu'il y'a une faille de sécurité avant...
              Une fois root c'est sûr qu'après il fait ce qu'il veut...
              #dd bs=2048 if=/dev/zero of=/proc/kcore ... je vous le conseille...
              • [^] # Re: On peut charger des modules avec un noyau monolithique !

                Posté par  . Évalué à 10.

                Le problème dont on parle dans ce thread, c'est les root-kits à base de modules noyaux. On se situe donc après qu'un pirate aie trouvé et exploité une faille. Le pirate possède donc un shell root, et veut:
                1/ Faire en sorte que son intrusion ne soit pas détecter
                2/ Se ménager une porte d'entrée facile, mais non détectable, et ceci même si le trou initial est patché.

                Pour cela, il existe des "root-kits" qui remplacent certaines commandes (ls, md5sum, ...) pour que les fichiers modifiés apparaissent comme sains. Le fin du fin dans les rootkits est de faire un module noyau, totalement indétectable, qui "ment" aux applications pour que le système paraisse sain.

                L'absence de support pour les modules dans le noyau rend ce travail plus difficile, mais pas impossinle comme l'a signalé Pappy plus haut.
      • [^] # portscan detection

        Posté par  . Évalué à 10.

        ah tiens tu aurais des exemples d'utilisation du module portscan detection ? deja comment l'activer ? il faut compiler le module du kernel, et puis iptables aussi ?
        • [^] # Re: portscan detection

          Posté par  . Évalué à 10.

          Il y a un module pour le kernel et un pour iptables, le tout se trouve parmis la collection 'patch-o-matic' dans les sources d'iptables (make patch-o-matic)

          La doc se trouve, toujours dans le package source d'ipables, dans le fichier patch-o-matic/psd.patch.help.

          La syntaxe c'est
          iptables -m psd [options] -j DROP
  • # Ca compile pas...

    Posté par  . Évalué à -7.

    Ca compile pas :(

    newton:/usr/src/snare/snare-core-0.8# make
    gcc -c -g -O6 -DMODVERSIONS -Iinclude -DMODULE -D__KERNEL__ -DLINUX auditmodule.c
    auditmodule.c:64: `spin_lock' redeclared as different kind of symbol
    /usr/include/asm/spinlock.h:79: previous declaration of `spin_lock'
    auditmodule.c: In function `auditmodule_read':
    auditmodule.c:453: called object is not a function
    auditmodule.c: In function `auditmodule_close':
    auditmodule.c:603: called object is not a function
    auditmodule.c: In function `audit_event':
    auditmodule.c:1286: called object is not a function
    auditmodule.c: In function `write_event':
    auditmodule.c:1390: called object is not a function
    auditmodule.c:1396: called object is not a function
    auditmodule.c:1445: called object is not a function
    auditmodule.c:1455: called object is not a function
    auditmodule.c: In function `timeout':
    auditmodule.c:1504: called object is not a function
    make: *** [auditmodule] Error 1
    • [^] # Re: Ca compile pas...

      Posté par  . Évalué à -7.

      mais au lieu de scorer négativement, dites plutôt si ça compile ou si ça compile pas chez vous.. Quelle mentalité sur linuxfr !
      • [^] # Re: Ca compile pas...

        Posté par  . Évalué à -10.

        Normal, c'est des parigos! Parigos tête de veaux!!!
      • [^] # Re: Ca compile pas...

        Posté par  . Évalué à -7.


        mais au lieu de scorer négativement, dites plutôt si ça compile ou si ça compile pas chez vous..


        Ca compile pas...
      • [^] # Re: Ca compile pas...

        Posté par  . Évalué à -2.

        dites plutôt si ça compile ou si ça compile pas chez vous..

        plutôt si ça compile ou si ça compile pas chez vous..

        Avec de l'habitude, on s'apercoit que si on est
        incapable de compiler ce genre d'outil, c'est qu'on
        n'est pas suffisamment "hacker" et encore trop "cracker"
        (encore des trucs à lire, faire etc...)
        Par contre, si on y arrive finalement en cherchant, on y gagne
        beaucoup!

        C'est ainsi que se fait la selection
        des outils "kifontdumal" d'une part largement
        répandus et d'autre part tres bon...

        Apres quelques modifications ça compile:
        la structure redéfinie, je l'ai vu une bonne
        douzaine de fois...

        Ca marche a tout les coups avec les script-kiddies
        pressé de péter le serveur de leur école.

        ps: inutile de me demander les modifs à apporter
        pps: je sais que ca va en enerver un paquet,
        alors je poste en anonyme...
    • [^] # Re: Ca compile pas...

      Posté par  . Évalué à -1.

      exactement pareil (à pars l'invite de shell mais c'est normal)
  • # pas C2

    Posté par  . Évalué à 10.

    ce n'est pas installer un module qui "permet d'obtenir un niveau de sécurité C2", ils disent sur le site "C2-style auditing/event logging capability"

Suivre le flux des commentaires

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