nicht angemeldet
Moin!
Ja, das mag stimmen, ich bin da vielleicht etwas zu paranoid: für mich ist bei einem erfolgreichem Angriff jedweder Art stets anzunehmen, das das gesamte System beschädigt ist und dementsprechend zu handeln. Dementsprechend bringt eine Trennung nicht sonderlich viel. Es sollte pro Box ja normalerweise auch nur ein einziger Dienst laufen, aber das ist ja aus einsehbaren Gründen nur selten möglich, mindestens ein SSHD o.ä. läuft ja immer mit.
Es gibt doch sehr viele Bugmeldungen der Art "erlaubt die Ausführung beliebigen Codes mit den Rechten des jeweiligen Users".
Es ist also vollkommen im Sinne einer mehrschichtigen Abschottungsstrategie, wenn man es einem Angreifer so schwer wie möglich macht. Genau deswegen laufen Webservices nicht als root-User, sondern unter einem separaten Account, und auch jeder unter einem eigenen Account. qmail beispielsweise ist so paranoid, dass da für jeden einzelnen Daemon, der läuft, ein eigener User eingerichtet wird. 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. Ohne Abschottung der Daemons in unterschiedlichen Usern wäre ein wesentlich größerer Systemzugriff schon an diesem Punkt möglich.
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? Insbesondere, wenn sie so leicht umsetzbar sind, wie verschiedene Useraccounts.
Ich würde dafür nicht unbedingt CVS nehmen. Dieses System hat mit großen Dateien so seine Probleme, insbesondere mit Binärdateien.
Was denn, immer noch?
Ich rede von megabytegroßen Binärdateien.
Wobei die Probleme keine von CVS-Programmcode sind, sondern schlicht ein Ressourcenproblem. Ich hatte mal Bilddateien, die um die 60 MB groß waren. Diese zum CVS hinzuzufügen ("add") hat noch funktioniert, sie danach hochzuspielen auf den Server wurde schwierig und scheiterte letztendlich daran, dass für das DIFF zuwenig RAM zur Verfügung stand, bzw. sich der Server (ok, so eine Höllenmaschine war es nicht, aber wenn der Server 194 MB RAM hat, und ansonsten nichts zu tun außer für CVS dazusein, aber an 60 MB Binärdaten scheitert, dann stimmt da was nicht... :)
Naja, meine größten Dateien sind eh nur C-Header mit vielen ifdef's, da kommen vielleicht mal 50 kib zusammen, mehr nicht ;-)
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.
Ebenso, wenn man sich mit Passwortabfrage auf dem DynDNS-Server anmeldet: Die Passworte gehen an den falschen Server, was ist, wenn der das munter mitschreibt und gegen einen verwendet?
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.
- Sven Rautenberg