it-swarm-eu.dev

Best Practices für das Härten von Apache Server?

Welche Best Practices, Empfehlungen und erforderlichen Informationen sind zum Sichern eines Apache-Servers erforderlich?

104
Eric Warriner

Lesen Sie das CIS-Handbuch (Center for Internet Security) zum Sichern von Apache (es beschreibt ausführlich, wie Sie die Sicherheit verbessern können):

Bearbeiten: Link aktualisiert CIS Apache HTTP Server 2.2.x Benchmark

Wenn Sie eine Lizenz für Nessus haben, können Sie eine automatische Überprüfung durchführen, indem Sie die Prüfvorlage abrufen:

alt text

31
Tate Hansen
  • Verwenden Sie SSH-Schlüssel-basierte Anmeldungen
  • Sichern Sie MySQL
  • Deaktivieren Sie phpMyAdmin, webmin usw.
  • Schließen Sie alle Ports/Prozesse, die nicht benötigt werden
  • Verwenden Sie eine Dateiintegritätsprüfung
  • Verwenden Sie mod_security
  • Legen Sie die richtigen Berechtigungen/Gruppen fest

Dies ist eine gute Anleitung:
https://serverfault.com/questions/212269/tips-for-securing-a-lamp-server

Grundlegende Anleitung zum Härten: http://www.wpsecure.net/server-guide/

Wenn Sie php ausführen: http://www.madirish.net/?article=229

Suchen Sie im Apache-Protokoll nach 404 (oder anderen Statuscodes)
awk '$9 == 404 {print $7}' access_log | uniq -c | sort -rn | head

12
Wyck

Die ursprünglich hoch bewertete Antwort auf diese Frage, die akzeptiert wurde, wurde gelöscht, da es sich um ein direktes Plagiat von 20 Möglichkeiten zum Sichern Ihrer Apache-Konfiguration handelte. Diese Seite ist eine fantastische Ressource.

@RoryMcCune hat dies auch als Link zu dieser Antwort gepostet: Es gibt ein OWASP-Projekt zum Entwickeln eines ModSecurity Core Rule Set hier , das von Nutzen sein könnte.

7
Jeff Ferland

Hier gibt es viele gute Ratschläge, daher werde ich die bereits erwähnten Dinge nicht wiederholen. Aber was ich sagen werde ist:

Vergessen Sie nicht, die Standardfehlerseiten durch Dinge zu ersetzen, die Ihre Webserver-Version oder Kernel-Revision nicht preisgeben. Ich neige dazu, jedes Standard-HTML durch 1 Liner zu ersetzen, die so etwas wie "Fehler 400" sind. Es gibt sehr wenig über das System weg. Dieses Prinzip gilt für alle Webserver, die benutzerdefinierte Fehlerseiten anzeigen können. Alle geben standardmäßig viel zu viele Informationen weiter, als erforderlich sind. Sie würden denken, dass ServerSignature dies verbergen würde, aber in vielen Fällen nicht.

Vergessen Sie auch nicht, den gesamten Standard-HTML-Inhalt (sprachspezifisch usw.) zu löschen, damit Fingerabdrücke umso schwieriger werden.

Was gute Lektüre angeht, gab es ein Whitepaper von Apcon 2008 das ist eine Lektüre wert.

Mod_Security wird einige Male erwähnt, dies ist besser für Webanwendungen geeignet. Wenn Sie also nur statischen Inhalt bereitstellen, hilft es Ihnen auch nicht viel, obwohl es einige Angriffe gibt, gegen die es sich bei der Bearbeitung von Anforderungen wehren kann, die einen statischen Webserver betreffen könnten.

Die andere Sache, die ich erwähnen möchte, ist eine gute Protokollverwaltung. Wenn Sie Ihre Protokolle nicht abbauen und das System im Auge behalten, besteht die Gefahr, dass ein Angreifer darauf stößt, ohne sich dessen bewusst zu sein.

6
Ori

Es gelten alle allgemeinen Sicherheitsprinzipien: Führen Sie nur Module aus, die Sie benötigen, deaktivieren Sie nicht benötigte Funktionen, bereinigen Sie Ihre Berechtigungen/Eigentümer (die meisten Inhalte sind schreibgeschützt. Warum benötigen die Dateien also mehr als 400 Dauerwellen?).

Die Dinge, die für Apache besonders sind, wie CGI-Jobs oder verschiedene vhosts, die denselben Inhalt zweimal mit zwei verschiedenen Sicherheitsmechanismen bereitstellen, sind viel schwieriger zu erkennen. Dies ist keine automatische Überprüfung. Sie müssen Apache, das zugrunde liegende Betriebssystem und die Funktionen der in Apache ausgeführten Anwendungen kennen.

