La réponse de David est une bonne base de référence des principes généraux du durcissement des serveurs. Comme David l'a indiqué, il s'agit d'une question très vaste. Les techniques spécifiques que vous adopterez dépendront fortement de votre environnement et de la façon dont votre serveur sera utilisé. Attention, cela peut demander beaucoup de travail dans un environnement de test pour le mettre au point et le faire correctement. Ensuite, il faudra beaucoup de travail pour l'intégrer dans votre environnement de production et, plus important encore, dans votre processus commercial.

Cependant, vérifiez d'abord si votre organisation dispose de politiques de renforcement, car ce sont les plus directement pertinentes. Si ce n'est pas le cas, en fonction de votre rôle, c'est le moment idéal pour les mettre en place. Je vous recommande également de vous attaquer à chaque composant séparément, de bas en haut.

Le L
Il existe beaucoup de bons guides pour vous aider. Cette liste peut ou non vous aider en fonction de votre distribution.

• Benchmarks du Centre pour la sécurité sur Internet - Distribution spécifique pour les principaux parfums
• CentOS Hardening HowTo - Suit de près le guide CIS RHEL5, mais est beaucoup plus facile à lire.
• NIST SP800-123 - Guide de la sécurité générale des serveurs
• Fiches d'information sur le durcissement de la NSA - La mise à jour n'est pas aussi récente que celle du CIS, mais elle reste largement applicable.
• Tigre - Logiciel d'audit de la sécurité des systèmes en direct

L'A
Apache peut être amusant à sécuriser. Je trouve qu'il est plus facile de renforcer le système d'exploitation et de maintenir l'utilisabilité que Apache ou PHP.

• Renforcement du serveur Apache - Cette question sur le site frère de IT Security contient de nombreuses informations utiles.
• Benchmarks du Centre pour la Sécurité Internet - Encore une fois, les repères Apache.
• Conseils de sécurité pour Apache - Tout droit sorti du projet Apache, il semble qu'il couvre l'essentiel.
• Liste de contrôle du durcissement de la DISA - Liste de contrôle des gars du DoD Information Assurance

Le M

• Benchmarks du Centre pour la Sécurité Internet - Encore une fois, mais pour les benchmarks MySQL
• OWASP MySQL Hardening
• Directives générales de sécurité - Liste de contrôle de base des développeurs du projet

Le P
Cela va à l'encontre de l'idée même de pratiques de programmation sécurisées, qui est une discipline à part entière. Le SANS et l'OWASP disposent d'une quantité ridicule d'informations sur le sujet, je ne vais donc pas essayer de les reproduire ici. Je me concentrerai sur la configuration de l'exécution et laisserai vos développeurs s'occuper du reste. Parfois, le "P" de LAMP fait référence à Perl, mais généralement à PHP. Je suppose qu'il s'agit de PHP.

• Durcissement de PHP - Quelques discussions mineures, également sur le site IT Security SE.
• Projet PHP renforcé - Projet principal qui produit Suhosin une tentative de correction de l'application PHP pour la projeter contre certains types d'attaques.
• Durcissement de PHP avec Suhosin - Un bref HowTo spécifique à Suhosin
• Durcissement de PHP à partir de php.ini - Une discussion courte, mais pas mauvaise, sur certaines des options d'exécution liées à la sécurité.

Vous avez posé une question qui, très franchement, mériterait quelques livres sur le sujet. Mais il existe des directives générales de base qui fonctionnent bien :

1. Tenez-vous au courant. Cela signifie le système d'exploitation, tous les services, et SURTOUT toutes les applications web que vous utilisez.
2. Désactivez tous les services inutiles, limitez ceux qui sont nécessaires à une exposition minimale (si vous ne vous connectez pas à distance à MySQL, ne le faites pas écouter sur TCP) et exécutez un pare-feu basé sur l'hôte. (Si c'est strictement LAMP, vous devriez être bon avec 80 et 443, mais peut-être aussi avec SSH pour l'administration).
3. Utilisez des mots de passe forts. Mieux encore, si vous utilisez SSH, n'utilisez que l'authentification par clé.
4. Assurez-vous que vous ne vous connectez pas en tant que root. Connectez-vous en tant qu'utilisateurs et utilisez su & sudo.
5. Bien que cela ne rende pas les choses plus sûres, vous devriez utiliser des outils tels que logwatch afin d'être au courant de ce qui se passe sur votre serveur.

J'espère que cela vous aidera à démarrer.

Voici une bonne liste de contrôle avec laquelle j'aime commencer.

