Frage Tipps zum Sichern eines LAMP-Servers


Das ist ein Kanonische Frage über das Sichern eines LAMP-Stapels

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


91
2017-12-14 01:52


Ursprung




Antworten:


Davids Antwort ist eine gute Grundlage für die allgemeinen Prinzipien der Serverhärtung. Wie David angedeutet hat, ist dies eine große Frage. Die spezifischen Techniken, die Sie treffen, können stark von Ihrer Umgebung und davon abhängen, wie Ihr Server verwendet wird. Achtung, dies kann in einer Testumgebung viel Arbeit erfordern, um richtig zu arbeiten. Gefolgt von einer Menge Arbeit, um in Ihre Produktionsumgebung und, was noch wichtiger ist, Geschäftsprozesse zu integrieren.

Überprüfen Sie jedoch zunächst, ob in Ihrer Organisation Richtlinien für die Verhärtung vorhanden sind, da diese am relevantesten sein könnten. Wenn nicht, je nach Ihrer Rolle, könnte dies eine gute Zeit sein, um sie aufzubauen. Ich würde auch empfehlen, jede Komponente separat von unten nach oben zu behandeln.

Die L
Es gibt viele gute Guides, die Ihnen helfen können. Diese Liste kann oder kann Ihnen nicht helfen, abhängig von Ihrer Distribution.

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

Sie

Die P
Dies führt schlagartig in die ganze Idee von Secure Programming Practices, die eine ganze Disziplin ist. SANS und OWASP haben eine lächerliche Menge an Informationen zu dem Thema, also werde ich nicht versuchen, es hier zu wiederholen. Ich werde mich auf die Laufzeitkonfiguration konzentrieren und Ihre Entwickler um den Rest kümmern. Manchmal bezieht sich das 'P' in LAMP auf Perl, aber normalerweise auf PHP. Ich nehme das letztere an.

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

105
2017-12-14 14:50



Ich möchte diese Antwort mindestens 10 Mal abstimmen. - user58859
Das unbeaufsichtigte N - Sperren Sie mit entweder IPTables oder einer externen Firewall Netzwerkverbindungen nur so, wie es für die Öffentlichkeit erforderlich ist. - Matt
Dies sollte ein Community-Wiki sein - Brian Adkins
Es ist so einfach, die Firewall zu vergessen. Ich habe von jemandem gehört, der einen Webserver für eine Website erstellt hat und ging sogar so weit, den TCP / IP-Stack zu hacken, um den Verkehr wegzuwerfen, der nicht Port 80 war. Eine andere Sache, die übersehen wird, sind unnötige Dienste - wenn sie nicht benötigt werden eingeschaltet sein, schalten Sie es aus. - Aaron Mason
@AaronMason: Herzlichen Glückwunsch! Sie haben eine erfolgreiche Anekdote. Erinnern wir uns, dass Ihre spezifische Situation gut funktioniert hat, aber hoffen Sie, dass zukünftige Leser Ihre ungewöhnliche Umgebung verstehen. Im allgemeinen Fall ist dieser Ratschlag ziemlich gefährlich. - Scott Pack


Sie haben eine Frage gestellt, die, ehrlich gesagt, einige Bücher zu diesem Thema verdient. Aber es gibt einige allgemeine grundlegende Richtlinien, die gut funktionieren:

  1. Neuesten Stand zu halten. Dies bedeutet das Betriebssystem, alle Dienste und BESONDERS alle Webapps, die Sie ausführen.
  2. Deaktivieren Sie nicht benötigte Dienste, beschränken Sie die für die minimale Belastung erforderlichen (wenn Sie keine Remoteverbindung zu MySQL herstellen, lassen Sie sie nicht auf TCP überwachen) und führen Sie eine Host-basierte Firewall aus. (Wenn es streng LAMP ist, sollten Sie gut mit 80 und 443 sein, aber vielleicht auch SSH für die Administration.))
  3. Verwenden Sie starke Kennwörter. Besser noch, wenn Sie SSH verwenden, verwenden Sie nur Schlüssel-basierte 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 es die Sicherheit nicht erhöht, sollten Sie Tools wie logwatch ausführen, damit Sie wissen, was auf Ihrem Server passiert.

Hoffnung, die dir hilft, anzufangen.


13
2017-12-14 02:23



Ich schlage vor, "Anleitung zur sicheren Konfiguration von Red Hat Enterprise Linux 5" von der NSA zu lesen - ALex_hha
Zu spät zur Party, aber ich habe kürzlich gelesen, dass "nicht einloggen als root" nicht mehr so ​​eine große Sache ist, besonders wenn Sie SSH-Authentifizierung basierend auf öffentlichen / privaten Schlüsseln verwenden. - the0ther


Hier ist eine gute Checkliste, mit der ich beginnen möchte.

