it-swarm.com.de

Tipps zum Sichern eines LAMP-Servers

Dies ist ein Canonical Question zum Sichern eines LAMP-Stacks

Was sind die absoluten Richtlinien für die Sicherung eines LAMP-Servers?

96
Aditya Shukla

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, dies kann in einer Testumgebung viel Arbeit erfordern, um richtig aufzubauen und zu erledigen. Gefolgt von viel Arbeit zur Integration in Ihre Produktionsumgebung und vor allem in Geschäftsprozesse.

Überprüfen Sie jedoch zunächst, ob in Ihrem Unternehmen Absicherungsrichtlinien vorhanden sind, da diese möglicherweise am unmittelbarsten relevant sind. Wenn nicht, kann dies abhängig von Ihrer Rolle ein guter Zeitpunkt sein, um sie auszubauen. Ich würde auch empfehlen, jede Komponente separat von unten nach oben anzugehen.

Das L
Es gibt viele gute Anleitungen, die Ihnen helfen können. Diese Liste kann Ihnen je nach Distribution helfen oder auch nicht.

Das A
Es kann Spaß machen, Apache zu sichern. Ich finde es einfacher, das Betriebssystem zu härten und die Benutzerfreundlichkeit aufrechtzuerhalten als Apache oder PHP.

Das M

Das P
Dies führt direkt zu der ganzen Idee der sicheren Programmierpraktiken, die eine ganze eigene Disziplin darstellt. SANS und OWASP haben eine lächerliche Menge an Informationen zu diesem Thema, daher werde ich nicht versuchen, sie hier zu replizieren. Ich werde mich auf die Laufzeitkonfiguration konzentrieren und Ihre Entwickler sich um den Rest kümmern lassen. Manchmal bezieht sich das 'P' in LAMP auf Perl, aber normalerweise auf PHP. Ich gehe von letzterem aus.

108
Scott Pack

Sie haben eine Frage gestellt, die ehrlich gesagt ein paar Bücher zu diesem Thema verdient. Es gibt jedoch einige allgemeine Grundrichtlinien, 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 auf das Minimum (wenn Sie keine Remoteverbindung zu MySQL herstellen, lassen Sie TCP nicht abhören) und führen Sie eine hostbasierte Firewall aus. (Wenn es sich ausschließlich um LAMP handelt, sollten Sie gut mit 80 und 443 umgehen können, aber möglicherweise auch mit SSH für die Verwaltung.))
  3. Verwenden Sie sichere Passwörter. Besser noch, wenn Sie SSH verwenden, verwenden Sie nur die 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 passiert.

Ich hoffe, das hilft Ihnen beim Einstieg.

14
David

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

Firewall

  • Ein guter Ansatz ist es, 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 für die Welt und ssh für Sysadmins öffnen.
  • Stellen Sie sicher, dass Dinge wie IPv6-Verkehr gesperrt sind, wenn Sie ihn nicht verwenden
  • AWS bietet Sicherheitsgruppen, Linux verfügt über iptables sowie zahlreiche Pakete zur Auswahl.

SSH & Benutzer

  • kein Passwort für den SSH-Zugriff (privaten Schlüssel verwenden)
  • Erlaube root nicht, ssh (die entsprechenden Benutzer sollten ssh, dann su oder Sudo)
  • Verwenden Sie Sudo für Benutzer, damit Befehle protokolliert werden
  • Protokollieren Sie nicht autorisierte Anmeldeversuche (und ziehen Sie Software in Betracht, um Benutzer zu blockieren/zu sperren, 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 keine niedrig hängenden Früchte haben und viel lästigen Verkehr fernhalten, aber nicht viel für die Sicherheit tun, insbesondere nicht für sich allein)
  • sperren Sie ssh nur auf den IP-Bereich, den Sie benötigen (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 für einen Angreifer schwieriger machen, zu Ihrem Webstack zu gelangen und umgekehrt.
  • Wie bei jeder Software auf dem Laufenden bleiben ist wichtig.
  • Ein Benutzer für jeden Zweck. Beginnen Sie beim Erstellen von Benutzern ohne Berechtigungen und fügen Sie nur diejenigen hinzu, die sie zum Ausführen ihrer Rolle benötigen. Wenn Sie separate Benutzer für verschiedene Anwendungen (oder manchmal unterschiedliche Teile von Anwendungen) haben, können Sie den Nutzen eines Angreifers verringern, wenn er ein Konto gefährdet. Seien Sie auch vorsichtig mit speziellen Privilegien 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 erforderlichen Aufwand machen, denken Sie daran, dass weniger häufig besser ist als nie.
  • Kennwortverschlüsselung verstehen. Salt Passwörter. Verwenden Sie nicht md5!

Software

  • Software auf dem neuesten Stand halten (Betriebssystem, Webserver, Skriptsprache, CMS). Viele Leute da draußen werden in alten (nicht gepatchten) Versionen nach bekannten Schwachstellen suchen
  • Entfernen Sie nicht benötigte Software (im Idealfall sollten Sie das zum Kompilieren von Software auf Produktionsservern erforderliche Paket nicht aufbewahren. Es ist besser, Software vorkompilieren und als Paket für Ihre Produktionsmaschinen verfügbar zu machen).
  • Stellen Sie sicher, dass Datei Berechtigungen sind gesperrt (insbesondere für Benutzer-Uploads und Konfigurationsdateien)
  • Kennwortschutz-Administratorbereich für CMS auf Webserverebene (http-Authentifizierung kann vor einem anfälligen CMS sitzen und den Zugriff blockieren, was ein guter Weg ist, um Angriffe zu verhindern)
  • Verwenden Sie SSL für Administrationsbereiche und andere vertrauliche Daten
  • Automatisieren Sie die Verwaltung Ihrer Server und Infrastruktur (z. B. Puppet, Chef oder SaltStack. Wenn Sie auch AWS CloudFormation verwenden). Auf diese Weise können Sie Dinge auf vielen Servern patchen und Szenarien wie das Korrigieren von Berechtigungen auf Server A reduzieren, aber vergessen, dies auf Server B zu tun
  • Wenn möglich, geben Sie nicht die bestimmte Version Ihres CMS, PHP oder WebServer) preis. Obwohl das Verschleiern dieser Informationen keine Sicherheit darstellt, suchen viele Leute nach bestimmten Versionen verschiedener Software und der Je weniger Informationen Sie frei weitergeben müssen, 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 wird dies niemandem etwas antun, der sich etwas mehr Mühe geben möchte im
  • Beschränken Sie die Personen, die Zugriff auf den Server haben
