Journal Linux sécurisé, GRsecurity, RSBAC, PaX, SSP, libsafe, SElinux,...

Posté par  .
Étiquettes :
0
10
août
2005
Ce journal s'agit en fait d'une sorte de sondage, ou plutôt d'une demande de retour d'expériences.

Je cherche activement à sécuriser mon petit linux des méchants
buffersoverflow et autres joyeusetés... pour une machine x86 en utilisation serveur (PII-266 48moRAM 3goDISK par exemple, mais ne vous heurtez pas à la config, ca pourrai etre un athlon2000+).

dessus ca serai pour utiliser des demons du styles: iptables,dhcpd,ftpd,httpd,sshd

Je cherche à savoir qu'est ce que utilisent les admins qui ont un grand besoin de securite et qui utilisent ce genre de serveur dans un cadre de production, ainsi que des conseils/pensés pour les differents modules de securité. J'aimerai avoir le plus d'avis possible alors ne vous genez pas pour donner votre opinion, quelqu'il soit...


de mon cote j'ai deja trouve des petites choses:

les distribs: adamantix(debian),hardened(gentoo), NSA/SElinux(Fedora),
IPcop(~debian), OpenBSD(ca m'emmerderai pcq j'y connais rien, j'ai quand meme lu la moitie de la doc, faut se changer plein d'habitudeS, bref j'ai pas trop envie..., surtout que la sécurite c'est surtout la maitrise du systeme que l'on utilise)

mes ratés:

bien habitué aux debians j'ai saute sur adamantix, et je me suis fait mal...
la adamantix-v1.1.0-pre1.iso ne boot pas, et j'ai éprouvé quelques soucis avec la adamantix-v1.0.4-4.iso: des logs de shorewall dans la tronche toutes les 30sec, apt qui merdait de tous les cotés (je m'y suis pas mis longtemps vu que apt etait inutilisable et que j'ai decouvert que d'autre gens avaient deja eu beaucoup de galereS avec)

les patchs noyaux et userspace:

GRsecurity, RSBAC, PaX, SSP, PIE, libsafe, SElinux

Quelque noyau utiliser ? les 2.4 ou les 2.6 ? quel est le meilleur rapport performance/sécurité, vaut-il mieu utiliser un noyau patché par une distrib (debian grsec) ou le faire sois meme.
J'ai deja eu quelques problemes de stabilite sur une gentoo (c'est pas un troll) , gentoo hardened serait-il pres pour la production ?
Ce qui me gene c'est de compiler moi meme les packets mais ca serai pas mal apres avoir patché GCC avec SSP et drolement pratique.

