Dies ist eine kanonische Frage zum Sichern eines LAMP-Stapels

Was sind die absoluten Richtlinien zum Sichern eines LAMP-Servers?

Davids Antwort ist eine gute Grundlage für die allgemeinen Prinzipien des Server-Hardening. Wie David angedeutet hat, ist dies eine große Frage. Die spezifischen Techniken, die Sie anwenden, können stark von Ihrer Umgebung und der Verwendung Ihres Servers abhängen. Achtung, es kann eine Menge Arbeit in einer Testumgebung erfordern, bis alles richtig aufgebaut und erledigt ist. Es folgt viel Arbeit, um sich in Ihre Produktionsumgebung und vor allem in Ihre Geschäftsprozesse zu integrieren.

Überprüfen Sie jedoch zunächst, ob Ihre Organisation über Richtlinien zur Absicherung verfügt, da diese möglicherweise am unmittelbarsten relevant sind. Wenn dies nicht der Fall ist, ist dies abhängig von Ihrer Rolle möglicherweise ein guter Zeitpunkt, um sie auszubauen. Ich würde auch empfehlen, jede Komponente einzeln von unten nach oben anzugehen.

Das L
Es gibt viele gute Führer, die Ihnen helfen. Diese Liste kann Ihnen je nach Distribution helfen oder auch nicht.

• Center for Internet Security Benchmarks - Distribution speziell für die wichtigsten Geschmacksrichtungen
• CentOS Hardening HowTo - Entspricht dem CIS RHEL5-Handbuch, ist aber viel einfacher zu lesen
• NIST SP800-123 - Leitfaden zur allgemeinen Serversicherheit
• NSA Hardening Factsheets - Nicht so aktuell wie CIS, aber immer noch meistens anwendbar
• Tiger - Live Systemsicherheits-Überwachungssoftware

Der A
Apache kann spaßig zu sichern sein. Ich finde es einfacher, das Betriebssystem zu härten und die Benutzerfreundlichkeit beizubehalten, als entweder Apache oder PHP.

• Apache Server Hardening - Diese Frage auf der IT Security-Schwestersite enthält viele gute Informationen.
• Zentrum für Internet-Sicherheits-Benchmarks - Wieder Apache-Benchmarks.
• Apache-Sicherheitstipps - Direkt aus dem Apache-Projekt heraus werden anscheinend die Grundlagen behandelt
• DISA Hardening Checklist - Checkliste der DoD Information Assurance-Mitarbeiter

Sie

• Zentrum für Internet-Sicherheits-Benchmarks - Wieder, aber für MySQL-Benchmarks
• OWASP MySQL Hardening
• Allgemeine Sicherheitsrichtlinien - Grundlegende Checkliste der Projektentwickler

Das P
Dies führt zu der ganzen Idee von Secure Programming Practices, die eine eigene Disziplin darstellt. SANS und OWASP haben eine Menge lächerlicher Informationen zu diesem Thema, deshalb werde ich hier nicht versuchen, sie zu replizieren. Ich werde mich auf die Laufzeitkonfiguration konzentrieren und Ihren Entwicklern den Rest überlassen. Manchmal bezieht sich das 'P' in LAMP auf Perl, aber normalerweise auf PHP. Ich gehe von letzterem aus.

• Härten von PHP - Einige kleinere Diskussionen, auch auf der IT Security SE-Site.
• Gehärtetes PHP-Projekt - Hauptprojekt, das Suhosin produziert , ein Versuch, die PHP-Anwendung so zu patchen , dass sie gegen bestimmte Arten von Angriffen projiziert.
• PHP mit Suhosin härten - Ein kurzes HowTo speziell für Suhosin
• PHP aus der php.ini härten - Kurze, aber nicht schlechte Diskussion über einige der sicherheitsrelevanten Laufzeitoptionen

Sie haben eine Frage gestellt, die ein paar Bücher zu diesem Thema verdient. Es gibt jedoch einige allgemeine Grundregeln, die gut funktionieren:

1. Neuesten Stand zu halten. Dies bedeutet das Betriebssystem, alle Dienste und INSBESONDERE alle Webanwendungen, die Sie ausführen.
2. Deaktivieren Sie nicht benötigte Dienste, beschränken Sie die erforderlichen Dienste auf das Mindestmaß (wenn Sie keine Remoteverbindung zu MySQL herstellen und kein TCP abhören möchten), und führen Sie eine hostbasierte Firewall aus. (Wenn es sich ausschließlich um LAMP handelt, sollten Sie mit 80 und 443 gut umgehen können, aber vielleicht auch mit SSH.)
3. Verwenden Sie sichere Passwörter. Besser noch, wenn Sie SSH verwenden, verwenden Sie nur schlüsselbasierte Authentifizierung.
4. Stellen Sie sicher, dass Sie sich nicht als root anmelden. Melden Sie sich als Benutzer an und verwenden Sie su & sudo.
5. Obwohl dies die Sicherheit nicht erhöht, sollten Sie Tools wie logwatch ausführen, damit Sie wissen, was auf Ihrem Server geschieht.

Hoffe das hilft dir beim Einstieg.

Hier ist eine gute Checkliste, mit der ich gerne anfange.

Firewall

• Ein guter Ansatz ist, zunächst keinen Datenverkehr zuzulassen und dann nur das zu öffnen, was Sie benötigen , wie Sie es benötigen. Dies führt dazu, dass die minimalen Ports / IPs geöffnet werden, damit die Dinge funktionieren, und dies minimiert Ihre Exposition.
• Für einen LAMP-Server müssen Sie möglicherweise nur Ports für http / https zur Welt und ssh für sysadmins öffnen.
• Stellen Sie sicher, dass IPv6-Datenverkehr gesperrt ist, wenn Sie ihn nicht verwenden
• AWS bietet Sicherheitsgruppen, Linux hat Iptables sowie viele Pakete zur Auswahl.

SSH & Benutzer

• Kein Passwort für den SSH-Zugang (privaten Schlüssel verwenden)
• Erlaube root nicht ssh (die entsprechenden Benutzer sollten ssh in, dann su oder sudo)
• Verwenden Sie sudo für Benutzer, damit Befehle protokolliert werden
• Protokollieren Sie nicht autorisierte Anmeldeversuche (und erwägen Sie, dass Software Benutzer blockiert / sperrt, die zu oft versuchen, auf Ihren Server zuzugreifen, z. B. fail2ban).
• ssh auf einem nicht standardmäßigen Port (dies kann nützlich sein, um sicherzustellen, dass Sie nicht zu wenig hängendes Obst haben und einen Großteil des lästigen Datenverkehrs fernhalten, aber nicht viel für die Sicherheit tun, insbesondere nicht für sich selbst)
• sperren Sie ssh nur auf den von Ihnen gewünschten IP-Bereich (ein großer Bereich ist besser als kein Bereich)

Datenbank

• Benutzerdaten bereinigen
• Abfragen parametrisieren
• Ziehen Sie in Betracht, die Datenbank auf ihren eigenen Computer zu abstrahieren. Diese Trennung kann es einem Angreifer erschweren, zu Ihrem Webstapel zu gelangen und umgekehrt.
• Wie bei jeder Software ist es wichtig , immer auf dem neuesten Stand zu sein .
• Ein Benutzer für jeden Zweck . Beginnen Sie beim Erstellen von Benutzern mit keinen Berechtigungen und fügen Sie nur die hinzu, die Sie zum Ausführen ihrer Rolle benötigen. Wenn für verschiedene Anwendungen (oder manchmal auch für bestimmte Teile von Anwendungen) separate Benutzer vorhanden sind, verringert sich der Nutzen, den ein Angreifer hat, wenn er ein Konto gefährdet. Seien Sie auch vorsichtig mit Sonderrechten wie GRANT, die nicht leichtfertig vergeben werden sollten.
• Eine Richtlinie zum regelmäßigen Ändern von Kennwörtern ist eine gute Idee. Wenn Sie sich Sorgen über den Aufwand machen, denken Sie daran, dass weniger häufig besser ist als nie.
• Grundlegendes zur Kennwortverschlüsselung. Salt-Passwörter . Benutze md5 nicht!

