Question:
Durcissement du serveur Linux
Mark Davidson
2010-12-06 16:04:07 UTC
view on stackexchange narkive permalink

Nous avons déjà eu des questions ici sur le durcissement d'Apache, le durcissement de PHP et la sécurisation de SSH.

Pour continuer cette tendance, je suis intéressé par les mesures que les gens prennent pour renforcer les serveurs Linux. Comme dans les étapes que les gens prennent toujours lors de la configuration d'un nouveau serveur, qui ne sont pas spécifiques à une application. Tels que définir la partition tmp sur noexec, désinstaller / désactiver certains services, e.t.c.

J'ai ajouté une prime à cette question car j'aimerais voir des réponses plus détaillées, au lieu de simplement des liens vers d'autres listes. Vous recherchez quelque chose comme la réponse principale à la question Hardening Apache - http://security.stackexchange.com/questions/77/apache-server-hardening/83#83
@Mark IMHO Je ferais confiance aux liens vers des benchmarks tels que CIS, bien plus que je ne me fierais à une liste aléatoire de choses à faire pour renforcer un serveur Linux. CIS est beaucoup plus approfondi, évalué par des pairs et éprouvé que ce que quelqu'un pourrait trouver sur ce site.
@Josh Je suis d'accord avec vous en ce qui concerne la confiance. Mais l'intérêt de tous les sites de stackexchange n'est-il pas de savoir si une réponse est la confiance par le nombre de votes positifs ou négatifs dont il dispose. Bien sûr, les gens devraient faire référence à d'autres ressources, mais un résumé des points clés de la liste de contrôle référencée serait bon à mon avis, car cela aide les utilisateurs à identifier plus facilement si la ressource leur sera utile.
Comme je l'ai noté dans ma réponse, l'espace du «serveur linux» est beaucoup trop large et diversifié pour obtenir une seule réponse utile. Alors divisez-le par distribution. Différentes distributions ont des ensembles de services très différents installés par défaut et des approches de renforcement. Même les téléphones Android peuvent être considérés comme des serveurs Linux, qui écoutent les appels téléphoniques et la messagerie cloud à périphérique (C2DM) et peuvent être configurés pour servir http, etc. Mais il n'utilise même pas une pile GNU typique. Si quelqu'un donnait une réponse complète, vous perdriez du temps à vérifier toutes les choses stupides qui doivent être évitées sur certaines distributions.
C'est pourquoi j'ai gardé ma réponse sous forme de liste d'éléments clés à examiner, mais suffisamment généraux pour qu'ils conviennent à presque tous les serveurs Linux.
Cela ressemble à une question wiki. À quoi ressemblerait la «bonne» réponse? La personne qui n'a pas été possédée depuis le plus longtemps? :)
@nealmcb J'apprécie la difficulté de cette question et elle est assez large, si les gens veulent être spécifiques à une distribution c'est très bien. J'utilise personnellement les serveurs Debian et Ubuntu, donc les réponses qui leur sont adaptées sont excellentes.
http://library.linode.com/security/basics
Pour ceux qui recherchent un outil pour auditer et vérifier le durcissement d'un système, jetez un œil à mon outil [Lynis] (http://rootkit.nl/projects/lynis.html). Cela peut être une excellente extension des points de repère / directives mentionnés et aide à la validation.
Neuf réponses:
#1
+57
Rory Alsop
2010-12-06 18:51:31 UTC
view on stackexchange narkive permalink

Identifiez les applications et les processus requis et appliquez une liste de contrôle pour éviter de les installer ou, dans le pire des cas, désinstallez-les après la construction initiale.

Ici, je pense aux coupables courants qui semblent encore continuer à beaucoup trop de distributions par défaut!

  • Services NFS: nfsd, lockd, mountd, statd, portmapper
  • serveur telnet et serveur ftp
  • services R : rlogin, rsh, rcp, rexec
  • BIND et serveur DNS sauf si nécessaire
  • serveurs de messagerie tels que sendmail
  • X11 (sauf si un ordinateur de bureau est nécessaire)
  • finger daemon etc

