web-dev-qa-db-fra.com

Conseils pour sécuriser un serveur LAMP

Ceci est une question canonique sur la sécurisation d'une pile LAMP

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

linuxsecuritylamp
96
Aditya Shukla

La réponse de David est une bonne base de référence des principes généraux du renforcement du serveur. Comme David l'a indiqué, c'est une énorme question. Les techniques spécifiques que vous prenez peuvent dépendre fortement de votre environnement et de la façon dont votre serveur sera utilisé. Attention, cela peut prendre beaucoup de travail dans un environnement de test pour se développer et se faire correctement. Suivi par beaucoup de travail pour s'intégrer dans votre environnement de production, et plus important encore, les processus métier.

Cependant, vérifiez d'abord si votre organisation a des politiques de renforcement, car celles-ci pourraient être les plus directement pertinentes. Sinon, selon votre rôle, ce pourrait être le moment idéal pour les développer. Je recommanderais également d'aborder chaque composant séparément de bas en haut.

Le L
Il existe de nombreux bons guides pour vous aider. Cette liste peut ou non vous aider selon votre distribution.

Le A
Apache peut être amusant à sécuriser. Je trouve plus facile de durcir le système d'exploitation et de maintenir la convivialité qu'Apache ou PHP.

Le M

Le P
Cela va à l'encontre de l'idée de Secure Programming Practices, qui est une discipline à part entière. SANS et OWASP ont une quantité ridicule d'informations sur le sujet, donc je n'essaierai pas de les reproduire ici. Je vais me concentrer sur la configuration d'exécution et laisser vos développeurs s'inquiéter du reste. Parfois, le "P" dans LAMP fait référence à Perl, mais généralement à PHP. J'assume ce dernier.

108
Scott Pack

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

  1. Reste informé. Cela signifie le système d'exploitation, tous les services et, en particulier, toutes les applications Web que vous exécutez.
  2. Désactivez tous les services inutiles, limitez ceux qui sont nécessaires à l'exposition minimale (si vous ne vous connectez pas à distance à MySQL, alors ne l'écoutez pas 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 SSH pour l'administration.))
  3. Utilisez des mots de passe forts. Mieux encore, si vous utilisez SSH, utilisez uniquement 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écurisées, vous devez exécuter des outils comme logwatch afin de savoir ce qui se passe sur votre serveur.

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

14
David

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

Pare-feu

  • Une bonne approche consiste à ne pas autoriser tout trafic, puis ouvrez uniquement ce dont vous avez besoin, selon vos besoins. Cela se traduit par l'ouverture des ports/ips minimum pour faire fonctionner les choses et qui minimise votre exposition.
  • Pour un serveur LAMP, vous n'aurez peut-être qu'à ouvrir les ports pour http/https au monde et ssh pour les administrateurs système.
  • Assurez-vous que des choses comme le trafic ipv6 sont verrouillées si vous ne les utilisez pas
  • AWS fournit des groupes de sécurité, Linux a iptables ainsi que de nombreux packages parmi lesquels choisir.