Software

• Halten Sie die Software auf dem neuesten Stand (Betriebssystem, Webserver, Skriptsprache, CMS). Viele Leute da draußen werden nach bekannten Schwachstellen in alten (ungepatchten) Versionen suchen
• Entfernen Sie jegliche Software, die Sie nicht benötigen (im Idealfall müssen Sie das Paket nicht aufbewahren, um Software auf Produktionsservern zu kompilieren. Es ist besser, die Software vorkompilieren und als Paket für Ihre Produktionsmaschinen verfügbar zu machen.)
• Vergewissern Sie sich, dass die Dateiberechtigungen gesperrt sind (insbesondere für Benutzer-Uploads und Konfigurationsdateien).
• Kennwortgeschützter Administrationsbereich für CMS auf Webserverebene ( HTTP-Authentifizierung kann vor einem anfälligen CMS sitzen und den Zugriff blockieren, um Angriffe zu verhindern)
• Verwenden Sie SSL für Administrationsbereiche und andere vertrauliche Daten
• Automatisieren Sie die Verwaltung Ihrer Server und Infrastruktur (wie Puppet, Chef oder SaltStack. Wenn Sie auch AWS CloudFormation verwenden). Auf diese Weise können Sie Patches auf vielen Servern ausführen und Szenarien wie das Beheben von Berechtigungen auf Server A reduzieren, ohne dies jedoch auf Server B zu tun
• Geben Sie nach Möglichkeit nicht die jeweilige Version Ihres CMS, PHP oder WebServers preis. Diese Informationen zu verbergen ist zwar keine Sicherheit, aber es gibt viele Leute, die nach bestimmten Versionen verschiedener Software suchen. Je weniger Informationen Sie frei preisgeben, desto mehr muss ein Angreifer arbeiten. Dies ist ein guter Weg, um sicherzustellen, dass Sie nicht zu den niedrig hängenden Früchten gehören. Natürlich hat dies nichts mit jemandem zu tun, der sich ein bisschen mehr Mühe geben möchte
• Begrenzen Sie die Personen, die Zugriff auf den Server haben

Je modularer Ihre Installation ist, desto sicherer ist Ihr LAMP-Stack, wenn Sie beispielsweise einen Apache-Benutzer haben für Apache-Dateien / -Ordner mit entsprechend festgelegten Berechtigungen und nicht in Gruppen, die auf wichtige Systemdateien / -ordner zugreifen können. Ein Benutzer, der auf die MySql-Tabellen zugreifen kann, die Ihren zu versorgenden Websites zugeordnet sind, und nur auf diese Tabellen. Darüber hinaus können Sie deren Zugriff einschränken, um die Mindestzugriffsmenge für einen PHP-Aufruf festzulegen. Stellen Sie außerdem sicher, dass der in der PHP-Datei verwendete / offen gelegte MySQL-Benutzername nicht mit dem Benutzernamen oder Kennwort eines anderen Benutzers übereinstimmt.

Was dies bedeutet: Wenn entweder der Apache-Benutzer oder der MySQL-Benutzer kompromittiert werden, können sie keinen Schaden anrichten, der außerhalb des Bereichs der Ordner liegt, auf die Apache Zugriff hat (im Fall des Apache-Benutzers) und außerhalb der Tabelle ( s) / database (s) (im Fall des Benutzers für die MySQL-Datenbank).

