Homeserver - Tutorial gesucht!

[Christoph Zurnieden]

Hi,

Falls noch andere hier mitlesen: das Folgende ist eine rein theoretische Diskussion, bitte stattdessen bei der Serversicherung die bekannten Maßnahmen zu ergreifen und nichts von mir zu übernehmen! Ich mache das schließlich auch so!
(Das ich nichts von mir übernehme? Naja, gut ... ;-)

Es gibt doch sehr viele Bugmeldungen der Art "erlaubt die Ausführung beliebigen Codes mit den Rechten des jeweiligen Users".

Es gibt auch viele Bugmeldungen mit privilege escalating Exploits (im Weiterem P.E.) - lokal oder auch remote, aber das ist von keinem wesentlichem Unterschied, zumindest in der Behandlungsweise. Da es nicht anzunehmen ist, das von fehlender Bugmeldung auf fehlenden Bug zu schließen ist, ist die genaue Art der Sicherheitslücke nicht wirklich relevant. Es gibt kein "nicht so schlimm", genausowenig wie "ein bischen schwanger".

Das führt dazu, das die übliche - und auch durchaus beizubehaltende - Gepflogenheit, jedem Service eine eigene User/Group Kombination zu verpassen nicht _in_ das Zwiebelmodell "Sicherheit" hineingehört sondern "nur noch" als Tüpfelchen auf dem 'i'. Ungefähr in den selben Rahmen, wie die Empfehlung, das Services ihre Versionsnummer nicht verraten sollten; der Apache also z.B. nur verraten sollte, welche Protokolle er unterstützt, aber nicht womit und auch nicht, wie er heißt.

Es ist also vollkommen im Sinne einer mehrschichtigen Abschottungsstrategie, wenn man es einem Angreifer so schwer wie möglich macht.

Ja, durchaus, aber man fängt von innen an. Es kostet schließlich alles Geld und da wird zuerst eingerichtet, was am meisten Effekt ergibt, nicht unbedingt, was am billigsten ist. Ja, ein wenig Hoffnung schwebt da mit ;-)

Die Einrichtung der Services mit verschiedenen Usern/Gruppen ist aber meist eh schon vorgegeben. Bei der Installation der Programme oder gar von der gewählten Distribution. Das zu ändern würde nur in extremen Ausnahmefällen Vorteile bringen, in den allermeisten anderen Fällen jedoch nur Nachteile. Also läßt man es.

Genau deswegen laufen Webservices nicht als root-User, sondern unter einem separaten Account, und auch jeder unter einem eigenen Account.

Dazu ist aber auch, das gebe ich zu bedenken, eine Multiuserumgebung erforderlich, die dann auch wieder andere Probleme aufwirft. Wenn also ein einziger Service als dedizierter Server im Singleusermode läuft, würde ich mir es dreimal überlegen, das zu ändern. Vorausgesetzt natürlich, das sich dabei jemand etwas gedacht hat und es nicht schlichte Unfähigkeit war.
Für eine Readonly Datenhaltung und entsprechender Hardwaresicherung (NX-Speicher etc) könnte das z.B. gehen. Ein Vorteil davon ist, das es klein genug wäre als kompletter Zustand, als RAM-Abbild aus einem ROM geladen zu werden. Alles im restlichem Speicher sei dann prinzipiell nicht ausführbar und reine Datenhaltung.
Dadurch wäre die Universalität der heutzutage gängigen von-Neumann-Maschinen allerdings stark in Frage gestellt. Ähnlich, wie es heute beim BIOS geht, würde aus einem Baukasten alles zusammengesteckt und wäre nur noch komplett austauschbar.
Und ob das wirklich soviel sicherer wäre?

Aber sowas begrenzt halt erst einmal den möglichen Schaden: Fehler in einem Daemon oder sonstigen Programmen, beispielsweise ein unachtsames Remote-Code-Include in PHP, führen zunächst nur dazu, dass man als der User dieses Daemons böse Dinge anstellen kann. Um von dort aus root zu werden, sind nochmal ganz andere Anstrengungen notwendig.

Gilt zwar nicht oder nur begrenzt für die hier angesprochenen Services aber trotzdem mal am Rande: Für einen normalen User mit Account ist es genauso schlimm, wenn in seinen eigenen Account eingebrochen wurde, als wenn root gefallen wäre. Es geht dem normalem User einzig und allein um seine Daten, nicht um das System, das in ein paar Minuten wieder vom Backup eingspielt werden kann, oder in ein paar Minuten mehr komplett neu aufgesetzt.
Wenn der Angreifer z.B. einen Browserexploit ausnutzt und schlicht 'for i in ~/*; do echo "" > $i;done' ausführt, dann sind des Users Daten weg. Dem nützt es dann rein gar nichts mehr, das das System dabei unbehelligt bleibt, es geht höchstens etwas schneller das Backup einzuspielen. Die Daten von einem Tag (wenn überhaupt täglich ein Backup gemacht wurde) sind schlicht weg.