Pare-feu

• Une bonne approche consiste à ne pas autoriser de trafic au départ, puis à seulement ouvrir ce dont vous avez besoin en fonction de vos besoins. Cela permet d'ouvrir le minimum de ports/ips pour que les choses fonctionnent et cela minimise votre exposition.
• Pour un serveur LAMP, il se peut que vous n'ayez besoin d'ouvrir que les ports suivants http/https au monde entier et ssh pour les sysadmins.
• Assurez-vous que des choses comme le trafic ipv6 sont verrouillées si vous ne l'utilisez pas.
• AWS fournit des groupes de sécurité, linux dispose de iptables ainsi que de nombreux paquets à choisir. parmi lesquels choisir.

SSH et utilisateurs

• Pas de mot de passe pour l'accès ssh (utiliser la clé privée)
• Ne pas autoriser root à ssh (les utilisateurs appropriés doivent se connecter par ssh, puis su ou sudo)
• Utiliser sudo pour les utilisateurs afin que les commandes soient enregistrées
• Consigner les tentatives de connexion non autorisées (et envisager un logiciel pour bloquer/interdire les utilisateurs qui essaient d'accéder à votre serveur trop souvent, comme fail2ban).
• ssh sur un port non standard (cela peut être utile pour s'assurer que vous n'êtes pas un fruit mûr, et éloigner une grande partie du trafic ennuyeux, mais ne fera pas grand-chose pour la sécurité, particulièrement en soi)
• verrouillez ssh à la seule plage d'adresses IP dont vous avez besoin (une grande plage vaut mieux que pas de plage).

Base de données

• Assainir les données des utilisateurs
• Paramétrer les requêtes
• Envisagez d'abstraire la base de données vers sa propre machine. Cette séparation peut rendre plus difficile l'accès d'un attaquant à votre pile web et vice versa.
• Comme tout logiciel se tenir au courant est important.
• Un utilisateur pour chaque objectif . Lorsque vous créez des utilisateurs, commencez sans privilèges et ajoutez uniquement ceux dont ils ont besoin pour remplir leur rôle. Le fait d'avoir des utilisateurs distincts pour différentes applications (ou parfois des parties distinctes d'applications) contribuera à réduire les avantages dont dispose un attaquant s'il compromet un seul compte. Faites également attention aux privilèges spéciaux tels que GRANT, qui ne doivent pas être attribués à la légère.
• Avoir une politique de changement périodique des mots de passe est une bonne idée. Si vous vous inquiétez de l'effort à fournir, mieux vaut moins souvent que jamais.
• Comprendre le cryptage des mots de passe. Mots de passe en sel . N'utilisez pas md5 !

Logiciel

• Maintenir les logiciels à jour (os, serveur web, langage de script, CMS). De nombreuses personnes analysent les vulnérabilités connues dans les anciennes versions (non corrigées).
• Supprimez tous les logiciels dont vous n'avez pas besoin (idéalement, ne conservez pas les paquets nécessaires à la compilation des logiciels sur les serveurs de production, il est préférable de précompiler les logiciels et de les mettre à la disposition de vos machines de production sous forme de paquets).
• Assurez-vous que le fichier les permissions sont verrouillées (surtout pour des choses comme les téléchargements des utilisateurs et les fichiers de configuration)
• Protection par mot de passe de la zone d'administration du CMS au niveau du serveur web ( authentification http peut se placer en face d'un CMS vulnérable et aider à en bloquer l'accès, ce qui est un bon moyen de prévenir les attaques)
• Utiliser SSL pour les zones d'administration et autres données sensibles
• Automatisez la gestion de vos serveurs et de votre infrastructure (quelque chose comme Puppet, Chef ou SaltStack. Si vous utilisez AWS CloudFormation également). Cela vous aidera à appliquer des correctifs sur de nombreux serveurs et à éviter des scénarios tels que la correction des permissions sur le serveur A et l'oubli de le faire sur le serveur B.
• Dans la mesure du possible, ne donnez pas la version particulière de votre CMS, PHP ou serveur Web. Bien que le fait de masquer cette information ne constitue pas une mesure de sécurité, il existe de nombreuses personnes qui recherchent des versions particulières de différents logiciels et moins vous donnez d'informations, plus un attaquant a de quoi travailler. C'est un bon moyen de s'assurer que vous ne faites pas partie des fruits mûrs. Bien sûr, cela ne fera rien à quelqu'un qui veut dépenser un peu plus d'efforts pour entrer dans le système.
• Limiter les personnes qui ont accès au serveur

