Renforcement du serveur Linux

Question

Nous avons déjà posé des questions sur Hardening Apache , Hardening PHP and Securing SSH .

Pour poursuivre cette tendance, je suis intéressé par les mesures que les gens prennent pour durcir les serveurs Linux. Comme dans quelles étapes les gens prennent-ils toujours lors de la configuration d'un nouveau serveur, qui ne sont pas spécifiques à l'application. Telles que la définition de la partition tmp pour être noexec, la désinstallation/désactivation de certains services, e.t.c.

Answer 1

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, les désinstaller après la construction initiale.

Ici, je pense à ces coupables communs qui semblent encore passer par trop de distributions par défaut!

• Services NFS: nfsd, lockd, mountd, statd, portmapper
• serveur telnet et serveur ftp
• Services R: rlogin, rsh, rcp, rexec
• Serveur BIND et DNS sauf si nécessaire
• serveurs de messagerie tels que sendmail
• X11 (sauf si le bureau est nécessaire)
• démon doigt etc

La prochaine étape consiste à passer en revue les services potentiellement faibles et à en limiter l'accès.

• utilisez 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 - les droits d'accès 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ésactivez les comptes système inutiles.
• Regardez le système de fichiers - des éléments collants pour tous les exécutables et répertoires publics.
• Vérifiez toutes les exigences root (variable d'environnement PATH, pas d'accès distant en tant que root, appartenance au groupe, exigences de mot de passe)
• Vérifier toutes les exigences des utilisateurs (appartenance à des groupes privilégiés, shells valides, umask, SUID, SGID)
• et bien sûr le guide SANS est une très bonne source!

Answer 2

L'espace "Serveur Linux" comprend un énorme gamme de distributions , chacun avec sa propre stratégie de mise à jour de configuration par défaut, sa chaîne d'outils de gestion de packages 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 très différent de celui d'un routeur basé sur Linux. Vous pouvez obtenir de meilleurs conseils en vous renseignant sur les distributions et les cas d'utilisation qui vous intéressent le plus.

Dans cet esprit, je vais juste aborder la sécurité d'Ubuntu ici en pointant vers certaines sources pertinentes, bien qu'une grande partie de cela soit utile pour 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 se tournent 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 effectuer 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 pour faire ce qui est à: https://wiki.ubuntu.com/Security/Privileges

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

Answer 3

Le durcissement du système à un point dans le temps 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 la qualité (voir les liens ci-dessous) qui détaillent les modifications de configuration recommandées à effectuer pour renforcer la sécurité de vos serveurs et appliquez les modifications qui conviennent à votre configuration. Mieux encore, codifiez les recommandations via Puppet ( http://www.puppetlabs.com/ ): c'est un gagnant-gagnant, vous déploierez plus sûr et vous '' Vous vous donnerez une chance de combattre les configurations durcies au fil du temps.

Bonus : Modélisation des attaques/modélisation des 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 comme:

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

Traduisez votre réponse à la deuxième question en modifications de configuration spécifiques (renforcement) ou en implémentant des contrôles supplémentaires. Le jeu, bien sûr, consiste à minimiser les chances de succès d’une menace. Cela prend du temps, mais vous vous sentirez mieux au sujet des changements que vous avez apportés et pourquoi par rapport à apporter des changements au hasard parce que quelqu'un a dit que c'était bien de le faire.

Obtenez un excellent niveau de journalisation et d'examen . La prévention échoue toujours: pour contrer cette réalité, vous souhaitez augmenter la journalisation afin d'identifier et de réagir plus rapidement aux incidents et de 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 du temps supplémentaire à personnaliser les règles incluses avec OSSEC pour surveiller les choses qui vous préoccupent le plus est une activité utile (par exemple, répertorier des répertoires et des fichiers supplémentaires à alerter). si elles sont modifiées, en ajoutant des règles ou en augmentant la gravité des règles existantes pour vous alerter des anomalies d'authentification, en ajoutant des règles pour surveiller les modifications de la table utilisateur mysql ( http://blog.rootshell.be/2011/ 01/07/auditing-mysql-db-integrity-with-ossec / ), ad infinitum). 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 de vos défenses de serveur, vous pouvez exécuter Nessus ( http://www.nessus.org/nessus/ ) sur une base continue avec le Centre pour les modèles d'audit Linux Internet Security (CIS). Utilisez les résultats comme référence, surveillez les changements et corrigez les faiblesses découvertes.

Pour récapituler:

1) Tirez parti 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 (espérons-le après avoir effectué des activités de modélisation des attaques/menaces et choisi un cadre de gestion de configuration)