Davon abgesehen hast du natürlich Recht: Ein irgendwie kompromittiertes System sollte unbedingt einer forensischen Analyse unterzogen werden, und dann komplett neu aufgesetzt. Ansonsten setzt man sich unnötigen Restrisiken aus. Das ist aber erst die Strategie für "danach" - warum sollte man nicht schon "davor" alle Möglichkeiten nutzen, um den Angriff so schwer wie möglich zu machen?

Ja, natürlich, aber schön in der vorgesehenen und lang erprobten Reihenfolge:
Erst in eine ordentliche Firewall investieren ( was ich unter "ordentlich" verstehe würde hier zu weit führen, aber ich nehme an, das da zwischen uns eh weitgehend Konsens herrschen würde). Ist das nicht möglich: laß es ganz, ich würde noch nicht einmal ein OpenBSD oder besser "nackicht" an's Netz hängen wollen.
Dann sollten alles Service auf möglichst viele Boxen verteilt erden, anzustreben ist ein Service pro Box. Ist aber meist aufgrund finanzieller Erwägungen nicht möglich. Auch praktische Erwägungen stehen dagegen, denn ohne zumindest ein SSHD o.ä. wäre ja nur Ein-ausschalten möglich.
Dann ist ausführlich auf Fehler zu prüfen: angefangen beim schlichtem Funktionstest, über einen oder besser mehrere Penetrations- und (D)DoS-Tests, bis hin zur Überprüfung des Codes falls Mittel und Fachpersonal zur Verfügung stehen. Es ist auch alle Hardware zu prüfen falls möglich (z.B. memtest86 u.ä.). Es sind nicht nur mehr oder weniger korrekte Usereingaben zu prüfen, sondern nach Möglichkeit auch aus /dev/random die Programme zu füttern.
(Insgesammt eine sehr unvollständige Liste, aber ich glaube eine gute Übersicht gegeben zu haben)

Dann und wirklich erst dann, sind solche Sachen wie Schadensbegrenzung zu bedenken: Versionsunterdrückung, Ausnutzung der Multiuserumgebung und was es alles so gibt.

Insbesondere, wenn sie so leicht umsetzbar sind, wie verschiedene Useraccounts.

Nun, bei extremen Zeitmangel, wenn Konventionalstrafe droht und der Kunde schon ständig seine Rolex bewundert, dann würde ich es nicht extra noch einrichten wollen ;-)

Aber wie gesagt: ist ja schon meist in der Installation von Programm oder Distribution mit drin, kost' im Grunde genommen gar nix, nimmt man also gerne mit.

[CVS]

Ich rede von megabytegroßen Binärdateien.

Wobei die Probleme keine von CVS-Programmcode sind,

[...]

an 60 MB Binärdaten scheitert, dann stimmt da was nicht... :)

Ja und zwar bei CVS (dem Programm). Wie man riesige Dateien schnell und sparsam sortiert steht schon ja schon im Sedgewick gut beschrieben und der hat's auch nicht selber erfunden. Von da zu einem Diff ist es nicht sehr weit. Finde es also sehr befremdlich, das das immer noch Probleme bereitet.

Alles im Bereich bis 9,99 Megabyte würde ich als unkritisch einschätzen, und auch all das, was Textdatei ist - denn das läßt sich ja gut als DIFF komprimieren. Binärdateien aber sind in CVS nicht wirklich gut aufgehoben, zumindest keine großen.

Wenn ich CVS allgemein nehme (Nicht als Programm, sondern als Abkürzung für "Concurrent Versioning System") macht das aber bei der Zunahme von digitalen Filmbearbeitungen schon Sinn. Könnte mir gut vorstellen, das dort ein CVS ganz praktisch wäre.

Dagegen gäbe es kryptographische Mittel und Wege, aber die sind kaum einem Fortgeschrittenem, geschweige denn einem Anfänger zuzumuten. Zumal sie auch noch zum Teil auf der unkontrollierbaren Clientseite passieren müssen.

SSL mit Zertifikat wären ja für die Benutzeranmeldung schon eine vernünftige Absicherung. Das löst aber keinesfalls das Mailproblem.

Eben, das läßt sich auf so einfache Weise nicht beherrschen.
Und wenn ich hier "SSL mit Zertifikat" als einfach bezeichne, dann kann man sich ja vorstellen, was da für Probleme auf einen zukämen ;-)

so short

Christoph Zurnieden