Je dois pas etre le premier a me poser toutes ces questions, alors qui a fait quoi ? je vous remercie d'avance parce que là, je pédale dans la semoule.
  • # Bah ...

    Posté par  . Évalué à 5.

    Je pense qu'il faut plus parler d'une certaine "hygiène de vie" plutôt que de tomber dans la paranoia la plus totale.

    Les outils tous compilés à la mimine c'est bien, mais il faut re certain de ne pas rater sa veille sur les vulnérabilités parce qu'à la première mise à jour, on ne peut compter que sur soi-même.

    Je prefère encore des paquets précompilés qui vont s'intégrer au système de mise à jour global de la distribution (ce qui n'empèche pas le travail de veille, mais le rend supportable).

    GRsecurity ou autres sont de bonnes choses pour le noyau ceci dit, mais ca n'empèche pas les reflexe de base :

    - chrooter les services
    - ne pas donner plus de droit que le minimum
    - ne pas se faire confiance en placant les règles de firewall (les règles c'est dans tous les sens)

    Après dans la catégorie des petites habitudes, penser à jeter un coup d'oeil à ses logs sans pour autant essayer de remonter à la source à chaque passage de script kiddies.

    Pousser le bouchon un peu plus loin après c'est vérifier la somme de contrôle des éléments essentiels.

    Ahh j'oubliais (parmis plein d'autres choses) : faire en sorte de pouvoir repartir vite à tout moment d'une machine douteuse !

    Ce qui fait la différence, c'est le temps nécessaire pour redémarrer tous les services en partant d'un disque vierge. Si on part du principe que la machine est jetable et qu'on s'en fout, on ne peut jamais avoir mal :)

    A mon avis il ne faut pas trop en faire ... l'énergie dépensée n'est pas souvent mesurable en terme de gain de sécurité.

    Et tout ca quel que soit le système, tant que tu es à l'aise avec.

    M
  • # Vaste sujet

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

    Bonjour,

    sécuriser une machine ne s'explique pas en 5 minutes. Cependant, voici quelques pistes pouvant t'y aider :

    - j'ai écrit une documentation http://olivieraj.free.fr/fr/linux/information/firewall/(...) sur le sujet, et je t'y invite à la lire. La partie II parle de la sécurisation des démon (http, ftp, etc...), et la partie III explique comment configurer netfilter/iptables.

    - pour ce qui est des démons, la première chose à faire est de limiter au strict minimum ceux qui vont écouter sur les interfaces réseaux sensibles. Par exemple, si tu mets à jour ton serveur avec Samba/NFS via ton réseau local, pas la peine que Samba/NFS écoute aussi sur l'interface réseau Internet. "xinetd" ( http://olivieraj.free.fr/fr/linux/information/firewall/fw-02-05.htm(...) ) fait très bien cela, avec ses options "only_from" et "bind". Mais chaque démon a généralement des options permettant de le faire (comme l'indique http://olivieraj.free.fr/fr/linux/information/firewall/fw-02-05.htm(...) ).

    - tu peux mettre aussi en place des "chroot" ( http://olivieraj.free.fr/fr/linux/information/firewall/fw-02-04.htm(...) ). Personnellement, sur mon réseau local avec mon serveur DNS ("named"), j'ai créé ce type de chroot car "named" est un démon qui était à l'époque "souvant" sujet à des découvertes de buffer overflow. Cela n'est pas forcément trivial de créer un tel chroot, et cela n'apporte pas une sécurité absolue. Mais c'est un bon début.

    - dans une approche plus globale de la sécurité, tu peux aussi changer les droits des éxectutables situés sur ta machine. Par exemple, sur une machine serveur ou passerelle, les commandes "wget" ou "ftp" ne sont pas toujours strictement nécéssaires à tout les utilisateurs. Pourtant, si par exemple un intrus réussi à faire executer une commande shell par ton serveur apache, celui-ci pourra alors faire un "wget" sur un autre serveur qu'il contrôle, afin de uploader sur ta machine un rootkit. La solution pour éviter ceci : supprimer "wget", ou plus simplement, changer les droits d'accès à wget ("chown o-rwx wget"), pour que personne hormis le root (et un groupe d'utilisateurs de confiance) ne puisse l'utiliser.

    - enfin, il faut faire très très attention à la configuration de tes demons eux-même. Pour cela, il faut lire à fond la doc, et regarder toutes les options. Un exemple simple : "proftpd", un serveur FTP. si tu prends la configuration par défaut, tout utilisateurs de ta machine pourra se connecter à ce serveur. Y compris un intrus utilisant les comptes de type "système" comme "apache", "mail", "nobody", etc... En lisant des doc sur Internet, tu trouveras facilement comment restreindre l'accès à "proftpd" à seulement des comptes de "vrais" utilisateurs. Autre exemple : ssh. Il n'est pas question de laisser un accès ssh à tout le monde. L'option "allowuser" permet de restraindre l'accès qu'à un certain nombre de comptes ("guillaume" par exemple). Et bien entendu, interdiction de se loger directement en ssh sur la machine ("permitrootlogin no"), mais passer passer d'abord par un compte utilisateur ("guillaume"), puis faire un "su".

    Ceci n'est qu'un ébauche de réponse à ta question. Je laisse d'autres LinuxFRiens apporter leurs propre experiance.
    • [^] # Re: Vaste sujet

      Posté par  . Évalué à 2.

      Une question que je me pose depuis très longtemps : Quel est l'intérêt de xinetd par rapport à lancer les démons en standalone ?
      J'avoue qu'actuellement, pour mes besoins persos, j'ai tous les serveurs en standalone (sshd, httpd, samba, nfs) et j'ai configuré le firewall en conséquence.
      • [^] # Re: Vaste sujet

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

        Xinetd permet théoriquement de gérer tout cela de la même façon pour chaque daemon. Toutefois, il nécessite de lancer un processus pour chaque nouvelle connexion tcp, il s'avère donc gourmand en puissance.

        Il date de l'époque aussi ou les daemons n'étaient pas forcément capables de gérer euh-même leurs pool de socket et les optimisations associées.

        Apache a donné le "la" et est aujourd'hui beaucoup moins gourmand et beaucoup plus optimisé en mode standalone qu'inetd.

        désormais, la plupart des daemons (exemple apache samba proftpd) sont capables de gérer euh-même leur socket, autant leur laisser le faire. De plus, ces mêmes daemons ont souvent (si ce n'est toujours) des directives de conf pour leur demander de n'écouter que sur certaines interfaces ou ip (bind de socket).

        j'aurais donc tendance à dire
        - standalone pour la performance
        - bien configurer ses services pour qu'ils n'écoutent que sur les ips q'ils devront servir.
        - ajouter un firewalling devant si besoin, par exemple pour restreindre l'accès à ce service aux ip locales de manière plus formelle.
      • [^] # Re: Vaste sujet

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

        Je rajouterai à l'explication ci-dessus quelques petites choses :
        - en terme de charge mémoire pour des processus peu utiliser (sshd par exemple), xinetd est plus intéressant. En effet, xinetd est present en mémoire, mais tant qu'aucune connexion n'est lancé sur le port en question (22 pour sshd), le demon (sshd) lui n'est pas executé.

        - xinetd propose tout un tas d'options intéressantes, et qui ne sont pas forcement développés par les mainteneurs des démons : restriction d'interface et d'adresse IP, log centralisés, restriction des connexions à certaines dates/heures, etc...

        - certaines fonctionnalités comme "echo", "discard", "chargen", sont parfoit très pratiques pour tester un réseau, mais sont en général très peu souvant utilisées. Et bien ce type de service est fournit par défaut par xinetd, sans avoir besoin de charger plus la mémoire de la machine.

        - xinetd propose dans une syntaxe unique de configuration, ce qui permet d'éviter de connaitre toutes sortes de paramètres de configuration de différents démons (voir les différentes syntaxes dans les tableaux de http://olivieraj.free.fr/fr/linux/information/firewall/fw-02-05.htm(...) )

        - enfin, un truc assez pratique: Lorsque l'on modifie une option de configuration d'un démon (sshd, proftpd, ...), il n'y a pas besoin de rédemarrer le démon en question, ni même redémarrer xinetd. Il suffit de refaire une connexion sur le service (22, 21, ...), pour qu'un nouveau demon démarre, avec la nouvelle configuration. Cela n'a l'air de rien, mais lorsque l'on configure un nouveau démon, il est souvant utile de faire des tests de différentes configurations, et ne par avoir à faire de "service demon restart", cela fait gagner du temps !
    • [^] # Re: Vaste sujet

      Posté par  . Évalué à 1.

      merci pour ta reponse,

      dans le meme genre de howto il y a http://www.debian.org/doc/manuals/securing-debian-howto/(...) qui est pas mal aussi, par exemple sur le montage des disques et les problemes qui en decoulent (avec apt notamment).

      Pour tes chroot, sans un systeme de jail à la GRsecurity, c'est vraiment utile ?

      Je cherche plutôt des systemes "completement" fermé à la PaX comme anti-bufferoverflow et des gens qui utilise ca depuis quelques temps.
      • [^] # Re: Vaste sujet

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

        Pour tes chroot, sans un systeme de jail à la GRsecurity, c'est vraiment utile ?

        Comme toujours, tout dépend du niveau de sécurité attendu. Un simple chroot permet de limiter les dégats, et bloquera un script kiddy qui ne pourra pas lancer son "wget" pour installer un rootkit. Par contre, cela ne tiendra pas contre un intrus expérimenté, qui veut vraiment rentré dans la machine.

        C'est pourquoi la sécurité n'une machine ne se concoit que de façon globale, en accumulant les méchanismes de sécurité, afin de ralentir un maximum l'intrus.
        • [^] # Re: Vaste sujet

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

          De plus, cela dépend des cas, mais un chroot peut offrir une protection non négligeable s'il n'est pas possible de devenir root dedans (ce qui implique que le démon chrooté s'exécute en tant qu'utilisateur non-privilégié). Attention aussi au règles de firewall (il peut-être possible de "rebondir" sur le chroot pour contourner un firewall).
  • # mandriva en mode paranoïa

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

    Pour sécurisé sans m'embéter, j'ai utilisé une mandriva en mode paranoïa. Le principe est que tout est fermé par default de partout. C'est à toi de creuser tout les trous pour que cela fonctionne. C'est assez formateur.

    De base, un utilisateur ne peut pas se balader dans l'arborescence, le noyau est patché grsec et autre.

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

    • [^] # Re: mandriva en mode paranoïa

      Posté par  . Évalué à 1.

      j'ai lu une doc sur les produits mdk:

      http://www.loria.fr/~dexheime/documents/selinux.pdf(...)

      les gars de LORIA se sont cassé les dents a vouloir installer SElinux sur mandriva. Leur conclusion est de s'intéresser a débian, gentoo, fedora. en qualifiant mandriva de station de travail pour utilisateur final.
      • [^] # Re: mandriva en mode paranoïa

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

        SElinux c'est bien le truc de la NSA ? Il me semble qu'il s'agit d'un ensemble de patch pour le noyau avec des gestion avancé de droit. Bref, vu que le noyau de la mandriva est patché GRsec et autre, cela ne m'étonne pas que cela ne marche pas directement.

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

        • [^] # Re: mandriva en mode paranoïa

          Posté par  . Évalué à 1.

          Patché ne veut pas dire que toutes les fonctionnalités sont activées au boot (sinon pour les RBAC grsecurity tu t'en rendrais compte avec une policy par défaut ;) ). Idem pour PaX à moins que l'équipe mandriva n'ait bien marqué tous les binaires .
      • [^] # Re: mandriva en mode paranoïa

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

        Cela a vraiment l'air d'un boulot d'étudiant. En fait quand tu lis la paragraphe qui suit tu comprends tout de suite : 1) ils connaissent
        pas mandrake 2) ne savent pas que tous les noyaux proposés par les distribs sont patchés à mort 3) qu'il est hyper simple de compiler et d'installer sont propre noyau.

        La distribution Mandrake ne fournissant en standard aucun noyau précompilé ou “patch” spécifique nous avons été contraint de le générer notre propre noyau SELinux. Dans un premier temps nous avons tenté d’utiliser les noyaux fournis en paquets de sources par la distribution Mandrake et nous sommes de suite retrouvés confrontés à des incompatibilités avec le noyau “vanilla” (l’officiel de kernel.org) et donc avec les patchs officiels proposés par la NSA."

        Ensuite, il s'étonne qu'il faille finir l'install à la main sur la mandrake...

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

  • # Linux Jaily

    Posté par  . Évalué à 1.

    Si tu souhaites faire des serveurs virtuels à le moins d'overhead :

    http://www.linux-vserver.org(...)

    même principe que les jails pour BSD mais en plus complet (selon moi)
    • [^] # Re: Linux Jaily

      Posté par  . Évalué à 2.

      si ce n'est que pour améliorer les chroots de base sous linux, je pense qu'une solution de type grsecurity est meilleure que les vservers qui servent plus à proposer des services mutualisés.
      D'ailleurs, si je me rappelle bien, les auteurs du patch vserver proposaient il y a quelques temps leur patch avec grsecurity intégré. On se demande pourquoi ? :)
      • [^] # Re: Linux Jaily

        Posté par  . Évalué à 2.

        > les auteurs du patch vserver [...] On se demande pourquoi ? :)

        Ce sont pas les auteurs (ils ont déjà assez de taff comme ca) mais Christian Heim et moi même. (un peu moins ces temps-ci)

        Nous l'intégrons
        - pour rajouter une couche de sécurité.
        - parce qu'on aime bien GrSecurity
        - parce qu'on aime bien Vserver

        Personnellement, j'utilise Vserver et GrSecurity non pas pour du mutualisé mais pour améliorer la sécurité et séparer les services et aussi pour garder un système clean.
  • # Ma sécurité

    Posté par  . Évalué à 3.

    Pour sécuriser une machine, je commence par installer ma distribution favorite (Debian) avec le minimum requis pour un système de base en configurant bien tout ce qui est installé.

    Ensuite, j'installe un kernel grsecurity ( http://www.grsecurity.org(...) ) patché par mes soins, je trouve que c'est l'un des meilleurs "patchs" pour la sécurité niveau noyau, mais il demande du temps afin de comprendre / analyser / configurer ses nombreuses options. Attention à bien choisir les options du noyau, que ce soit pour la configuration de grsecurity ou pour celles des options de base du noyau (ça ne sert à rien d'avoir des fonctionnalités en trop, par habitude, je n'utilise jamais les modules, je n'active pas leur support ...)

    Apres l'étape de configuration du noyau, une bonne chose à faire est de passer gradm en mode "apprenant", de restreindre les privilèges / accès / ... de certains programmes ... (grsecurity permet vraiment beaucoup de chose, voici une documentation bien qu'elle date un peu : http://tigrou3tac.org/index.php?current=3&suite=1&article=3(...) )

    Ensuite, je configure le firewall (iptables + IMQ pour la qos) qui ne laissera passer que ce qui est autorisé et ce dans les 2 sens.
    Viens ensuite la configuration des services. J'essaye d'en chrooter le maximum possible, et c'est là qu'intervient grsecurity, il "renforce" les chroots ( je pense qu'un chroot n'est valable que sur une machine grsecurity, peut être avec d'autres patchs noyau aussi mais je ne les connais pas). Ne pas oublier de bien configurer ces services et de définir leur portée (réseau local ou disponible depuis internet ?) , les utilisateurs autorisés à s'y connecter ... Dans le cas où plusieurs programmes sont en concurrence pour proposer un service, une bonne démarche à suivre serait d'étudier leur mode de fonctionnement, de savoir quelle politique sécuritaire ils utilisent (par exemple pour proposer un service ftp, à-t-on besoin de toutes les options de proftpd ? vsftpd ne serait pas plus adapté ?).

    A présent que tous les services sont installés, configurés et sécurisés au maximum de leurs possiblités, il faut penser à espionner la machine, ce qui passe par l'installation d'un NIDS, de processus de surveillance ... en vrac, j'utilise snort (avec oinkmaster pour la mise à jour des règles), cacti et nagios pour superviser un peu le réseau, tiger pour un audit de sécurité du système.

    Une fois la machine proprement installée, il ne faut pas oublier de faire les mises à jour, de consulter les listes de bugs/vulnérabilités/... de tous les composants du système (noyau, prog, ...) et d'étudier les logs générés (qui peuvent être assez conséquent si vous activez les bonnes options de grsecurity, mais rien ne pourra vous échapper :)

    Voilà pour mes habitudes de configuration au niveau de la sécurité, ce n'est surement pas la meilleure solution mais je pense que ça m'apporte une bonne protection, surtout pour un particulier.
    Tout ça pour dire que j'aime bien grsecurity, que je le recommande et que j'aimerais bien avoir des retours d'expérience de son utilisation avec des noyaux 2.6.x.y .
    • [^] # Re: Ma sécurité

      Posté par  . Évalué à 2.

      Je cautionne ta démarche ;) que je partage (avec des plus mais j'imagine que tu n'as pas cité tout ce que tu fais). Pour ce qui est du php(comme tu parlais de cacti) il y a hardened-php qui est intérressant et bien sûr dès que tu fais du web modsecurity.

      Dans la mesure du possible il est également utile de recompiler les applications sensibles avec les options -fstack-protector de gcc (patché ssp).

      Et puis la base c'est aussi une politique de mots de passe correcte avec des protections contre le brute-force.
  • # doc gentoo

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

    y'a le manuel sécurité de gentoo qui est vraiment bien foutu et très formateur (et en français !).

    http://www.gentoo.org/doc/fr/security/security-handbook.xml(...)

    De manière générale j'ai pris l'habitude d'aller souvent voir les docs Gentoo même si je suis pas utilisateur de la distro car leur qualité est indéniable.
    • [^] # Re: doc gentoo

      Posté par  . Évalué à 1.

      Waou, si tu l'avais pas posté je l'aurais fait :)

      Y'a de très bonnes doc pour avoir une gentoo sécioure aussi ... Genre en jouant sur les use et compagnie.

Suivre le flux des commentaires

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