Wenn der MySQL-Benutzer auf irgendeine Weise gefährdet wäre, könnte er beispielsweise nicht auf die Datenbank zugreifen und alle Datenbanken von MySQL löschen und alle Ihre Daten ruinieren. Sie KÖNNTEN unter Umständen in der Lage sein, Tabellen zu löschen oder Informationen in einige Tabellen in einer isolierten Datenbank einzufügen. Aus diesem Grund ist es wichtig, Tabellenzugriff nur dort zu gewähren, wo dies unbedingt erforderlich ist, und nur dann, wenn Sie die erforderlichen Berechtigungen erteilen. Sie müssen keine Rechte zum Löschen von Tabellen oder zum Aktualisieren von Tabellen haben und dürfen diese nicht an diesen Benutzer vergeben.

Wenn aus irgendeinem Grund der Benutzername und das Kennwort Ihres Administratorkontos für MySQL ermittelt werden und Sie einen anderen Benutzernamen als die Benutzernamen auf Ihrem System verwenden, müssen Sie zuerst die Sicherheit Ihres Systems unterbrechen, bevor Sie in Ihre Datenbank gelangen, um Schäden zu verursachen. Gleiches gilt für den Apache-Benutzer und den Zugriff auf Dateien.

Beispiel Zeit! Ich werde ein Systembeispiel geben, um die Idee zu vereinfachen.

Angenommen, Sie haben Benutzer auf Ihrem System (root sollte aus Sicherheitsgründen durch etwas wie umod -l oder passwd -l usw. deaktiviert sein): john, barney, terence und lisa.

Sie können in MySQL einen Benutzer mit dem Namen bigbird erstellen (stellen Sie sicher, dass Sie ein Hash-Passwort verwenden). Bigbird hat nur Auswahl- und Aktualisierungsrechte, aber keine Drop- oder Create-Rechte und schon gar nicht . Außerdem erstellen Sie einen weiteren administrativen MySQL-Benutzer mit dem Namen garfield für die Arbeit an der MySQL-Datenbank und löschen den Root-Benutzer aus der MySQL-Datenbank, damit er nicht kompromittiert werden kann. Garfield wurde gewährt . Privilegien in MySQL (effektiv ist dies nur das Umbenennen von root).

Jetzt erstellen Sie entweder eine Apache-Gruppe oder einen Benutzer und wir nennen es apweb2. Appweb2 ist kein Mitglied einer anderen Gruppe und alle Dateien / Ordner für Apache sind in / home / apweb2 / gespeichert. Jeder virtuelle Host verfügt über einen eigenen Unterordner, und für jeden dieser Hosts ist der Dokumentenstamm auf diesen Unterordner festgelegt. Symlinks würden deaktiviert, um nicht versehentlich Zugriff auf den Rest des Systems zu gewähren.

Sie können den SSH-Zugriff auch nur auf bestimmte Benutzer beschränken (oder auf bestimmte Gruppen, ich möchte sie in die SSH-Gruppe aufnehmen, damit nur diese SSH verwenden können).

Sie können auch auswählen, welche Benutzer über Sudo-Berechtigungen verfügen, um die Aktivitäten weiter einzuschränken. Ein weiterer Schritt, den Sie noch weiter ausführen können, besteht darin, alle SSH-Benutzer dazu zu bringen, nicht sudo-fähig zu sein. Sie könnten spezielle Benutzer erstellen, die sudo verwenden können, ohne ssh zu verwenden Zugriff auf sudo.

Wenn Sie also jedes Segment modularisieren, wird der gesamte Stapel nicht beeinträchtigt, und Sie können das Problem 1 beheben, anstatt von vorne beginnen zu müssen.

Ich fand dieses Dokument von SANS.org wirklich hilfreich http://www.sans.org/score/checklists/linuxchecklist.pdf

Vernachlässigen Sie derzeit nicht die Containervirtualisierung, dh Docker, systemd-nspawn und die Mechanismen der Containervirtualisierung, auf denen sie basieren (Namespaces, Cgroups). Mithilfe der Containervirtualisierung können Sie Prozesse isolieren. Wenn beispielsweise einer der Dienste gefährdet ist, kann ein Angreifer nicht auf andere Dienste zugreifen.

Im Falle von LAMP können beispielsweise vier Docker-Container mit SSH-Server, Apache, MySQL, PHP-FPM / Python / Perl / etc verwendet werden.