SSH et utilisateurs

  • Pas de mot de passe pour l'accès ssh (utilisez une clé privée)
  • Ne pas autoriser root à ssh (les utilisateurs appropriés devraient ssh in, puis su ou Sudo)
  • Utilisez Sudo pour les utilisateurs afin que les commandes soient enregistrées
  • Enregistrez les tentatives de connexion non autorisées (et envisagez un logiciel pour bloquer/interdire les utilisateurs qui tentent d'accéder à votre serveur trop de fois, comme fail2ban)
  • ssh sur un port non standard (cela peut être utile pour vous assurer que vous n'êtes pas à court de fruits et garder une grande partie du trafic ennuyeux, mais ne fera pas grand-chose pour la sécurité, en particulier par lui-même)
  • verrouillez ssh uniquement à la plage IP dont vous avez besoin (une grande plage vaut mieux qu'aucune plage)

Base de données

  • Sanitize user data
  • Paramétrer les requêtes
  • Envisagez d'abstraire 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 vice versa.
  • Comme tout logiciel se tenir à jour est important.
  • n utilisateur pour chaque objectif. Lorsque vous créez des utilisateurs, commencez sans privilèges et ajoutez uniquement ceux dont ils ont besoin pour exécuter leur rôle. Le fait d'avoir des utilisateurs distincts pour différentes applications (ou parfois des parties distinctes des applications) contribuera à réduire les avantages d'un attaquant s'il compromettait un seul compte. Faites également attention aux privilèges spéciaux comme GRANT qui ne doivent pas être attribués à la légère.
  • Avoir une politique pour changer périodiquement les mots de passe est une bonne idée. Si vous êtes inquiet au sujet de la quantité d'effort requise, rappelez-vous que moins fréquent vaut mieux que jamais.
  • Comprenez le cryptage des mots de passe. Mots de passe Salt. N'utilisez pas md5!

Logiciel

  • Gardez le logiciel à jour (os, serveur Web, langage de script, CMS). De nombreuses personnes rechercheront des 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 le package requis pour compiler les logiciels sur les serveurs de production, il est préférable de précompiler les logiciels et de les rendre disponibles sous forme de package pour vos machines de production)
  • Assurez-vous que le fichier les autorisations sont verrouillées (en particulier pour des choses comme les téléchargements d'utilisateurs et les fichiers de configuration)
  • Mot de passe protège la zone d'administration du CMS au niveau du serveur Web (authentification http peut se placer devant un CMS vulnérable et aider à bloquer l'accès, ce qui est un bon moyen de prévenir les attaques)
  • tiliser 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 à corriger des choses sur de nombreux serveurs et à réduire les scénarios tels que la fixation des autorisations sur le serveur A mais en oubliant de le faire sur le serveur B
  • Dans la mesure du possible, ne donnez pas la version particulière de votre CMS, PHP ou WebServer. Bien que masquer ces informations ne soit pas de la sécurité, de nombreuses personnes recherchent des versions particulières de différents logiciels et les moins d'informations que vous donnez librement, plus un attaquant doit travailler. C'est un bon moyen de vous assurer que vous ne faites pas partie des fruits bas. Bien sûr, cela ne fera rien à quelqu'un qui veut dépenser un peu plus d'efforts pour obtenir dans
  • Limiter les personnes qui ont accès au serveur
9
Drew Khoury

Ajoutant à ce que David suggère, plus votre installation est modulaire, je veux dire restreindre 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 de cela est d'avoir un utilisateur Apache pour les fichiers/dossiers Apache avec des autorisations définies en conséquence et non dans les groupes pouvant accéder aux fichiers/dossiers système critiques. Un utilisateur qui peut 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 PHP = le fichier n'est pas le même nom d'utilisateur ou mot de passe utilisé pour un autre utilisateur.

Ce que cela signifie: si l'utilisateur Apache ou l'utilisateur MySql sont compromis, ils ne peuvent pas faire de mal en dehors de la portée des dossiers auxquels Apache a accès (dans le cas de l'utilisateur Apache) et en dehors de la table ( s)/base (s) de données (dans le cas de l'utilisateur de la base de données MySQL).

Si l'utilisateur MySQL devait être compromis d'une manière ou d'une autre, il ne pourrait pas, par exemple, accéder à la base de données et supprimer toutes les bases de données de MySQL et ruiner toutes vos données. Ils POURRAIENT 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 que lorsque cela est absolument nécessaire et d'accorder uniquement les autorisations nécessaires ... si vous ne le faites pas '' t besoin d'avoir des privilèges de tables de dépôt ou de mise à jour, alors 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 découverts pour MySQL, si vous utilisez un nom d'utilisateur différent de tout nom d'utilisateur sur votre système, ils doivent d'abord briser la sécurité de votre système avant d'entrer dans 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.

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 n'a que certains privilèges et privilèges de mise à jour, mais pas supprimer ou créer, et certainement pas . 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 à partir de la base de données MySQL afin qu'il ne puisse pas être compressé. garfield a obtenu 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 fournir accidentellement l'accès au reste du système.

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

De plus, vous pouvez choisir quels utilisateurs ont les privilèges Sudo pour restreindre encore plus les choses. Une autre étape que vous pouvez aller plus loin est de rendre les utilisateurs ssh incapables de Sudo, vous pouvez créer des utilisateurs spéciaux qui peuvent utiliser Sudo qui ne peuvent pas utiliser ssh, de sorte qu'une fois que vous vous connectez, vous devez vous connecter à un autre utilisateur pour avoir accès à Sudo.

Ainsi, en modularisant chaque segment, si l'un est compromis, la pile entière ne sera pas compromise et vous pouvez résoudre le problème 1 au lieu d'avoir à tout recommencer à zéro.

5
86bornprgmr

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

3
wsindhu

À l'heure actuelle, ne négligez pas la virtualisation de conteneurs, à savoir Docker, systemd-nspawn et les mécanismes de virtualisation de conteneurs sur lesquels ils sont construits (espaces de noms, cgroups). L'utilisation de la virtualisation de conteneurs vous permet d'isoler les 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.

1
Quarind