2) Augmentez les capacités d'observation: améliorez la journalisation (c.-à-d. Ajustez le système pour générer suffisamment de journaux pour les activités que vous souhaitez observer), déployez 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) Faire en sorte que la responsabilité de quelqu'un soit un défenseur assidu des systèmes

4) Auditez et testez continuellement pour vérifier ce que vous pensez être en train de faire

ressources de référence/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 perturbation des affaires et du commerce électronique résultant d'une insuffisance technique. contrôles de sécurité. La Division fournit aux entreprises des normes de meilleures pratiques consensuelles pour les configurations de sécurité, ainsi que des ressources pour mesurer l'état de la sécurité des informations et prendre des décisions rationnelles concernant les investissements en matière 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 programme national de liste de contrôle (NCP), défini par le NIST SP 800-70 Rév. 1, est le référentiel du gouvernement américain des listes de contrôle de sécurité (ou benchmarks) accessibles au public qui fournissent des conseils détaillés de bas niveau sur la définition de la configuration de sécurité des systèmes d'exploitation et des applications.

Answer 4

Vous pourriez faire bien pire que de commencer par Sans checklist .

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

Answer 5

Tout d'abord, vous devez comprendre l'objectif 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 confiance ou non?

Permettez-moi de supposer 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 possède un compte sur votre machine. Voici les étapes que je prends:

• Activez 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 autorisation explicite dans la politique de pare-feu. J'autorise les connexions entrantes vers les services 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 une excellente prise en charge du filtrage avec état, de sorte qu'une fois la connexion établie, tous les paquets 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 tout 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 déconseiller les mises à jour automatiques, car il existe le risque qu'une mise à jour interrompt certains services; vous devrez soupeser 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 défaillants, 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 sur les services exposés. Cela peut parfois être un peu pénible (cela m'a parfois causé des problèmes, interrompant un service d'une manière difficile à déboguer), mais pour un paramètre critique pour la sécurité, je pense que cela en vaut la peine.

• Configurer SSH pour l'administration à distance. Vous devez configurer SSH pour pouvoir administrer la machine à distance. Je vous recommande de générer une clé privée DSA côté client, de la chiffrer avec une phrase secrète, 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 souhaiterez peut-être personnaliser le sshd_config fichier de configuration sur le serveur également. 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 rechange utile en cas de problème avec votre clé privée, mais c'est également un risque plus élevé, 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. Si c'est juste vous et que vous avez une très grande confiance en 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éremment.

• Si vous avez plusieurs administrateurs système, configurez-en des comptes. Donnez à chacun d'eux un accès Sudo ou créez un compte racine distinct pour chaque administrateur système.

• Activer 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 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 détails 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 fiables sur votre serveur, il devient beaucoup plus difficile de renforcer la sécurité: la surface d'attaque est beaucoup plus grande. Si cela vous inquiète, 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 très différent.)

Answer 6

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

Sommaire:

• Protéger les débordements de tas et de piles
• Masquer les autres processus utilisateurs
• Liste de contrôle d'accès basée sur les rôles
• Durcissement Chroot
• / proc, FIFO et restrictions dmesg
• Capacités de journalisation avancées

Answer 7

Pour Red Hat , NSA contient des conseils sur le renforcement. Voir Guide de configuration pour Red Hat Enterprise Linux 5 - NSA/CSS .

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

Answer 8

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

Answer 9

Si vous essayez de sécuriser votre système en désinstallant des packages/services inutiles, vous avez déjà un problème plus important. Ces packages n'auraient pas dû être installés en premier lieu.

Vous devez installer un système minimaliste et ajouter uniquement les packages 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 tout le support (vous n'en aurez pas besoin de toute façon à 95%)