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!

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/

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.

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.

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 .)

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

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.

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

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%)