Firewall

  • Ein guter Ansatz ist es, zu Beginn keinen Datenverkehr zuzulassen nur Öffne, was du brauchst, wie du es brauchst. Dies führt zum Öffnen der minimale Ports / ips, damit die Dinge funktionieren und das minimiert Ihre Exposition.
  • Für einen LAMP-Server müssen Sie möglicherweise nur Ports für öffnen http / https für die Welt und ssh für Systemadministratoren.
  • Stellen Sie sicher, dass Dinge wie IPv6-Verkehr gesperrt sind, wenn Sie sie nicht verwenden
  • AWS bietet Sicherheitsgruppen, Linux hat Iptables sowie viele Pakete zur Auswahl von.

SSH & Benutzer

  • Kein Passwort für SSH-Zugriff (privaten Schlüssel verwenden)
  • Lassen Sie root nicht auf ssh zu (die entsprechenden Benutzer sollten ssh in, dann su oder sudo)
  • Verwenden Sie sudo für Benutzer, damit Befehle protokolliert werden
  • Melden Sie nicht autorisierte Anmeldeversuche (und erwägen Sie Software, um Benutzer, die versuchen, zu oft auf Ihren Server zuzugreifen, wie fail2ban, zu blockieren / sperren)
  • ssh auf Nicht-Standard-Port (Dies kann nützlich sein, um sicherzustellen, dass Sie nicht tief hängende Frucht sind, und einen Großteil des lästigen Verkehrs fernhalten, aber nicht viel für die Sicherheit tun, besonders von selbst)
  • Sperren Sie ssh 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 DB auf ihre eigene Maschine zu übertragen. Diese Trennung kann es einem Angreifer erschweren, zu Ihrem Webstapel zu gelangen und umgekehrt.
  • Wie jede Software auf dem Laufenden gehalten werden ist wichtig.
  • Ein Benutzer für jeden Zweck. Beim Erstellen von Benutzern beginnen Sie mit keinen Privilegien und fügen nur diejenigen hinzu, die sie benötigen, um ihre Rolle zu erstellen. Wenn Sie separate Benutzer für verschiedene Anwendungen (oder manchmal auch für bestimmte Teile von Anwendungen) haben, können Sie den Vorteil eines Angreifers verringern, wenn er ein Konto gefährdet. Seien Sie auch vorsichtig mit speziellen Privilegien wie GRANT, die nicht leicht zugeordnet werden sollten.
  • Eine Richtlinie zum regelmäßigen Ändern von Kennwörtern ist eine gute Idee. Wenn Sie sich Sorgen um den Aufwand machen, denken Sie daran, dass weniger häufig besser ist als nie.
  • Verstehen Sie die Passwort-Verschlüsselung. Salz-Passwörter. Verwenden Sie nicht md5!

