Wann sollte ich ein neues Benutzerkonto erstellen, um Software auf einem Server auszuführen?

Wann sollte im Allgemeinen ein neues Benutzerkonto erstellt werden, um eine mit dem Internet verbundene Software auf einem Server auszuführen?

Angenommen, ich verwende einen gemeinsam genutzten Debian-Server (z. B. über Dreamhost) und möchte einige Websites mit WordPress, einige mit Redmine, einige mit Ruby on Rails, einige mit Django betreiben und Mercurial unterstützen Repositories auch.

Auf Dreamhost-Servern und vielen anderen ähnlich eingerichteten Servern könnte dies alles unter einem einzelnen Benutzerkonto erfolgen , bei diesem Ansatz kann ich jedoch einige Nachteile feststellen:

Eine längere .bashrc
Wenn dieses eine Konto kompromittiert wird, tun dies alle Sites, die unter diesem Konto ausgeführt werden.

Andererseits kann es schwierig werden, viele Benutzerkonten zu haben, um den Überblick zu behalten, insbesondere wenn einige von ihnen identische Anforderungen an die installierte Software haben. Ein Konto für jede Website, auf der WordPress ausgeführt wird, ist möglicherweise zu viel.

Was ist die beste Vorgehensweise? Geht es lediglich darum, die Anzahl der gehosteten Websites (oder der gehosteten Repositorys usw.) pro Benutzerkonto proportional zum Grad der Paranoia zu verringern?

Bitte hinterlassen Sie Ihre Meinung dazu und begründen Sie diese.

Wenn Sie Grund zu der Annahme haben, dass sich die Vorgehensweise auf einem privaten Server oder VPS von der Vorgehensweise auf einem gemeinsam genutzten Server unterscheidet, erläutern Sie bitte die Gründe für diese Vorgehensweise.

— sampablokuper
quelle

Antworten:

Ich bin im Allgemeinen ein Fan von "Ein Benutzer für alles, was das Abhörsocket im Netzwerk öffnet" - Einer für Apache, einer für Mail, einer für DNS usw.