Der Vollständigkeit halber hier eine Apache 2.2-Sicherheitscheckliste von DISA. UPDATE: Hier ist ein Link zu ihrer gesamte Sammlung von Webserver-Härtungsdokumenten.

6
Marcin

Es könnte sich lohnen, Apache mod_security einen Blick darauf zu werfen.

Ich habe es in letzter Zeit auf einigen meiner Server ausprobiert. Es führt nicht nur einige Konfigurationsänderungen an Apache selbst durch, z. B. das Ändern der Versionsnummer usw., sondern fungiert auch als Firewall für Webanwendungen, die zum Schutz vor einer Vielzahl von Angriffen wie SQL beiträgt Injektion usw.

4
Mark Davidson

Wie sichere ich den Apache-Webserver?

Welche Antwort würden Sie erwarten, wenn Sie fragen würden: "Wie fliege ich einen Jumbjet?" Oder "Wie mache ich eine Gehirnoperation?". Gleiches gilt für die Sicherheit eines Webservers. Sie müssen 1000 Stunden Training, Übung und Forschung durchführen . Aber da muss jeder irgendwo anfangen ...

Es gibt viele grundlegende Checklisten im Internet, wie man einen Server härtet - aber gemäß meinem Kommentar an anderer Stelle unterscheiden sie sich stark in der Qualität.

Ich würde die ohne als gute Quelle empfehlen.

Sobald Sie der Checkliste gefolgt sind, müssen Sie Mittel festlegen, mit denen Sie können

  • überprüfen Sie die Integrität Ihres Servers (Sie benötigen auf jeden Fall ein Host-basiertes IDS wie Tripwire zusammen mit einem Rootkit-Detektor).
  • patches beachten und anwenden
  • stellen Sie Ihr System in einem bekanntermaßen guten Zustand wieder her

Planen Sie nicht, wie Sie mit einem Sicherheitsvorfall umgehen , wenn dies passiert. Planen Sie, was zu tun ist , wenn es passiert.

Nachdem Sie Ihr System eingerichtet und konfiguriert haben, tauschen Sie die Festplatte aus und sehen Sie, wie lange Sie brauchen, um den Dienst wieder in Betrieb zu nehmen, ohne die Originalfestplatte zu verwenden.

2
symcbean

dies ist nicht nur Apache-bezogen (und zählt auch für nginx + php-fpm), sondern wird oft vergessen: php-eastereggs, die möglicherweise über php.ini ausgeschaltet werden

  expose_php = off

es ist nicht so schrecklich wie das Zurücklassen einer phpinfo.php, aber normalerweise ein Hinweis auf eine sehr faule Systemadministration.

siehe Ostereier

Guter Faden gedreht. Viele Leute sagen die Wahrheit.

Sie haben einen vergessen, OpenBSD 's Weg:

In OpenBSD wurde der Apache httpd (8) -Server standardmäßig chroot (2) bearbeitet

httpd (v.1 von Apache) ist standardmäßig in OpenBSD enthalten und standardmäßig chrootiert.

Sie können es einfach mit Apache2 oder nginx auf jedem anderen Unix-ähnlichen Betriebssystem wiederholen.

0
user29424

Verwenden Sie die neueste Version von Apache, patchen Sie Ihr Betriebssystem und auch von Drittanbietern wie openssl oder anderen.

Blockieren Sie unerwünschte Ports.

Dies schützt Sie vor einigen bekannten Sicherheitslücken, aber Sie sind natürlich immer für einen 0-Tage-Tag anfällig.

0
Novice User

Hier 6 wichtige Schritte:

  1. Sichern Sie Ihren Anwendungscode
  2. deaktivieren Sie alle nicht verwendeten Module. Versuchen Sie, alle zu deaktivieren, und fügen Sie dann nacheinander Module hinzu.
  3. entfernen Sie alle Skripte und Sicherungsdateien im Webordner.
  4. verzeichnisliste deaktivieren
  5. verwenden Sie modsecurity, um Ihre Anwendung vor Angriffen auf Anwendungsebene zu schützen.
  6. Verwenden Sie Fail2ban, um HTTP-Fehler auszulösen (403, 404).

Verlassen Sie sich nicht auf Ihre Netzwerk-Firewall, sie ist nutzlos, wenn es um Web-Sicherheit geht.

0
Mike