En complément de ce que suggère David, plus votre installation est modulaire, c'est-à-dire qu'elle restreint l'accès à certains utilisateurs/groupes créés spécifiquement pour une tâche et limitant leur champ d'action, plus votre pile LAMP est sécurisée : Un exemple de ceci est d'avoir un utilisateur Apache pour les fichiers/dossiers Apache avec des permissions définies en conséquence et pas dans les groupes qui peuvent accéder aux fichiers/dossiers critiques du système. Un utilisateur qui peut accéder aux tables MySql qui sont associées aux sites Web que vous allez servir et uniquement à ces tables. De plus, vous pouvez restreindre leur accès pour qu'ils aient le minimum d'accès à partir d'un appel PHP. Assurez-vous également que le nom d'utilisateur MySQL utilisé/exposé par le biais du fichier PHP n'est pas le même nom d'utilisateur ou mot de passe que celui utilisé par un autre utilisateur.

Cela signifie que si l'utilisateur apache ou l'utilisateur MySql est compromis, il ne peut pas faire de dégâts en dehors du ou des dossiers auxquels apache a accès (dans le cas de l'utilisateur apache) et en dehors de la ou des tables/bases de données (dans le cas de l'utilisateur de la base de données MySQL).

Si l'utilisateur de MySQL était compromis, il ne pourrait pas, par exemple, accéder à la base de données, supprimer toutes les bases de données de MySQL et détruire toutes vos données. Il pourrait, dans certaines circonstances, être en mesure de supprimer des tables ou d'insérer des informations dans certaines tables d'une base de données isolée. C'est pourquoi il est important de n'accorder l'accès aux tables qu'en cas de nécessité absolue et de n'accorder que les autorisations nécessaires.

De plus, si, pour une raison quelconque, le nom d'utilisateur et le mot de passe de votre compte administratif sont découverts pour MySQL, si vous utilisez un nom d'utilisateur différent de tous les noms d'utilisateur de votre système, ils doivent d'abord briser la sécurité de votre système avant d'accéder à votre base de données pour faire des dégâts. Il en va de même pour l'utilisateur apache et l'accès aux fichiers.

C'est l'heure des exemples ! Je vais donner un exemple de système pour simplifier l'idée.

disons que vous avez des utilisateurs sur votre système (root doit être désactivé pour des raisons de sécurité par quelque chose comme umod -l ou passwd -l, etc :) John, Barney, Terence et Lisa.

vous pourriez créer un utilisateur dans MySQL avec le nom de bigbird (veillez à utiliser un mot de passe haché). Bigbird ne dispose que des privilèges de sélection et de mise à jour, mais pas des privilèges de suppression ou de création, et certainement pas des privilèges d'accès. . En outre, vous créez un autre utilisateur MySQL administratif avec le nom garfield pour travailler sur la base de données MySQL et vous supprimez l'utilisateur root de la base de données MySQL afin qu'il ne puisse pas être compromis. garfield a été accordé . dans MySQL (en fait, il s'agit simplement de renommer root).

maintenant, vous créez un groupe apache ou un utilisateur et nous l'appellerons apweb2. Appweb2 n'est pas membre d'autres groupes, et tous les fichiers/dossiers pour apache sont stockés dans /home/apweb2/. Chaque hôte virtuel aurait son propre sous-dossier et chacun de ces hôtes aurait une racine de document définie dans ce sous-dossier. Les liens symboliques sont désactivés afin de ne pas donner accidentellement accès au reste du système.

De plus, vous pouvez restreindre l'accès à ssh à certains utilisateurs seulement (ou certains groupes, j'aime les mettre dans le groupe ssh, et faire en sorte que ce soit la seule chose capable d'utiliser ssh).

De plus, vous pouvez choisir quels utilisateurs ont des privilèges sudo pour restreindre encore plus les choses. Une autre étape que vous pouvez franchir est de faire en sorte que tous les utilisateurs de ssh ne puissent pas utiliser sudo, vous pouvez créer des utilisateurs spéciaux qui peuvent utiliser sudo mais pas ssh, de sorte qu'une fois que vous vous êtes connecté à ssh, vous devez vous connecter à un autre utilisateur pour avoir accès à sudo.

Ainsi, en modularisant chaque segment, si l'un d'entre eux est compromis, l'ensemble de la pile ne le sera pas et vous pourrez remédier à un seul problème au lieu de devoir tout recommencer depuis le début.

J'ai trouvé ce document de SANS.org très utile. http://www.sans.org/score/checklists/linuxchecklist.pdf