Moin, die Frage ist eine Folgefrage von Beitrag "Aufwand um Server gegen Missbrauch zu schützen" Wie kann eine auf einem Server laufende Software missbraucht werden im Sinn von 'Systeme schädigen'. Nehmen wir an, das Programm läuft in einem eigenen Jail. 1. Die Daten, auf die das Programm Zugriffsrecht hat, könnten ausgelesen werden. Da keine geheimen Daten vorliegen, spielt das hier wohl keine Rolle. 2. Durch Code-Injektion könnte das Programm im Jail irgendwas machen. 2.1 Dateien löschen: Kein Problem 2.2 Programme installieren und ausführen, die Schaden verursachen. DoS oder Spamversender zum Beispiel 2.3 Selber so umgeschrieben werden, dass es Schaden verursacht wie unter 2.2 3. Reflection-Angriffe, ähnlich wie bei NTP. 4. Je nach Protokoll dem Nutzer (Client) einen Virus unterschieben. Wie schwer sind die Auswirkungen, wie leicht kann man sich dagegen schützen, welche Möglichkeiten gibt es noch?
Bist du im System drin, ist die Angriffsfläche deutlich größer; ein Stichwort ist "local privilege escalation".
Das sollte aber hauptsächlich durch das Betriebssystem verhindert werden, oder? In FreeBSD müsste es doch möglich sein, dass der Benutzer, der das Programm ausführt, nur in einem Ordner Schreib- und Leserechte und in einem anderen Ordner nur Ausführungsrechte hat, oder? Dann könnte man das auszuführende Programm in den Ordner mit Ausführungsrechten legen und damit verhindern, dass das Programm verändert oder ein neues Programm installiert wird. In dem Ordner, in dem der Benutzer Schreibrechte hat, könnte ein neues Programm abgelegt werden, aber es könnte nicht ausgeführt werden. Funktioniert das so? Muss man das überhaupt? Code-Injection in den RAM hätte man so noch natürlich noch nicht verhindert.
Von FreeBSD habe ich keine Ahnung. Aber selinux (security enhanced linux), eine sehr viel tiefgreifendere Verwaltung von Zugriffsrechten im Zusammenspiel mit Anwendungen, geht in diese Richtung. Ist ein optional verwendbarer Teil von Linux-Distros.
:
Bearbeitet durch User
Dussel schrieb: > Nehmen wir an, das Programm läuft in einem eigenen Jail. [...] 5. Einen Fehler vorgaukeln, warten bis sich der Admin per SSH einloggt und dann dessen SSH-Session missbrauchen. Z.B. so http://0xthem.blogspot.de/2015/03/hijacking-ssh-to-inject-port-forwards.html 6. Aus dem Jail ausbrechen. Wenn das Jail irgendwelche Kommunikation mit dem Host oder der Außenwelt erlaubt, und das muss es damit es nutzbar ist, ist das Einsperren ziemlich komplex. Daher ist mit hoher Wahrscheinlichkeit irgendwo eine Lücke drin.
Kurzum: Die einzig sichere Anwendung für Kommunikation mit der Aussenwelt ist eine Anwendung, der man jede Kommunikation mit der Aussenwelt rein physisch abschneidet. ;-) Wenn man mit dieser kleinen Einschränkung nicht leben kann, dann muss man Abstriche an die Sicherheit machen. Dass Millionen von Servern trotzdem funktionieren zeigt, dass es geht. Und dass man immer wieder von Einbrüchen in Server lesen muss zeigt, dass es nicht geht. Der Rest ergibt sich dann aus dem Grad der eigenen Empfindlichkeit gegenüber den Meldungen in einschlägigen Medien, den tolerierten Kosten der Lösung und ob es einen schon mal erwischt hat. Absolut sicher geht nicht, aber sperrangelweit offen ist auch nicht gut. So landet man dann bei einem Kompromiss.
:
Bearbeitet durch User
Gerd E. schrieb: > Dussel schrieb: >> Nehmen wir an, das Programm läuft in einem eigenen Jail. > [...] > > 5. Einen Fehler vorgaukeln, warten bis sich der Admin per SSH einloggt > und dann dessen SSH-Session missbrauchen. Z.B. so > http://0xthem.blogspot.de/2015/03/hijacking-ssh-to-inject-port-forwards.html > > 6. Aus dem Jail ausbrechen. Wenn das Jail irgendwelche Kommunikation mit > dem Host oder der Außenwelt erlaubt, und das muss es damit es nutzbar > ist, ist das Einsperren ziemlich komplex. Daher ist mit hoher > Wahrscheinlichkeit irgendwo eine Lücke drin. :-( > Dass Millionen von Servern trotzdem funktionieren > zeigt, dass es geht. Die meisten werden aber auch von Profis gewartet. Die Idee mit dem Server habe ich erstmal auf Eis gelegt, aber das Thema interessiert mich trotzdem noch.
> Die Idee mit dem Server habe ich erstmal auf Eis gelegt
Nun übertreibe mal nicht mit deiner Paranoia.
Die Botnetze brauchen ein paar Server mit fester IP-Adresse und
Zigtausende von PCs.
Als Server ist dein Kasten mit wechselnder IP ist doch vollkommen
uninteressant. Und warum deinen PC kapern? Mit dem selben Aufwand
bekommen die 10000 normale Windows-PCs.
Einfach mal beobachten, ob der Datentransfer im erwarteten Rahmen
bleibt.
Noch einer schrieb: >> Die Idee mit dem Server habe ich erstmal auf Eis gelegt > > Nun übertreibe mal nicht mit deiner Paranoia. > > Die Botnetze brauchen ein paar Server mit fester IP-Adresse und > Zigtausende von PCs. > > Als Server ist dein Kasten mit wechselnder IP ist doch vollkommen > uninteressant. Und warum deinen PC kapern? Mit dem selben Aufwand > bekommen die 10000 normale Windows-PCs. Es ging darum, einen Server zu mieten. Der sollte in den meisten Fällen eine feste IP haben und eine Verbindung, die gut genug ist, um Schaden anzurichten. ;-)
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.