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.
Journal Linux sécurisé, GRsecurity, RSBAC, PaX, SSP, libsafe, SElinux,...
10
août
2005
# Bah ...
Posté par Maillequeule . Évalué à 5.
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 Olivier (site web personnel) . Évalué à 7.
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 Frédéric COIFFIER . Évalué à 2.
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 Benjamin (site web personnel) . Évalué à 1.
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 Pierre . Évalué à 1.
Joli
[^] # Re: Vaste sujet
Posté par Olivier (site web personnel) . Évalué à 4.
- 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 abc . Évalué à 1.
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 Olivier (site web personnel) . Évalué à 1.
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 Nicolas Bernard (site web personnel) . Évalué à 2.
# mandriva en mode paranoïa
Posté par Nicolas Boulay (site web personnel) . Évalué à 3.
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 abc . Évalué à 1.
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 Nicolas Boulay (site web personnel) . Évalué à 2.
"La première sécurité est la liberté"
[^] # Re: mandriva en mode paranoïa
Posté par voodoo . Évalué à 1.
[^] # Re: mandriva en mode paranoïa
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
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 Prae . Évalué à 1.
http://www.linux-vserver.org(...)
même principe que les jails pour BSD mais en plus complet (selon moi)
[^] # Re: Linux Jaily
Posté par Fabien (site web personnel) . Évalué à 2.
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 Prae . Évalué à 2.
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 Fabien (site web personnel) . Évalué à 3.
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 voodoo . Évalué à 2.
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 patrick_g (site web personnel) . Évalué à 6.
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 Sasuke . Évalué à 1.
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.