Quelle est votre liste de contrôle / routine lors de la configuration d'un serveur Web Linux?
Que recommandez-vous pour obtenir une sécurité maximale?
Existe-t-il un moyen préféré d'effectuer une maintenance répétée?
Tout d'abord, sachez que toute capacité de script dans Apache (php, cgi, ruby, ...) est l'équivalent potentiel d'un compte shell avec les privilèges de l'utilisateur exécutant le script.
Si le serveur est partagé avec plusieurs utilisateurs, vous voudrez peut-être penser à utiliser suexec (- ou ITK MPM - suggéré par David Schmitt ) afin que tous les scripts ne s'exécutent pas comme le même utilisateur apache.
Virtualisez ou chrootez apache, de sorte que tout compromis soit au moins quelque peu contenu dans une couche de sécurité supplémentaire. Sachez que lorsque vous chrootez Apache, la maintenance peut devenir plus difficile, car vous finissez par déplacer des bibliothèques vers la prison, etc. Si vous utilisez FreeBSD, vous pouvez utiliser une prison à la place, ce qui est beaucoup plus facile à gérer, car vous pouvez simplement installer Apache à partir des ports et exécutez portaudit à partir de celui-ci, sans avoir à vous soucier des dépendances de la bibliothèque et du déplacement manuel des fichiers, ce qui devient toujours un vilain désordre. Avec les prisons BSD, vous pouvez simplement continuer à utiliser le système de gestion de paquets (ports). (Sur GNU / Linux, vous pouvez également utiliser VServer pour la virtualisation. - Suggéré par David Schmitt )
(évidemment) Tenez-vous au courant des mises à jour et des correctifs, non seulement pour Apache, mais aussi PHP, ruby, perl, etc ... ne faites pas seulement confiance à votre système d'exploitation pour vous donner toutes les mises à jour non plus. Certaines distributions sont extrêmement lentes avec leurs patchs. Limitez autant que possible le temps d'exposition aux vulnérabilités 0 jours. Tenez -vous le milw0rm flux dans votre lecteur RSS, abonnez - vous aux Insecure.Org listes de diffusion, etc ... Non seulement il vous aider à apprendre sur les vulnérabilités avant que votre OS se déplace pour libérer un patch, vous apprendrez aussi sur les vulnérabilités dans certains php des applications cms par exemple, qui peuvent même ne pas être gérées ou corrigées par votre système d'exploitation.
Utilisez quelque chose comme tripwire / aide, audit ou mtree (sur BSD) pour garder une trace des changements sur votre système de fichiers. Celui-ci est vraiment important. Recevez régulièrement les modifications par courrier, examinez-les manuellement, tous les jours. Si des modifications de fichier ne devraient pas changer, cherchez pourquoi. Si du javascript malveillant est inséré d'une manière ou d'une autre dans vos pages par quelque méthode que ce soit, vous le capturez de cette façon. Cela enregistre non seulement votre serveur, mais aussi vos utilisateurs, car vos propres pages Web peuvent être utilisées à mauvais escient pour infecter vos visiteurs. (Il s'agit d'une tactique très courante, les attaquants se moquent souvent de votre serveur, ils veulent simplement infecter autant de visiteurs que possible jusqu'à ce qu'ils soient découverts. Ces attaquants ne prennent même pas la peine de cacher leurs traces habituellement. Il est très important de trouver un compromis comme celui-ci le plus rapidement possible.)
Utiliser des trucs comme la suhosine pour protéger le php aide. Mais apprenez aussi à le comprendre, ajustez sa configuration aux paramètres attendus de votre application.
L'utilisation d'un correctif du noyau tel que PaX peut vous protéger contre de nombreuses vulnérabilités de dépassement de tampon. Même si votre logiciel est vulnérable. (Cela ne vous rend pas invulnérable, c'est juste un autre calque mineur.)
Ne soyez pas trop confiant lorsque vous utilisez un outil de sécurité. Comprenez les outils que vous utilisez et faites preuve de bon sens. Lisez, apprenez, restez informé autant que vous le pouvez.
Pensez à utiliser le contrôle d'accès obligatoire (par exemple: SELinux ). Il vous permet de spécifier, pour chaque application, ce qu'il est autorisé à faire, de manière très détaillée. À quels fichiers est-il autorisé à accéder? Ce que le noyau appelle est-il autorisé à faire, etc. C'est un processus très complexe et qui nécessite beaucoup de compréhension. Certaines distributions fournissent des politiques SELinux prédéfinies pour leurs packages (par exemple: Gentoo ). Cette suggestion est en quelque sorte une contradiction avec celle ci-dessous, mais toujours valable, néanmoins.
Gardez les choses simples. Une stratégie de sécurité complexe peut être contre vous.
Dans Apache, définissez des règles par défaut très restrictives (Options Aucune, Refuser de tout, etc ...) et remplacez selon les besoins pour des VirtualHosts spécifiques.
Refuser l'accès à tous les fichiers dot (qui couvre également immédiatement les fichiers .htaccess)
Utilisez toujours https partout où il existe une sorte d'authentification par mot de passe.
Le pare-feu doit être une stratégie de refus par défaut. Créez des règles spécifiques dans votre pare-feu pour enregistrer un trafic spécifique.
Configurez des scripts d'analyse des journaux pour analyser vos journaux afin de détecter des anomalies. (La suite IDS prélude peut le faire, mais honnêtement, je vous recommande de créer vos propres scripts au fil du temps, car cela vous aidera à mieux comprendre vos propres outils et règles.)
Demandez au serveur de vous envoyer quotidiennement des rapports sur les derniers utilisateurs connectés, les connexions actives, la bande passante utilisée, etc.
Ayez une analyse cron pour les binaires suid, les fichiers inscriptibles dans le monde et des trucs comme ça, et faites-les vous envoyer par la poste.
Pour tout ce que vous avez configuré et qui vous est envoyé par courrier, vous devez créer une liste d'exceptions au fil du temps. (dossiers pour ignorer les modifications du système de fichiers, 777 fichiers à autoriser, binaires suid à autoriser). Il est important que vous ne soyez averti que des choses qui ne devraient pas se produire. Si vous recevez chaque jour un courrier contenant des choses insignifiantes, vous commencerez à les ignorer et elles deviendront inutiles.
Avoir une bonne stratégie de sauvegarde redondante en couches solide. Et ne vous contentez pas de supposer que la création d'une image ou d'une copie de tout fonctionne. Par exemple, si MySQL est en train d'écrire dans une table pendant votre sauvegarde, vos fichiers binaires MySQL peuvent être corrompus lorsque vous restaurez votre sauvegarde. Vous aurez donc besoin d'un cron qui mysqldump est vos bases de données au-dessus des images régulières ou des tarballs nocturnes ou du contrôle de version ou de tout ce que vous avez configuré. Pensez à votre stratégie de sauvegarde. Je veux dire vraiment y réfléchir.
Ne comptez pas sur des listes comme celle-ci pour la sécurité :) Sérieusement! Vous en trouverez beaucoup sur Internet, allez les lire toutes, recherchez toutes les suggestions et utilisez votre bon sens et votre expérience pour vous faire votre propre opinion. En fin de compte, l'expérience et le bon sens sont les seules choses qui vous sauveront. Ni listes, ni outils. Lisez, mais ne copiez pas sans comprendre.
Je recommande la liste de contrôle de sécurité Linux , de SAN. J'utilise cela, plus une autre procédure interne. La liste de contrôle est peut-être un peu dépassée, mais bon nombre des points clés restent vrais.
la source
la source
éditez votre ~ / .ssh / config
cela fait
ne répond pas mais
fonctionnera si vous souhaitez vous connecter en tant que root.
la source
Il y aura toujours d'innombrables autorisations à vérifier, d'innombrables listes de contrôle, une découverte sans fin de nouveaux bugs / vulnérabilités. Sécurité Je ne pense pas que c'est quelque chose que vous allumez ou éteignez, c'est quelque chose que vous faites constamment.
Étant donné «l'échec inévitable» des logiciels, SELinux aide à dissiper certaines inquiétudes (là encore, pas de solution miracle pour la sécurité). en supposant qu'une application de l'espace utilisateur soit compromise, la politique SELinux correcte l'empêchera d'agir à ses privilèges habituels (c'est-à-dire si SELinux était désactivé ou permissif). Bien sûr, cela vous demandera de surveiller vos journaux d'audit et d'analyser la politique installée et de la modifier si nécessaire pour permettre aux applications de fonctionner.
Ne pas dire que la politique par défaut n'aiderait pas, mais j'aime personnellement savoir ce qu'elle permet.
la source