Ceci est une question canonique sur la sécurisation d'une pile LAMP
Quelles sont les instructions absolues pour sécuriser un serveur LAMP?
Ceci est une question canonique sur la sécurisation d'une pile LAMP
Quelles sont les instructions absolues pour sécuriser un serveur LAMP?
Réponses:
La réponse de David constitue une bonne base de référence pour les principes généraux de la sécurisation des serveurs. Comme David l'a indiqué, la question est énorme. Les techniques spécifiques que vous utiliserez dépendront beaucoup de votre environnement et de la manière dont votre serveur sera utilisé. Attention, cela peut prendre beaucoup de travail dans un environnement de test pour être construit correctement. Suivi de beaucoup de travail à intégrer dans votre environnement de production et, plus important encore, dans les processus métier.
Cependant, vérifiez d’abord si votre organisation a des stratégies de renforcement, car celles-ci pourraient être les plus directement pertinentes. Sinon, selon votre rôle, le moment est peut-être bien choisi pour les développer. Je recommanderais également de traiter chaque composant séparément du bas vers le haut.
Le L
Il y a beaucoup de bons guides disponibles pour vous aider. Cette liste peut vous aider ou non, selon votre distribution.
Le
Apache peut être amusant à sécuriser. Je trouve qu'il est plus facile de durcir le système d'exploitation et de maintenir la facilité d'utilisation qu'Apache ou PHP.
Leur
Le P
Cela va tête baissée dans l'idée des pratiques de programmation sécurisée, ce qui est toute une discipline propre. SANS et OWASP ont une quantité ridicule d'informations sur le sujet, je ne vais donc pas essayer de la reproduire ici. Je vais me concentrer sur la configuration d'exécution et laisser vos développeurs se préoccuper du reste. Parfois, le "P" dans LAMP fait référence à Perl, mais généralement à PHP. J'assume ce dernier.
Franchement, vous avez posé une question digne de quelques livres sur le sujet. Mais il existe quelques directives générales de base qui fonctionnent bien:
J'espère que cela vous aidera à démarrer.
Voici une bonne liste de contrôle avec laquelle j'aime bien commencer.
En ajoutant à ce que David suggère, plus votre installation est modulaire (je veux dire par là limiter l'accès à certains utilisateurs / groupes créés spécifiquement pour une tâche et limiter leur portée), plus votre pile LAMP est sécurisée: Un exemple en est un utilisateur Apache. pour les fichiers / dossiers Apache avec les autorisations définies en conséquence et non dans les groupes pouvant accéder aux fichiers / dossiers système critiques. Un utilisateur pouvant accéder aux tables MySql associées à vos sites Web que vous allez servir et uniquement à ces tables. De plus, vous pouvez restreindre leur accès pour donner le minimum d'accès à partir d'un appel PHP. Assurez-vous également que le nom d'utilisateur MySQL utilisé / exposé via le fichier PHP ne correspond pas au même nom d'utilisateur ou mot de passe utilisé par un autre utilisateur.
Qu'est-ce que cela signifie: si l'utilisateur apache ou l'utilisateur MySql sont compromis, ils ne peuvent pas faire de mal en dehors du ou des dossier (s) auxquels apache a accès (dans le cas de l'utilisateur apache) et en dehors de la table ( s) / database (s) (dans le cas de l'utilisateur pour la base de données MySQL).
Si l'utilisateur de MySQL devait être 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. Dans certaines circonstances, ils PEUVENT pouvoir supprimer des tables ou insérer des informations dans certaines tables d’une base de données isolée. C’est pourquoi il est important d’accorder l’accès aux tables uniquement lorsque cela est absolument nécessaire et d’accorder uniquement les autorisations nécessaires ... si vous ne le faites pas. Il n’est pas nécessaire d’avoir des privilèges de suppression de tables ou de mise à jour, ne les donnez pas à cet utilisateur.
De plus, si pour une raison quelconque, le nom d'utilisateur et le mot de passe de votre compte administratif sont trouvés 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 casser la sécurité de votre système avant d'entrer dans votre base de données pour causer des dommages. Il en va de même pour l'utilisateur apache et l'accès aux fichiers.
Exemple de temps! Je vais donner un exemple de système pour simplifier en quelque sorte l'idée.
disons que vous avez des utilisateurs sur votre système (root doit être désactivé pour des raisons de sécurité via quelque chose comme umod -l ou passwd -l, etc.): john, barney, terence et lisa.
vous pouvez créer un utilisateur dans MySQL avec le nom de bigbird (assurez-vous d'utiliser un mot de passe haché). Bigbird ne dispose que de certains privilèges et privilèges de mise à jour, mais pas de suppression ni de création, et certainement pas . De plus, vous créez un autre utilisateur administratif MySQL 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 d'éviter toute compression. garfield a été accordé . les privilèges 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 la racine du document définie sur ce sous-dossier. Les liens symboliques seraient désactivés afin de ne pas donner accidentellement l'accès au reste du système.
En outre, vous pouvez restreindre l'accès ssh à certains utilisateurs uniquement (ou à certains groupes, j'aime bien les placer dans le groupe ssh et en faire le seul moyen d'utiliser ssh).
De plus, vous pouvez choisir les utilisateurs qui ont des privilèges sudo pour restreindre davantage les choses. Une autre étape consiste à rendre tout utilisateur ssh incapable de se connecter à sudo. Vous pouvez créer des utilisateurs spéciaux pouvant utiliser sudo et ne pouvant pas utiliser ssh. Ainsi, une fois que vous avez ssh, vous devez vous connecter à un autre utilisateur accès au 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 résoudre le problème 1 au lieu de devoir tout recommencer à zéro.
J'ai trouvé ce document de SANS.org vraiment utile http://www.sans.org/score/checklists/linuxchecklist.pdf
À l’heure actuelle, ne négligez pas la virtualisation de conteneur, à savoir Docker, systemd-nspawn et les mécanismes de virtualisation de conteneur sur lesquels ils sont construits (espaces de noms, cgroups). L'utilisation de la virtualisation de conteneur vous permet d'isoler des processus. Par exemple, si l'un des services est compromis, un attaquant n'aura pas accès aux autres services.
Dans le cas de LAMP, il est possible d’utiliser, par exemple, quatre conteneurs Docker avec serveur SSH, Apache, MySQL, PHP-FPM / Python / Perl / etc.