9
Drew Khoury

Je modularer Ihre Installation ist, desto sicherer ist Ihr LAMP-Stack, je modularer Ihre Installation ist. Damit meine ich, den Zugriff auf bestimmte Benutzer/Gruppen zu beschränken, die speziell für eine Aufgabe erstellt wurden, und deren Umfang einzuschränken: Ein Beispiel hierfür ist ein Apache-Benutzer 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 Websites zugeordnet sind, die Sie bereitstellen möchten, und nur auf diese Tabellen. Darüber hinaus können Sie den Zugriff einschränken, um den Mindestzugriff von einem PHP -Aufruf) zu gewährleisten. Stellen Sie außerdem sicher, dass der verwendete MySQL-Benutzername über PHP) verfügbar gemacht wird = Datei ist nicht derselbe Benutzername oder das gleiche Passwort, die für einen anderen Benutzer verwendet wurden.

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

Wenn der MySQL-Benutzer irgendwie kompromittiert werden sollte, konnte er beispielsweise nicht auf die Datenbank zugreifen und alle Datenbanken aus MySQL löschen und alle Ihre Daten ruinieren. Unter bestimmten Umständen können sie möglicherweise Tabellen löschen oder Informationen in einige Tabellen in einer isolierten Datenbank einfügen. Daher ist es wichtig, Tabellenzugriff nur dort zu gewähren, wo dies unbedingt erforderlich ist, und nur die erforderlichen Berechtigungen zu erteilen ... wenn Sie dies nicht tun. Sie müssen keine Drop-Tables-Berechtigungen oder Update-Berechtigungen haben und geben diese dann nicht an diesen Benutzer weiter.

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

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

angenommen, Sie haben Benutzer auf Ihrem System (root sollte aus Sicherheitsgründen durch umod -l oder passwd -l usw. deaktiviert werden): john, barney, terence und Lisa.

sie können einen Benutzer in MySQL mit dem Namen bigbird erstellen (stellen Sie sicher, dass Sie ein Hash-Passwort verwenden). Bigbird verfügt nur über Auswahl- und Aktualisierungsberechtigungen, jedoch nicht über Löschen oder Erstellen und schon gar nicht über . 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, so dass es nicht komprimiert werden kann. garfield wurden . Berechtigungen in MySQL gewährt (effektiv wird nur root umbenannt).

jetzt erstellen Sie entweder eine Apache-Gruppe oder einen Benutzer und wir nennen es apweb2. Appweb2 ist kein Mitglied anderer Gruppen und alle Dateien/Ordner für Apache werden in/home/apweb2/gespeichert. Jeder virtuelle Host hätte einen eigenen Unterordner, und für jeden dieser Hosts wäre der Dokumentenstamm auf diesen Unterordner festgelegt. Symlinks werden deaktiviert, um nicht versehentlich den Zugriff auf den Rest des Systems zu ermöglichen.

Außerdem können Sie den SSH-Zugriff nur auf bestimmte Benutzer beschränken (oder auf bestimmte Gruppen, ich möchte sie in die SSH-Gruppe aufnehmen und dies zum einzigen Element machen, das SSH verwenden kann).

Sie können auch auswählen, welche Benutzer über Sudo-Berechtigungen verfügen, um die Dinge noch weiter einzuschränken. Ein weiterer Schritt, den Sie noch weiter ausführen können, besteht darin, ssh-Benutzer dazu zu bringen, Sudo nicht zu können. Sie können spezielle Benutzer erstellen, die Sudo verwenden können, die ssh nicht verwenden können. Sobald Sie sich bei ssh anmelden, müssen Sie sich bei einem anderen Benutzer anmelden Zugang zu Sudo.

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

5
86bornprgmr

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

3
wsindhu

Vernachlässigen Sie derzeit nicht die Containervirtualisierung, nämlich Docker, systemd-nspawn und die Mechanismen der Containervirtualisierung, auf denen sie basieren (Namespaces, cgroups). Durch die Verwendung der Containervirtualisierung können Sie Prozesse isolieren. Wenn beispielsweise einer der Dienste gefährdet ist, erhält ein Angreifer keinen Zugriff auf andere Dienste.

Bei LAMP können beispielsweise vier Docker-Container mit SSH-Server, Apache, MySQL, PHP-FPM/Python/Perl/etc. Verwendet werden.

1
Quarind