Software

  • Halten Sie die Software auf dem neuesten Stand (os, Webserver, Skriptsprache, CMS). Viele Leute suchen nach bekannten Sicherheitslücken in alten (ungepatchten) Versionen
  • Entfernen Sie jegliche Software, die Sie nicht benötigen (im Idealfall bewahren Sie das Paket nicht auf, um Software auf Produktionsservern zu kompilieren, es ist besser, Software vorab zu kompilieren und sie als Paket für Ihre Produktionsmaschinen verfügbar zu machen)
  • Stellen Sie sicher, Datei Berechtigungen sind gesperrt (besonders für Dinge wie Benutzer Uploads und Konfigurationsdateien)
  • Passwortschutz für CMS auf Web-Server-Ebene (HTTP-Authentifizierung kann vor einem anfälligen CMS sitzen und den Zugriff blockieren, was eine gute Möglichkeit ist, Angriffe zu verhindern.
  • Verwenden Sie SSL für Verwaltungsbereich und andere sensible Daten
  • Automatisieren Sie die Verwaltung Ihrer Server und Infrastruktur (etwa Marionette, Chef oder SaltStack. Wenn Sie auch AWS CloudFormation verwenden). Dies wird Ihnen helfen, Dinge auf vielen Servern zu patchen und Szenarien wie das Korrigieren von Berechtigungen auf Server A zu reduzieren, aber vergessen, dies auf Server B zu tun
  • Wenn möglich, verschenken Sie nicht die jeweilige Version Ihres CMS, PHP oder WebServers. Während das Verschleiern dieser Information keine Sicherheit ist, gibt es viele Leute da draußen, die nach bestimmten Versionen verschiedener Software suchen, und je weniger Informationen Sie frei geben, desto mehr muss ein Angreifer arbeiten. Dies ist ein guter Weg, um sicherzustellen, dass Sie nicht zu den tiefhängenden Früchten gehören. Natürlich wird das nichts für jemanden tun, der etwas mehr Aufwand investieren möchte
  • Begrenzen Sie die Personen, die Zugriff auf den Server haben

7
2017-08-10 08:08





Zusätzlich zu dem, was David vorschlägt: Je modularer Ihre Installation ist, dh ich beschränke den Zugriff auf bestimmte Benutzer / Gruppen, die speziell für eine Aufgabe erstellt wurden, und schränkt deren Umfang ein, desto sicherer ist Ihr LAMP-Stack: Ein Beispiel dafü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 mit Ihren zu versendenden Websites und nur mit diesen Tabellen verknüpft sind. Darüber hinaus können Sie ihren Zugriff einschränken, um den Zugriff auf einen PHP-Aufruf so gering wie möglich zu halten. Stellen Sie außerdem sicher, dass der MySQL-Benutzername, der über die PHP-Datei verwendet / verfügbar gemacht wird, nicht derselbe Benutzername oder dasselbe Passwort ist, das für einen anderen Benutzer verwendet wird.

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

Wenn der MySQL-Benutzer irgendwie kompromittiert würde, 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 Tabellen löschen oder Informationen in Tabellen in einer isolierten Datenbank einfügen. Aus diesem Grund ist es wichtig, den Tabellenzugriff nur dort zu gewähren, wo es absolut notwendig ist, und nur die erforderlichen Berechtigungen zu erteilen. t müssen Tabellenprivilegien oder Aktualisierungsberechtigungen haben, dann geben Sie diese nicht an diesen Benutzer weiter.

Wenn aus irgendeinem Grund Ihr Benutzername und Passwort für Ihr Administratorkonto bei MySQL gefunden wird, müssen Sie, wenn Sie einen anderen Benutzernamen als Benutzernamen auf Ihrem System verwenden, zunächst die Sicherheit Ihres Systems durchbrechen, bevor Sie in Ihre Datenbank gelangen, um Schaden anzurichten. Dasselbe gilt für den Apache-Benutzer und den Zugriff auf Dateien.

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

Sagen Sie, Sie haben Benutzer auf Ihrem System (root sollte für Sicherheit durch etwas wie Umod-l oder passwd-l, etc. deaktiviert werden): John, Barney, Terence und Lisa.

Sie könnten einen Benutzer in MySQL mit dem Namen bigbird erstellen (stellen Sie sicher, dass Sie ein Hash-Passwort verwenden). Bigbird verfügt nur über ausgewählte Berechtigungen und Update-Berechtigungen, aber nicht über Drop- oder Create-Funktionen . Zusätzlich erstellen Sie einen anderen administrativen MySQL-Benutzer mit dem Namen garfield für die Arbeit an der MySQL-Datenbank und Sie löschen den Root-Benutzer aus der MySQL-Datenbank, so dass er nicht komprimiert werden kann. garfield wurde gewährt . Privilegien in MySQL (effektiv, dies ist nur umbenennen root).

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 sind in / home / apweb2 / gespeichert. Jeder virtuelle Host hätte seinen eigenen Unterordner und jeder dieser Hosts würde den Dokumentenstamm auf diesen Unterordner setzen. Symlinks würden deaktiviert werden, um nicht versehentlich Zugriff auf den Rest des Systems zu gewähren.

Außerdem können Sie den ssh-Zugriff nur auf bestimmte Benutzer beschränken (oder bestimmte Gruppen, die ich gerne in die ssh-Gruppe lege und das einzige, das ssh verwenden kann).

Außerdem können Sie auswählen, welche Benutzer über sudo-Berechtigungen verfügen, um die Aktivitäten noch weiter einzuschränken. Ein weiterer Schritt, den Sie weiterführen können, besteht darin, dass ssh-Benutzer nicht in der Lage sind, sudo zu verwenden. Sie könnten spezielle Benutzer erstellen, die sudo verwenden können, die ssh nicht verwenden können, so dass Sie sich bei einem anderen Benutzer einloggen müssen Zugang zu Sudo.

Wenn man also jedes Segment modularisiert, wird, wenn man kompromittiert ist, der gesamte Stapel nicht kompromittiert, und man kann das Problem lösen, anstatt von vorne beginnen zu müssen.


4
2017-07-30 04:49





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


2
2017-08-10 11:50



Willkommen bei Serverfehler! Im Allgemeinen mögen wir Antworten auf der Website, um alleine stehen zu können - Links sind großartig, aber wenn dieser Link jemals bricht, sollte die Antwort genügend Informationen haben, um immer noch hilfreich zu sein. Bitte bedenken Sie, dass Sie Ihre Antwort bearbeiten müssen, um mehr Details zu erhalten. Siehe die FAQ Für mehr Information. - slm


Vernachlässigen Sie derzeit nicht die Container-Virtualisierung, namentlich Docker, systemd-nspawn und die Mechanismen der Container-Virtualisierung, auf denen sie gebaut werden (Namespaces, Cgroups). Mithilfe 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.


0
2017-07-27 20:00