Question Astuces pour sécuriser un serveur LAMP


C'est un Question canonique à propos de la sécurisation d'une pile LAMP

Quelles sont les instructions absolues pour sécuriser un serveur LAMP?


91
2017-12-14 01:52


origine




Réponses:


La réponse de David est 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 peuvent dépendre fortement 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, commencez par vérifier si votre organisation dispose de 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 A
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 à l’encontre de l’idée des pratiques de programmation sécurisées, qui est une discipline à part entière. 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.


105
2017-12-14 14:50



Je veux voter cette réponse au moins 10 fois. - user58859
Le N silencieux - Avec IPTables ou un pare-feu externe, bloquez les connexions réseau uniquement à ce dont le public a besoin. - Matt
Cela devrait être un wiki de communauté - Brian Adkins
C'est tellement facile d'oublier le pare-feu. J'ai entendu parler de quelqu'un qui a construit un serveur Web pour un site Web et est même allé jusqu'à pirater la pile TCP / IP pour jeter le trafic qui n'était pas le port 80. Une autre chose qui est négligée est celle des services inutiles - si elle n'en a pas besoin pour être allumé, éteignez-le. - Aaron Mason
@AaronMason: Félicitations! Vous avez une anecdote réussie. Rappelons-nous que votre situation spécifique a bien fonctionné, mais espérons que les futurs lecteurs comprendront votre environnement inhabituel. Dans le cas général, ce conseil est assez dangereux. - Scott Pack


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:

  1. Reste informé. Cela signifie que le système d'exploitation, tous les services et surtout toutes les applications Web que vous exécutez.
  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 l'écoutez pas en 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 SSH pour l'administration.))
  3. Utilisez des mots de passe forts. Mieux encore, si vous utilisez SSH, utilisez uniquement l’authentification basée sur la clé.
  4. Assurez-vous de ne pas vous connecter en tant que root. Connectez-vous en tant qu'utilisateur et utilisez su & sudo.
  5. Même si cela ne rend pas les choses plus sécurisées, vous devez utiliser des outils tels que logwatch pour être au courant de ce qui se passe sur votre serveur.

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


13
2017-12-14 02:23



Je suggère de lire le "Guide pour la configuration sécurisée de Red Hat Enterprise Linux 5" rédigé par la NSA - ALex_hha
tard dans la soirée, mais j’ai lu récemment que "ne pas se connecter en tant que root" n’a plus une telle importance, surtout si vous utilisez l’authentification SSH basée sur des clés publiques / privées. - the0ther


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

Pare-feu

  • Une bonne approche consiste à ne permettre à aucun trafic de commencer, puis seulement ouvrez ce dont vous avez besoincomme vous en avez besoin. Cela se traduit par l'ouverture du minimum de ports / ips pour que les choses fonctionnent et qui minimise votre exposition.
  • Pour un serveur LAMP, il vous suffit peut-être d’ouvrir des ports pour http / https au monde et ssh pour les administrateurs système.
  • Assurez-vous que des éléments tels que le trafic ipv6 sont verrouillés s'ils ne sont pas utilisés
  • AWS fournit des groupes de sécurité, linux a iptables ainsi que de nombreux packages à choisir de.