Dies ist (wie ich zuletzt gehört habe) immer noch die beste derzeitige Vorgehensweise, und der Grund dafür ist ganz einfach Paranoia: Diese Dienste sind dem Big Bad Internet ausgesetzt, wenn jemand eine Sicherheitsanfälligkeit findet und sie ausnutzt, bevor ich die Chance habe, die zu patchen Ich beschränke sie zumindest auf ein Benutzerkonto, mit nur den Berechtigungen, die zum Ausführen des einzelnen Dienstes erforderlich sind, für den er verantwortlich ist.
Im Allgemeinen halte ich diese Isolationsstufe für ausreichend, um das System zu schützen, obwohl jede Anwendung eine Schwachstelleninsel darstellt (zum Beispiel, wenn jemand ein anfälliges WordPress-Plugin installiert, sind alle Dinge, auf die Apache Zugriff hat (dh alle Websites), effektiv anfällig im Falle eines Kompromisses.

Eine erweiterte Version dieses Arguments kann daher für das Sandboxen von Websites von Shared Hosting-Clients mit eigener Apache-Konfiguration und eigenem Benutzer erstellt werden (Sie müssen nicht unbedingt für jede Site einen vollständigen Webstack installieren, sondern lediglich eine separate Apache-Konfiguration, die einen anderen Benutzer angibt ), der Nachteil ist, dass auf jeder Site jetzt eine Reihe von Apache-Prozessen ausgeführt werden, so dass die RAM-Auslastung erheblich zugenommen hat und Dinge, die von der Welt gelesen werden können, immer noch anfällig sind, wenn eine einzelne Apache-Instanz / ein einzelner Apache-Benutzer gefährdet wird.

Das Argument, dass jeder Apache in eine Chroot (oder ein Jail, wenn Sie auf BSD-Systemen arbeiten) abgelegt werden soll, kann noch weiter ausgebaut werden, aber jetzt geht es um zusätzlichen Speicherplatz, da für jede Chroot / jedes Jail die erforderliche Software erforderlich ist Führen Sie die darin enthaltene Site aus (und die Notwendigkeit, diese Software für jede Site und nicht nur für eine Masterkopie auf dem Server zu aktualisieren, wenn Patches veröffentlicht werden).
Dies mindert alles außer einem Betriebssystem- / Kernel-Fehler, durch den Benutzer aus der Chroot ausbrechen können (was zum Argument für die Ausführung jeder Site auf einem separaten physischen Server wird - was dann zum Argument für die Aufteilung der Sites in verschiedene VLANs / Subnetze usw. wird).

Wie bei allen Risiken können Sie es nicht ausschließen: Sie können es nur auf ein akzeptables Maß reduzieren, das auf dem potenziellen Schaden / den Kosten eines Kompromisses, der Wahrscheinlichkeit eines Kompromisses und den Kosten der einzelnen Minderungsstufen basiert.
Für mein Geld, für eine unkritische, nicht E-Commerce-basierte Shared-Hosting-Umgebung die Grundvoraussetzung "Ein Benutzer für Apache, einer für DNS, einer für Mail usw." Sicherheitsnetz ist genug. Wenn darüber hinaus ein Sicherheitsbedürfnis besteht, sollten Ihre Benutzer ernsthaft über ihre eigene Hardware nachdenken.

— voretaq7
quelle

Es gibt auch ein Modul für Apache (ich denke, mod_su?), Mit dem Apache den Benutzer, unter dem es ausgeführt wird, basierend auf der eingehenden Anfrage dynamisch ändern kann. In einer gemeinsam genutzten Hosting-Umgebung würden Sie festlegen, dass sich der Benutzer ändert, dem die Website gehört, auf die zugegriffen wird. Dies ermöglicht die Unterteilung der häufigsten Arten von Sicherheitsverletzungen (Code-Injection usw.), sodass nur derjenige Benutzer davon betroffen ist, der z. B. das fehlerhafte WordPress-Plugin installiert hat. Es bietet auch einen gewissen Schutz vor einer vollständigen Verletzung des Apache-Prozesses selbst und vor Eskalationsangriffen, aber zugegebenermaßen ist dies nicht der eigentliche Zweck.

— Kromey

@Kromey, ich konnte nicht viele Informationen über mod_su finden. Meinen Sie damit mod_suexec ?

— sampablokuper

@sampablokuper Yup, das wäre derjenige, sorry für die Fehlinformationen.

— Kromey

@Kromey Das große Problem dabei mod_suexecist, dass "Nicht-CGI-Anforderungen immer noch mit dem in der User-Direktive angegebenen Benutzer verarbeitet werden". Wenn PHP also ein Modul ist, wird es immer noch als "Haupt" -Apache-Benutzer ausgeführt. Es ist eine großartige Lösung, wenn alles, was Sie ausführen, CGI ist.

— voretaq7

@voretaq Ah, mir war diese Einschränkung nicht bewusst. Könnte in einigen Umgebungen nützlich sein, aber das macht es in der Tat weniger anwendbar, als ich gedacht hatte.

— Kromey

Im Allgemeinen habe ich einen Benutzer für externe Dienste, die sich nicht anmelden dürfen (z. B. "nobody"), und einen Benutzer, der sich anmelden darf, und su oder sudo. Stellen Sie natürlich sicher, dass Ihre Benutzernamen unterschiedlich und nicht leicht zu erraten sind.

Ich sehe keinen Benutzer pro Dienst als notwendig an, es sei denn, Sie betreiben eine gemeinsame Hosting-Umgebung, in der jeder Kunde über eine Anmeldung verfügt. Wenn Sie sich realistisch als ein sehr attraktives Ziel für das Hacken sehen, können Sie so gut wie möglich isolieren. Wenn Sie jedoch nicht etwas sehr umstrittenes unternehmen oder Finanzdaten hosten, sind Sie für ein Ziel nicht wirklich attraktiv.

— Kyle
quelle

+1 Der Grad der Trennung muss der jeweiligen Situation angemessen sein - und wenn Sie erst einmal zu "sehr kontroversen" oder "finanziellen Daten" kommen, werden Sie meine eigenen verdammten Trennungsgrade wollen :-)

— voretaq7