web-dev-qa-db-fra.com

Meilleures pratiques pour le renforcement du serveur Apache?

Quelles sont les meilleures pratiques, recommandations et lectures requises pour sécuriser un serveur Apache?

webserverhardeningconfigurationapache
104
Eric Warriner

Prenez le guide du Center for Internet Security (CIS) pour sécuriser Apache (il décrit en détail comment améliorer la sécurité):

Modifier: lien mis à jour CIS Apache HTTP Server 2.2.x Benchmark

Si vous avez une licence pour Nessus , vous pouvez exécuter une vérification automatisée en saisissant leur modèle d'audit:

alt text

31
Tate Hansen
  • Utiliser les connexions basées sur les clés SSH
  • Sécuriser MySQL
  • Désactivez phpMyAdmin, webmin, etc.
  • Fermez tous les ports/processus qui ne sont pas nécessaires
  • Utiliser un vérificateur d'intégrité de fichier
  • Utilisez mod_security
  • Définissez les autorisations/groupes appropriés

Ceci est un bon guide:
https://serverfault.com/questions/212269/tips-for-securing-a-lamp-server

Guide de base pour le durcissement: http://www.wpsecure.net/server-guide/

Si vous utilisez php: http://www.madirish.net/?article=229

Trouver les 404 (ou autres codes d'état) dans le journal Apache
awk '$9 == 404 {print $7}' access_log | uniq -c | sort -rn | head

12
Wyck

La réponse initialement très votée à cette question qui a été acceptée a été supprimée car il s'agissait d'un plagiat direct de 20 façons de sécuriser votre configuration Apache . Cette page est une ressource fantastique.

@RoryMcCune a également posté ceci en tant que lien sur cette réponse: Il existe un projet OWASP pour développer un ModSecurity Core Rule Set here qui pourrait être utile.

7
Jeff Ferland

Il y a beaucoup de bons conseils ici, donc je ne répéterai pas les choses déjà mentionnées. Mais ce que je dirai c'est:

N'oubliez pas de remplacer les pages d'erreur par défaut par des éléments qui ne révèlent pas la version de votre serveur Web ou la révision du noyau. J'ai tendance à remplacer chaque html par défaut par 1 doublures qui sont quelque chose comme "Erreur 400". Il donne très peu d'informations sur le système. Ce principe s'applique à tous les serveurs Web capables d'afficher des pages d'erreur personnalisées, ils sont tous à peu près par défaut à donner beaucoup trop d'informations que nécessaire. On pourrait penser que ServerSignature cacherait cela, mais dans de nombreux cas, ce n'est pas le cas.

N'oubliez pas non plus de supprimer tout le contenu HTML par défaut (spécifique à la langue, etc.), l'empreinte digitale est donc beaucoup plus difficile.

En ce qui concerne les bonnes lectures, il y avait un livre blanc d'Apcon 2008 qui vaut la peine d'être lu.

Mod_Security est mentionné à plusieurs reprises, cela convient mieux aux applications Web, donc si vous ne proposez que du contenu statique, cela ne vous aidera pas aussi beaucoup, bien qu'il y ait quelques attaques contre lesquelles il aide à se défendre pendant le traitement des requêtes qui pourraient affecter un serveur Web statique.

L'autre chose que je mentionnerais est une bonne gestion des journaux, si vous ne fermez pas vos journaux et ne surveillez pas de près le système, vous courez le risque qu'un attaquant le martèle sans en avoir conscience.

6
Ori

Tous les principes de sécurité généraux s'appliquent: exécuter uniquement les modules dont vous avez besoin, désactiver les fonctionnalités dont vous n'avez pas besoin, ranger vos autorisations/propriétés (la plupart des contenus sont en lecture seule, alors pourquoi les fichiers ont-ils besoin de plus de 400 perms?).

Les choses qui sont particulières à Apache, comme les travaux CGI ou différents vhosts servant deux fois le même contenu avec deux mécanismes de sécurité différents, sont beaucoup plus difficiles à repérer; pas exactement une vérification automatisée, vous devez en fait connaître Apache, le système d'exploitation sous-jacent et ce que font les applications exécutées dans Apache.

Par souci d'exhaustivité, voici un Liste de contrôle de sécurité Apache 2.2 de DISA. MISE À JOUR: Voici un lien vers leur collection entière de documents de renforcement de serveur Web.

6
Marcin

Il vaut peut-être la peine de jeter un œil à Apache mod_security .

Je l'ai essayé récemment sur certains de mes serveurs, non seulement il effectue des ajustements de configuration à Apache lui-même, comme le changement de numéro de version, etc., mais il agit également comme un pare-feu d'application Web aidant à se protéger contre une grande variété d'attaques telles que SQL. injection etc.

4
Mark Davidson

Comment sécuriser le serveur Web Apache

À quelle réponse vous attendriez-vous si vous demandiez "Comment piloter un jumb-jet" ou "Comment faire une chirurgie cérébrale" - il en va de même pour sécuriser un serveur Web - vous devez faire des milliers d'heures de formation, de pratique et de recherche . Mais comme tout le monde doit commencer quelque part ...

Il y a beaucoup de listes de contrôle de base sur Internet pour savoir comment durcir un serveur - mais selon mon commentaire ailleurs, elles varient considérablement en qualité.

Je recommanderais le sans un comme une bonne source.

Une fois que vous avez suivi la liste de contrôle, vous devez établir les moyens par lesquels vous pouvez

  • vérifier l'intégrité de votre serveur (vous avez certainement besoin d'un IDS basé sur l'hôte tel que tripwire avec un détecteur de rootkit)
  • connaître et appliquer des correctifs
  • récupérer votre système dans un bon état connu

Ne planifiez pas la façon dont vous traitez un incident de sécurité si cela se produit. Prévoyez quoi faire quand cela se produit.

Après avoir installé et configuré votre système, remplacez le disque dur et voyez combien de temps il vous faut pour que le service soit à nouveau opérationnel sans utiliser le disque d'origine.

2
symcbean

ce n'est pas seulement lié à Apache (et compte également pour nginx + php-fpm), mais souvent oublié: php-eastereggs, qui pourrait être désactivé via php.ini

  expose_php = off

ce n'est pas aussi terrible que de laisser un phpinfo.php derrière, mais c'est généralement un indice d'une administration système très paresseuse.

voir oeufs de pâques

1
that guy from over there

Bon fil tourné. Beaucoup de gens disent la vérité.

Ils en ont oublié un, OpenBSD façon:

Dans OpenBSD, le serveur Apache httpd (8) a été chroot (2) ed par défaut

httpd (v.1 d'Apache) inclus dans OpenBSD par défaut, et chrooté par défaut.

Vous pouvez le répéter facilement avec Apache2 ou nginx sur tout autre système d'exploitation de type Unix.

0
user29424

Utilisez la dernière version d'Apache, corrigez votre système d'exploitation ainsi que des tiers comme openssl ou tout autre.

Bloquer les ports indésirables.

Cela vous protégera de certaines vulnérabilités connues, mais vous serez toujours sensible à un 0-day, bien sûr.

0
Novice User

Voici 6 étapes clés:

  1. Sécurisez votre code d'application
  2. désactiver tous les modules non utilisés. Essayez de tout désactiver, puis, un par un, ajoutez des modules.
  3. supprimez tous les scripts et fichiers de sauvegarde du dossier Web.
  4. désactiver la liste des répertoires
  5. utilisez modsecurity pour protéger votre application contre les attaques au niveau de l'application.
  6. Utilisez Fail2ban pour déclencher des erreurs HTTP (403, 404).

Ne vous fiez pas au pare-feu de votre réseau, c'est inutile quand on parle de sécurité Web.

0
Mike