SSH et utilisateurs

  • Pas de mot de passe pour un accès SSH (utiliser une clé privée)
  • Ne pas autoriser root à ssh (les utilisateurs appropriés doivent ssh, puis su ou sudo)
  • Utilisez sudo pour les utilisateurs afin que les commandes soient enregistrées
  • Consignez les tentatives de connexion non autorisées (et envisagez un logiciel pour bloquer / interdire les utilisateurs qui tentent d'accéder à votre serveur trop souvent, comme fail2ban)
  • ssh sur un port non standard (cela peut être utile pour vous assurer que vous n'êtes pas à la traîne et que vous gardez une bonne partie du trafic gênant, mais que vous ne ferez pas grand chose pour la sécurité, en particulier par lui-même)
  • verrouillez ssh uniquement sur la plage ip de votre choix (une grande plage vaut mieux que pas de plage)

Base de données

  • Désinfecter les données utilisateur
  • Paramétrer les requêtes
  • Envisagez de résumer la base de données sur sa propre machine. Cette séparation peut rendre plus difficile pour un attaquant d'accéder à votre pile Web et inversement.
  • Comme n'importe quel logiciel se tenir au courant est important.
  • Un utilisateur pour chaque objectif. Lorsque vous créez des utilisateurs, démarrez sans privilèges et ajoutez uniquement ceux dont ils ont besoin pour modifier leur rôle. Le fait de disposer d'utilisateurs distincts pour différentes applications (ou parfois de parties distinctes d'applications) contribuera à réduire les avantages dont dispose un attaquant qui compromettrait un 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 pour changer les mots de passe périodiquement est une bonne idée. Si vous êtes inquiet au sujet de la quantité d'effort requis, rappelez-vous, moins fréquemment est mieux que jamais.
  • Comprendre le cryptage du mot de passe. Mots de passe sel. N'utilisez pas md5!

Logiciel

  • Garder le logiciel à jour (os, serveur Web, langage de script, CMS). Beaucoup de gens vont rechercher 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 gardez pas le paquet nécessaire pour compiler le logiciel sur des serveurs de production, il est préférable de le pré-compiler et de le mettre à la disposition de vos machines de production).
  • Assurez-vous que le fichier les autorisations sont verrouillées (surtout pour des choses comme les téléchargements d'utilisateurs et les fichiers de configuration)
  • Protéger par mot de passe la zone administrative du CMS au niveau du serveur Web (authentification http peut s'asseoir devant un CMS vulnérable et aider à bloquer l'accès, ce qui est un bon moyen de prévenir les attaques)
  • Utiliser SSL pour la zone d'administration et d'autres données sensibles
  • Automatisez la gestion de vos serveurs et de votre infrastructure (quelque chose comme Puppet, Chef ou SaltStack. Si vous utilisez également AWS CloudFormation). Cela vous aidera à appliquer des correctifs à de nombreux serveurs et à réduire des scénarios tels que la fixation d'autorisations sur le serveur A, mais en oubliant de le faire sur le serveur B
  • Dans la mesure du possible, ne cédez pas la version de votre CMS, PHP ou WebServer. Bien que masquer ces informations ne soit pas une sécurité, de nombreuses personnes recherchent des versions particulières de différents logiciels. Moins vous communiquez librement des informations, plus un attaquant doit travailler. C'est un bon moyen de vous assurer que vous n'êtes pas un fruit à portée de main. Bien sûr, cela ne fera rien à quelqu'un qui veut consacrer un peu plus d'effort à entrer
  • Limiter le nombre de personnes ayant accès au serveur

7
2017-08-10 08:08





En ajoutant à ce que David suggère, plus votre installation est modulaire (par exemple, je veux dire restreindre l'accès à certains utilisateurs / groupes créés spécifiquement pour une tâche et limiter leur étendue), 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é pour 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 du tableau ( 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 (la racine devrait être désactivée pour des raisons de sécurité 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é . privilèges sur MySQL (en fait, il s’agit 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 les placer dans le groupe ssh et en faire le seul moyen d'utiliser ssh).

En outre, vous pouvez choisir les utilisateurs disposant 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 pour pouvoir 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.


4
2017-07-30 04:49





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


2
2017-08-10 11:50



Bienvenue sur Server Fault! Généralement, nous aimons que les réponses sur le site puissent être autonomes - Les liens sont excellents, mais si ce lien se brise, la réponse devrait avoir suffisamment d’informations pour être toujours utile. Pensez à modifier votre réponse pour inclure plus de détails. Voir le FAQ pour plus d'informations. - slm


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


0
2017-07-27 20:00