La prochaine étape consiste à passer en revue les services faibles potentiels et à limiter leur accès

  • utiliser at.allow et cron.allow pour restreindre l'accès à crontab
  • Assurez-vous que tous les appareils sont illisibles et inscriptibles par les utilisateurs ordinaires (à l'exception de ceux tels que / dev / tty et / dev / null, etc.)
  • Fichiers clés - autorisations sur ceux-ci doivent appartenir à root: / etc / fstab, / etc / password, / etc / shadow
  • Vérifiez attentivement hosts.equiv - une excellente source d'accès ici :-)
  • De même, la configuration NFS est verrouillée si elle est requise
  • Désactiver les comptes système inutiles.
  • Regardez le système de fichiers - sticky bits pour tous les exécutables et répertoires publics.
  • Vérifiez toutes les exigences de racine (variable d'environnement PATH, pas d'accès distant en tant que root, appartenance au groupe, exigences de mot de passe)
  • Vérifiez toutes les exigences des utilisateurs (appartenance à des groupes privilégiés, shells valides, exigences umask, SUID, SGID
  • et bien sûr le guide SANS est une très bonne source!
Probablement une question stupide, mais ... Pourquoi les utilisateurs ne devraient-ils pas être autorisés à écrire dans / lire à partir de / dev / null? Je sais qu'il existe d'autres moyens d'obtenir ses fonctionnalités (par exemple, `verboseprogram |:`)? Y a-t-il déjà eu une implémentation non sécurisée de / dev / null?
** excluant **, parthe
** googles un peu plus ** Oh- d'accord. Espèce de buse sournoise ...
* "Identifiez les applications et les processus requis et appliquez une liste de contrôle pour éviter de les installer" * Pourquoi éviteriez-vous d'installer vos * applications requises *? Je suppose que vous voulez dire "* applications standard mais non obligatoires *"?
#2
+25
nealmcb
2010-12-07 08:27:13 UTC
view on stackexchange narkive permalink

L'espace "Linux Server" comprend une vaste gamme de distributions, chacune avec sa propre stratégie de mise à jour de la configuration par défaut, sa propre chaîne d'outils de gestion des paquets et son approche des services par défaut et des ports ouverts. Il existe également un large éventail de scénarios de déploiement: le renforcement d'un serveur Web est assez différent du renforcement d'un routeur basé sur Linux. Vous pouvez obtenir de meilleurs conseils en vous posant des questions sur les distributions et les cas d’utilisation qui vous intéressent le plus.

Dans cette veine, je vais simplement aborder la sécurité Ubuntu ici en pointant vers certaines sources pertinentes , bien qu'une grande partie de cela soit utile dans d'autres situations.

Une bonne introduction est ici: http://www.andrewault.net/2010/05/17/securing-an-ubuntu- server /

La communauté a décrit ici des valeurs par défaut plus strictes et des conseils de renforcement qui penchent davantage vers la sécurité même si la convivialité est affectée: https://help.ubuntu.com/community/ StricterDefaults

Voici une matrice et un résumé des fonctionnalités de sécurité d'Ubuntu, pour aider les gens à rechercher des listes de contrôle que vous trouverez ailleurs: https://wiki.ubuntu.com/Security/Features

Pour voir comment vous pouvez faire certains des tests vous-même, consultez la transcription dans http://people.canonical.com/~kees/demo/ec2-session.log piloté par le code de démonstration dans http://people.canonical.com/~kees/demo/

Un résumé de ce qu'il faut faire w chapeau est à: https://wiki.ubuntu.com/Security/Privileges

L'équipe de sécurité d'Ubuntu a d'autres informations utiles sur son wiki: https: //wiki.ubuntu.com/Security/

#3
+21
Tate Hansen
2010-12-07 00:11:07 UTC
view on stackexchange narkive permalink

Le renforcement ponctuel du système est un exploit bénéfique, mais ce qui définit vraiment le déploiement d'un serveur en toute sécurité, c'est ce qui est fait pour maintenir cet état .

Choisissez l'une des listes de contrôle de qualité (voir les liens ci-dessous) qui détaillent les modifications de configuration recommandées à apporter pour renforcer la sécurité de vos serveurs et appliquez les changements qui ont du sens pour votre configuration. Mieux encore, codifiez les recommandations via Puppet ( http://www.puppetlabs.com/): c'est gagnant-gagnant, vous déploierez plus en sécurité et vous " Vous vous donnerez une chance de soutenir les configurations durcies au fil du temps.

Bonus : modélisez les attaques et les menaces ( http://taosecurity.blogspot.com/2007/06/threat-model-vs-attack-model. html) pour concentrer vos efforts défensifs. Par exemple, posez-vous des questions telles que:

Comment un attaquant pourrait-il accéder à ces serveurs?
Que puis-je faire pour réduire ses chances de réussir?

Traduisez votre réponse à la deuxième question en changements de configuration spécifiques (durcissement) ou en implémentant des contrôles supplémentaires. Le jeu, bien sûr, est de minimiser la probabilité de succès d’une menace. Cela prend du temps, mais vous vous sentirez mieux à propos des changements que vous avez apportés et des raisons pour lesquelles vous ne les apportez pas au hasard parce que quelqu'un a dit que c'était bon à faire.

Excellente consignation et révision . La prévention échoue toujours - pour contrer cette réalité, vous souhaitez augmenter la journalisation afin de pouvoir identifier et réagir plus rapidement aux incidents et récupérer plus rapidement. Mon outil préféré pour renforcer les défenses et améliorer la journalisation sous Linux est OSSEC ( http://www.ossec.net/). Passer plus de temps à personnaliser les règles incluses dans OSSEC pour surveiller les choses qui vous préoccupent le plus est une activité intéressante (par exemple, répertorier les répertoires et fichiers supplémentaires pour lesquels il faut être alerté s'ils sont modifiés, ajouter des règles ou augmenter la gravité des règles existantes pour vous alerter des anomalies d'authentification, l'ajout de règles pour surveiller les modifications de la table des utilisateurs mysql ( http://blog.rootshell.be/2011/01/07/auditing-mysql-db-integrity -with-ossec /), à l'infini). Richard Bejtlich vient de publier une entrée de blog opportune intitulée Sept projets open source sympas pour les défenseurs ( http://taosecurity.blogspot.com/2011/01/seven-cool-open-source-projects -for.html)

Pour prendre en charge la vérification continue des défenses de votre serveur, vous pouvez exécuter Nessus ( http://www.nessus.org/ nessus /) sur une base continue avec les modèles d'audit Linux du Center for Internet Security (CIS). Utilisez les résultats comme référence, surveillez les changements et corrigez les faiblesses découvertes.

Pour récapituler:

1) Inspirez-vous des listes de contrôle de renforcement de la sécurité respectées existantes pour vous aider à en rédiger une personnalisée qui fonctionne pour votre environnement (si tout va bien après avoir effectué une attaque / activités de modélisation des menaces et choix d'un cadre de gestion de la configuration)

2) Augmenter les capacités d'observation: améliorer la journalisation (c'est-à-dire régler le système pour générer suffisamment de journaux pour les activités que vous souhaitez observer), déployer HIDS (par exemple OSSEC), déployer des outils d'analyse des journaux (par exemple logwatch - http://sourceforge.net/projects/logwatch/), peut-être capturer les flux réseau (par exemple via softflowd)

3) Faites en sorte que quelqu'un soit responsable d'être un défenseur assidu des systèmes

4) Auditez et testez en permanence pour vérifier ce que vous pensez être en train d'être fait

benchmark / ressources de la liste de contrôle:.

http://cisecurity.org/ Le Center for Internet Security (CIS) est une entreprise à but non lucratif dont la division Benchmarking and Metrics aide les organisations à réduire le risque de les perturbations des affaires et du commerce électronique résultant de contrôles de sécurité techniques inadéquats. La Division fournit aux entreprises des normes de bonnes pratiques consensuelles pour les configurations de sécurité, ainsi que des ressources pour mesurer l'état de la sécurité des informations et pour prendre des décisions rationnelles concernant les investissements de sécurité.

http://iase.disa.mil / stigs / checklist / Agence des systèmes d'information de défense (DISA)

http://web.nvd.nist.gov/view/ncp/repository
http://csrc.nist.gov/fdcc/faq-common_security_configurations.html
Le National Checklist Program (NCP), défini par le NIST SP 800-70 Rev. 1, est aux États-Unis référentiel gouvernemental de listes de contrôle de sécurité (ou benchmarks) accessibles au public qui fournissent des conseils détaillés de bas niveau sur la configuration de la configuration de la sécurité des systèmes d'exploitation et des applications.

#4
+17
symcbean
2010-12-06 17:49:39 UTC
view on stackexchange narkive permalink

Vous pourriez faire bien pire que de commencer avec la liste de contrôle Sans.

Ma seule critique à ce sujet est qu'elle ne met pas suffisamment l'accent sur la gestion de la sécurité d'un déploiement système - en particulier en s'assurant que les correctifs des fournisseurs sont à jour, en planifiant un bon modèle d'autorisations, en gérant les rapports d'exception IDS, etc.

#5
+13
D.W.
2011-01-12 09:12:28 UTC
view on stackexchange narkive permalink

Tout d'abord, vous devez déterminer le but du serveur et le modèle de menace contre lequel vous essayez de vous défendre. S'agit-il d'un serveur à usage unique? Plusieurs utilisateurs ont-ils accès? Si plusieurs utilisateurs y ont accès, leur faites-vous tous confiance ou non?

Je suppose que ce serveur est utilisé uniquement pour les services réseau et que vous n'avez pas à faire face à la menace d'attaques de quelqu'un qui a un compte sur votre machine. Voici les étapes à suivre:

  • Activer un pare-feu. J'utilise iptables pour configurer un pare-feu local. J'utilise une politique default-deny : toutes les connexions entrantes sont bloquées par défaut, sauf si explicitement autorisé dans la politique de pare-feu. J'active les connexions entrantes aux services qui sont destinés à être exportés vers le monde (par exemple, le port 25 s'il s'agit d'un serveur de messagerie, les ports 80/443 s'il s'agit d'un serveur Web, etc.). iptables a un excellent support pour le filtrage avec état, de sorte qu'une fois qu'une connexion est établie, tous les paquets sont associés à cette connexion sont autorisés.

  • Mettez à niveau tous les packages et activez les mises à jour automatiques. Je mets à jour ma distribution Linux vers la dernière version de tous les packages ( yum upgrade sur Fedora, mais utilisez ce qui convient à votre configuration). J'ai également mis en place un script cron pour récupérer et installer automatiquement les mises à jour une fois par jour ( yum -y upgrade sur Fedora). Je me rends compte que certains administrateurs système expérimentés pourraient recommander des mises à jour automatiques, car il existe un risque qu'une mise à jour interrompe certains services; vous devrez peser ce risque par rapport au risque d'une faille de sécurité due à un package obsolète. Personnellement, je trouve que la facilité d'esprit et la commodité des mises à jour automatiques valent le risque de services interrompus, mais ce n'est peut-être pas la bonne réponse dans tous les paramètres opérationnels.

  • Activez SELinux. SELinux fournit une deuxième couche de défense contre les attaques contre les services exposés. Cela peut parfois être un peu pénible (cela m'a parfois causé des problèmes, interrompant un service de manière difficile à déboguer), mais pour un paramètre de sécurité critique, je pense que cela en vaut la peine.

  • Configurer SSH pour l'administration à distance. Vous devez configurer SSH afin de pouvoir administrer la machine à distance. Je vous recommande de générer une clé privée DSA côté client, de la crypter avec une phrase de passe, d'installer la clé publique correspondante dans le fichier authorized_keys sur le serveur et de vous connecter à l'aide de la clé privée. Vous pouvez également personnaliser le fichier de configuration sshd_config sur le serveur. Envisagez de désactiver PasswordAuthentication et d'exiger que les utilisateurs se connectent à l'aide d'une clé publique. L'authentification par mot de passe peut être une solution de secours utile en cas de problème avec votre clé privée, mais c'est aussi un plus grand risque, car les humains choisissent souvent des mots de passe devinables. Si vous avez d'autres utilisateurs sur votre système sur lesquels vous ne pouvez pas compter pour choisir des mots de passe de très haute qualité, vous pouvez désactiver PasswordAuthentication. S'il ne s'agit que de vous et que vous avez une très grande confiance dans tous vos mots de passe, vous pouvez le laisser activé. Je n'empêche pas root de se connecter via SSH, mais vous pourriez vous sentir différent.

  • Si vous avez plusieurs administrateurs système, configurez-leur des comptes. Donnez à chacun d'entre eux un accès sudo ou configurez un compte racine distinct pour chaque administrateur système.

  • Activez DNSSEC. Je configure mes serveurs pour exécuter un serveur DNS de mise en cache local qui valide les noms d'hôte avec DNSSEC dans la mesure du possible, afin de réduire le risque d'usurpation DNS.

Ensuite, pour chaque service qui est exposé au monde, je prends des précautions pour sécuriser ce service. Par exemple, j'active la cryptographie (par exemple, STARTTLS pour les serveurs de messagerie) et les serveurs chroot ou sandbox dans la mesure du possible. Cependant, les spécificités varieront d'un service à l'autre. Par conséquent, je suggère de soumettre une question distincte pour chaque service que vous avez l'intention d'exécuter, en demandant des conseils sur la façon de verrouiller ce service.

Si vous recherchez une distribution Linux qui a déjà beaucoup de durcissement appliqué, je peux fortement recommander Openwall Linux.

(Commentaire: Si vous donnez des utilisateurs non approuvés sur votre serveur, alors il devient beaucoup plus difficile de renforcer la sécurité: le La surface d'attaque est beaucoup plus grande. Si cela vous préoccupe, je vous suggère de poser une question distincte sur la façon de verrouiller votre serveur pour se protéger contre les attaques d'utilisateurs locaux avec des comptes sur votre serveur, car l'ensemble des techniques pour le faire est assez différent .)

#6
+6
Jerry Jacobs
2011-07-21 13:13:20 UTC
view on stackexchange narkive permalink

Et qu'en est-il des correctifs du noyau Grsecurity / PAX, ceux-ci incluent des fonctionnalités très intéressantes pour renforcer le serveur au niveau du noyau.

Résumé:

  • Protéger les débordements de tas et de pile
  • Masquer les processus des autres utilisateurs
  • Liste de contrôle d'accès basé sur les rôles
  • Durcissement de chroot
  • / proc, restrictions FIFO et dmesg
  • Fonctionnalités de journalisation avancées
#7
+4
nealmcb
2011-02-04 03:00:46 UTC
view on stackexchange narkive permalink

Pour Red Hat , la NSA a des conseils sur le durcissement. Reportez-vous aux Conseils de configuration pour Red Hat Enterprise Linux 5 - NSA / CSS.

Ils devraient également être utiles pour CentOS et d'autres dérivés.

Merci à @graham-lee pour avoir signalé le lien NSA dans le chat, pour une question sur Windows 2000. Et venez rejoindre le chat si vous voulez le scoop!
Le lien est mort.
Merci @EvanTeitelman. Lien corrigé via une simple recherche Google.
#8
+3
nealmcb
2011-07-17 04:18:12 UTC
view on stackexchange narkive permalink

Pour RHEL, le Benchmark CIS Red Hat Enterprise Linux 5 du Center for Internet Security semble être une bonne ressource.

#9
+2
Martin Vegter
2013-10-23 18:50:24 UTC
view on stackexchange narkive permalink

Si vous essayez de sécuriser votre système en désinstallant des packages / services inutiles, vous avez déjà un problème plus grave. Ces packages ne doivent pas avoir été installés en premier lieu.

Vous devriez installer un système minimaliste et n'ajouter que les paquets dont vous avez vraiment besoin. La même chose s'applique à votre noyau. Compilez votre propre noyau avec uniquement les fonctionnalités dont vous avez besoin. N'utilisez pas votre noyau de distribution avec un support pour tout (vous n'en aurez pas besoin de toute façon à 95%)

Bien qu'installer un système minimal et partir de là soit une bonne idée, lancer votre propre noyau sera rapidement un exercice de frustration. 1: Vous devrez le recompiler vous-même à chaque fois qu'un nouveau correctif de sécurité apparaîtra. 2: les systèmes exécutant des noyaux compilés par l'utilisateur (en particulier ceux avec un `.config` personnalisé) sont à l'état" non supporté "si vous utilisez RHEL ou SLES. La liste noire des mods que vous n'utilisez pas est cependant une bonne idée.
Plus le noyau est petit, moins il y a de possibilités de bogues de sécurité. Si vous avez éliminé 95% des fonctionnalités inutiles, vous avez également éliminé 95% de la «surface d'attaque». De plus, si des millions d'utilisateurs utilisent le même noyau, il est plus facile de trouver des exploits dans ce noyau particulier.
Je ne prétends pas que cela n'aidera pas en termes de sécurité. Je dis que cela demande beaucoup d'efforts du côté administrateur et a plus de chances que le serveur exécute un noyau obsolète (parce que l'administrateur a oublié ou n'a pas remarqué ou n'a pas eu le temps de préparer une nouvelle configuration, etc.). Le deuxième problème est que si vous dépendez du support tiers, l'utilisation de la configuration de noyau personnalisée peut être tout simplement impossible.


Ce Q&R a été automatiquement traduit de la langue anglaise.Le contenu original est disponible sur stackexchange, que nous remercions pour la licence cc by-sa 2.0 sous laquelle il est distribué.
Loading...