Bidouiller dans le /proc pour sécuriser son Linux

Posté par  . Modéré par Fabien Penso.
Étiquettes :
0
10
avr.
2002
Sécurité
LinuxGazette propose un article assez clair sur quelques-unes des options du /proc, en particulier, celles relatives à la configuration de la couche TCP/IP du noyau Linux. Vous saurez alors quel est l'effet du fameux 'echo "1" > /proc/sys/net/ipv4/conf/all/rp_filter'
rencontré dans certains scripts de config firewall.

Malheureusement, l'article ne survole que quelques-unes des possibilités, certes, les plus utiles, comme la non prise en compte des messages ICMP, ou la protection contre les attaques tcp_syncookies.

D'autres articles permettent de mieux couvrir certains domaines de cette partie (souvent ignorée) de la configuration du noyau Linux.

Aller plus loin

  • # sysctl

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

    interessant comme article.

    Ne pas oublier cependant la commande sysctl qui permet aussi de faire un peu de tuning au niveau noyau.

    encore une url a garder sous le coude...

    • [^] # Re: sysctl

      Posté par  . Évalué à 10.

      Euh ... la MIB système accessible par sysctl n'est pas mappée dans /proc ?
      Ce serait un peu idiot d'avoir ce genre de données réparties entre deux systèmes différents, non ?

      sysctl permet d'y accéder si /proc n'est pas monté, je suppose. De plus sysctl est la commande classique pour ce genre de trucs sur pas mal d'Unix.

      • [^] # Re: sysctl

        Posté par  . Évalué à 10.

        sysctl permet d'y accéder si /proc n'est pas monté, je suppose.

        meme pas, cf la page man de sysctl.

        sysctl evite juste de faire "echo 1 > /proc/.."
        mais il fait la meme chose avec sa syntaxe a lui.

        l'interet c'est /etc/sysctl.conf qui garde la config entre les reboot.

    • [^] # Re: sysctl

      Posté par  . Évalué à 10.

      sysctl et /proc c'est blanc bonnet et bonnet blanc ...

      sysctl n'est autre qu'un interface pour manipuler les parametres de /proc .

    • [^] # Re: sysctl : doc complète

      Posté par  . Évalué à 3.

      Pour sysctl, la doc du kernel est ici : http://www.linuxhq.com/kernel/v2.4/doc/networking/ip-sysctl.txt.htm(...)

      Tous les parametres présents dans /proc/sys/net/ipv4/ y sont expliqués.

      Mais je persiste à dire que l'utilisation du /proc est plus simple (pas de programme supplémentaire...)

  • # "tuning" deb

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

    Avant de commencer à "tuner" la machine, penser à économiser en processus de type demons/services.
    Un bonne intro sur MadrakeUser :
    http://www.mandrakeuser.org/docs/admin/print/service.html(...)

  • # option avancé

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

    a en croire ce qu'on fait avec freebsd, il y a quand meme des options plus avancés sous bsd avec sysctl...

    Notamment, un truc comme géré le nombre de process qui s affiche lors d un ps (restreint au pid de l'utilisateur), c est toujours bon !

    est ce que quelqu un sous linux a une méthode ?

    @+
    Code34

    • [^] # Re: option avancé

      Posté par  . Évalué à 10.

      Oui, mais il faut patcher ton kernel, avec openwall par exemple. C'est bien mais certaines options rendent plein d'applications inutilisables...

      • [^] # Re: option avancé

        Posté par  . Évalué à -1.

        Pour ce qui est de la pile non executable, il y a un nouvel attibut de fichier permettant de rendre la pile executable il me semble. Ce qui permet à beaucoup de programmes de fonctionner quand même, même si ses contraintes au niveau sécurités sont moindres...

  • # /proc le link pour l ipv4

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

    j avais pas regardé les liens dans le topic [..]
    clair c succint comme article ;)

    je vous file l url pour parametrer votre pile ipv4 sur un kernel 2.4

    http://www.linuxhq.com/kernel/v2.4/doc/networking/ip-sysctl.txt.htm(...)

    @+
    Code34

Suivre le flux des commentaires

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