Antworten:
Beachten Sie zunächst, dass jede Skriptfähigkeit in Apache (PHP, CGI, Ruby, ...) das potenzielle Äquivalent eines Shell-Kontos mit den Rechten des Benutzers ist, der das Skript ausführt.
Wenn der Server für mehrere Benutzer freigegeben ist, sollten Sie über die Verwendung von suexec (oder ITK MPM - empfohlen von David Schmitt ) nachdenken, damit nicht jedes Skript als derselbe Apache-Benutzer ausgeführt wird.
Virtualisieren oder chroot-Apache, sodass jeder Kompromiss zumindest teilweise in einer zusätzlichen Sicherheitsebene enthalten ist. Beachten Sie, dass die Wartung von Chroot-Apache schwieriger werden kann, wenn Sie Bibliotheken in das Jail verschieben. Wenn Sie unter FreeBSD arbeiten, können Sie stattdessen ein Jail verwenden, das viel einfacher zu warten ist, da Sie Apache einfach installieren können von Ports aus und führen Sie portaudit von dort aus aus aus, ohne sich um Bibliotheksabhängigkeiten und das manuelle Verschieben von Dateien kümmern zu müssen, was immer zu einem hässlichen Durcheinander wird. Mit BSD-Jails können Sie einfach das Paketverwaltungssystem (Ports) weiterverwenden. (Unter GNU / Linux können Sie auch VServer für die Virtualisierung verwenden. - Vorgeschlagen von David Schmitt )
(offensichtlich) Halten Sie sich über Updates und Patches auf dem Laufenden, nicht nur für Apache, sondern auch für PHP, Ruby, Perl usw. Vertrauen Sie nicht nur Ihrem Betriebssystem, um Ihnen alle Updates zukommen zu lassen. Einige Distributionen sind mit ihren Patches extrem langsam. Begrenzen Sie die Expositionszeit so weit wie möglich auf Schwachstellen von 0 Tagen. Stecken Sie den milw0rm- Feed in Ihren RSS-Reader, abonnieren Sie die Mailinglisten von insecure.org usw. Sie erfahren nicht nur mehr über Sicherheitslücken, bevor Ihr Betriebssystem einen Patch veröffentlicht, sondern auch über Sicherheitslücken in bestimmten PHP-Umgebungen Zum Beispiel CMS-Anwendungen, die möglicherweise nicht einmal von Ihrem Betriebssystem verwaltet oder gepatcht werden.
Verwenden Sie beispielsweise tripwire / aide, audit oder mtree (unter BSD), um Änderungen in Ihrem Dateisystem zu verfolgen. Dieser ist wirklich wichtig. Lassen Sie sich regelmäßig Änderungen zusenden und überprüfen Sie diese täglich manuell. Wenn sich eine Datei ändert, die sich nicht ändern sollte, untersuchen Sie, warum. Wenn auf irgendeine Weise böswilliges Javascript in Ihre Seiten eingefügt wird, werden Sie es auf diese Weise abfangen. Dies schont nicht nur Ihren Server, sondern auch Ihre Benutzer, da Ihre eigenen Webseiten missbraucht werden können, um Ihre Besucher zu infizieren. (Dies ist eine sehr weit verbreitete Taktik. Die Angreifer kümmern sich oft nicht einmal um Ihren Server. Sie möchten nur so viele Besucher wie möglich infizieren, bis sie entdeckt werden. Diese Angreifer machen sich auch nicht die Mühe, ihre Spuren normalerweise zu verbergen.) Es ist sehr wichtig, so schnell wie möglich einen Kompromiss zu schließen.)
Mit Sachen wie Suhosin zum Schutz von PHP hilft. Aber lernen Sie auch, es zu verstehen. Passen Sie die Konfiguration an die erwarteten Parameter Ihrer Anwendung an.
Die Verwendung eines Kernel-Patches wie PaX kann Sie vor vielen Sicherheitslücken durch Pufferüberlauf schützen. Auch wenn Ihre Software anfällig ist. (Das macht dich nicht unverwundbar, es ist nur eine weitere, kleinere Ebene.)
Seien Sie nicht zu selbstsicher, wenn Sie ein Sicherheitstool verwenden. Verstehen Sie die Tools, die Sie verwenden, und verwenden Sie gesunden Menschenverstand. Lesen, lernen, so viel wie möglich mithalten.
Erwägen Sie die Verwendung einer obligatorischen Zugriffskontrolle (z . B. SELinux ). Sie können für jede Anwendung genau festlegen, was sie tun darf. Auf welche Dateien darf zugegriffen werden? Was der Kernel aufruft, darf er machen usw. Dies ist ein sehr komplizierter Prozess und erfordert viel Verständnis. Einige Distributionen bieten vorgefertigte SELinux-Richtlinien für ihre Pakete an (zB: Gentoo ). Dieser Vorschlag ist eine Art Widerspruch zu dem unten stehenden, aber dennoch gültig.
Halte die Dinge einfach. Eine komplexe Sicherheitsstrategie kann gegen Sie arbeiten.
Richten Sie in Apache sehr restriktive Standardregeln ein (Optionen Keine, Von allen ablehnen usw.) und überschreiben Sie diese nach Bedarf für bestimmte VirtualHosts.
Den Zugriff auf alle Punktedateien verweigern (die auch sofort die .htaccess-Dateien abdecken)
Verwenden Sie https immer überall dort, wo eine Kennwortauthentifizierung möglich ist.
Die Firewall sollte standardmäßig verweigert werden. Erstellen Sie bestimmte Regeln in Ihrer Firewall, um bestimmten Datenverkehr zu protokollieren.
Richten Sie Protokollanalyse-Skripts ein, um Ihre Protokolle auf Anomalien zu überprüfen. (Die Präludium-IDS- Suite kann dies, aber ehrlich gesagt, ich empfehle, dass Sie im Laufe der Zeit Ihre eigenen Skripte erstellen, da Sie so Ihre eigenen Tools und Regeln besser verstehen.)
Lassen Sie den Server täglich E-Mails über zuletzt angemeldete Benutzer, aktive Verbindungen, genutzte Bandbreite usw. senden.
Lassen Sie einen Cron-Scan nach geeigneten Binärdateien, Dateien, die von der Welt beschrieben werden können, und lassen Sie sich diese per E-Mail zusenden.
Für alles, was Sie eingerichtet haben und das Ihnen zugesandt wird, sollten Sie im Laufe der Zeit eine Liste mit Ausnahmen erstellen. (Ordner, für die Änderungen am Dateisystem ignoriert werden sollen, 777 Dateien, für die suid-Binärdateien). Es ist wichtig, dass Sie nur über Dinge informiert werden, die nicht passieren sollten. Wenn Sie jeden Tag eine E-Mail mit Kleinigkeiten erhalten, werden Sie diese ignorieren und sie werden sinnlos.
Haben Sie eine gute Strategie für redundante Backups mit mehreren Ebenen. Und nehmen Sie nicht einfach an, dass das Erstellen eines Bildes oder einer Kopie von allem funktioniert. Wenn MySQL beispielsweise gerade während der Sicherung in eine Tabelle schreibt, sind Ihre MySQL-Binärdateien möglicherweise beschädigt, wenn Sie Ihre Sicherung wiederherstellen. Sie benötigen also einen Cron, mit dem Sie Ihre Datenbanken mit mysqldump über normale Images, nächtliche Tarballs, Versionskontrolle oder was auch immer einrichten können. Denken Sie über Ihre Sicherungsstrategie nach. Ich meine, WIRKLICH darüber nachdenken.
Verlassen Sie sich aus Sicherheitsgründen nicht auf Listen wie diese :) Im Ernst! Sie finden viele davon über das Internet, lesen sie alle, recherchieren jeden Vorschlag und treffen mit gesundem Menschenverstand und Erfahrung Ihre eigenen Entscheidungen. Am Ende sind Erfahrung und gesunder Menschenverstand die einzigen Dinge, die Sie retten werden. Weder Listen noch Werkzeuge. Lesen Sie, aber kopieren Sie nicht, ohne es zu verstehen.
Ich empfehle die Linux-Sicherheits-Checkliste von SAN. Ich benutze das und ein weiteres internes Verfahren. Die Checkliste ist vielleicht etwas veraltet, aber viele der wichtigsten Punkte stimmen.
Es wird immer unzählige Berechtigungen zum Überprüfen geben, unzählige Checklisten, und die Entdeckung neuer Bugs / Schwachstellen wird niemals enden. Ich würde nicht denken, dass Sie die Sicherheit ein- oder ausschalten, sie tun Sie ständig.
In Anbetracht des "unvermeidlichen Ausfalls" von Software hilft SELinux dabei, einige Bedenken auszuräumen (auch diesmal kein Patentrezept für die Sicherheit). Unter der Annahme, dass eine Userspace-Anwendung gefährdet ist, verhindert die korrekte SELinux-Richtlinie, dass sie die üblichen Berechtigungen (z. B. wenn SELinux deaktiviert oder zulässig war) einhält. Dazu müssen Sie natürlich Ihre Überwachungsprotokolle überwachen, die installierten Richtlinien analysieren und bei Bedarf ändern, damit die Anwendungen funktionieren können.
Nicht zu sagen, dass eine Standardrichtlinie nicht helfen würde, aber ich persönlich würde gerne wissen, was sie erlaubt.