Am Donnerstag, 15. September 2005 12:11 schrieb andreas: > Hi, > > On Thu, 15 Sep 2005, Max Trense wrote: > > Am Donnerstag, 15. September 2005 10:45 schrieb andreas: > > > > Warum das? Es macht IMHO keinen Unterschied, ob ein Angreifer die > > Benutzersitzung kompromitieren kann, die ich verwende um via su root zu > > werden oder ob er gleich die Sitzung als root angreift. Wichtig ist, dass > > er keines von beidem bekommt. Und das geht nur über regelmäÃige > > Updates und sichere Passwörter. > > Soweit ich das verstanden habe macht der sshd beim loginversuch von root > intern dicht somit wuerde es das system schonen! > Ich blaetter nachher nochmal den soure durch.
Ja, schon. Aber die Auswirkungen auf das System sind die Selben, ob Du nun eine gehackte Benutzersession hast, in der Du Dir root-Rechte verschaffst, oder ob Du eine gehackte Rootsession hast. Deswegen scheue ich den Mehraufwand, jedesmal wenn ich mich auf einem Server anmelde zwei Passwörter eingeben zu müssen, wenn es mir keinen Sicherheitsvorteil verschafft. > > Bei Updates übrigens eine vielgehörte und vielüberhörte Warnung, nach > > dem Neustart des ssh-Servers eine weitere Verbindung aufzubauen, denn die > > aktuelle Verbindung wird noch über die alte ssh-Binary aufrechterhalten. > > Nur nach einem erneuten Anmelden kann man sicher sein, dass der neu > > aufgespielte ssh-Server auch wirklich das tut, was er soll ;-) > > darum starte ich den immer nach compilen mit ./sshd -p 12345 (JA ich > compile den meist selbst :-)) Ich bin eigentlich ganz glücklich, dass mir die Distributoren mit ihren Paketverwaltungssystemen eine Menge Arbeit abnehmen. > > > Ganz clever ist es allerdings (zetzt vorraus das du weisst was du > > > tust): SSH auf port xxx und port 22 mit, z.b. portsenetry zu belegebn > > > oder ganz einfach ein script schreiben das auf port 22 listen ist und > > > bei zugriff ` route add xxx.xxx.xxx.xxx gw 127.0.0.1` executen. dann > > > ist ruhe :-) > > > > Das ist aber hochgradig DoS-anfällig. Kein *nix-ähnlicher Kernel kann > > IMHO ohne Modifikation beliebig groÃe Routentabellen verarbeiten. Das > > heiÃt, jemand der es darauf anlegt, hat mit sehr geringem Aufwand > > ziemlich schnell Dein System zumindest viel langsamer gemacht. > > Legt es der angreifer drauf an, macht er den system so oder so platt! > der angreifer braucht aber genug ip's! > mal nen test: > for x in ` seq 2 222` ; do route add -host 10.10.1.$x gw 127.0.0.1; done > das habe ich nun mit 10.10.1. - 10.10.10. durchlaufen lassen. > netstat -rn|wc -l wirft 2215 raus! wenn der angreifer 2215 rechner hat, > oder es drauf angelgt sich ueber 2000 mal neu zu connecten macht der dich > auch anders platt! zumal du ja jede stunde die table laeschen kannst. Solange du keine Unterscheidung durch Source-Routing machst, macht Dir da aber das altbekannte IP-Spoofing einen Strich durch die Rechnung. Das Problem ist einfach, dass Sicherungsmaßnahmen für Dich billig, aber für den Angreifer teuer sein sollen. Das ist wie das Problem mit sicherer Kryptographie: Ein Algorithmus ist nur dann sicher, wenn das Ver- und Entschlüsseln mit dem richtigen Schlüssel schnell geht, aber Brute-Force mit dem falschen Schlüssel Jahrhunderte dauert ;-) > > > Auch clever ist ein script zu hacken welches sich das logfile ansieht, > > > und beim falschen login die IP blockt. > > > > Das gibt es aber schon (fast) fertig. Da sollte man sich mal diverse IDS > > anschauen. > > macht aber nix anderes als die route setzen (soweit ich weiss) Die meisten IDS bringen ein PAM-Modul mit, welches eine registrierte IP schon im Account-Modus ablehnt. Alternativ fallen mir auch noch Lösungen ein, die den tcpd verwenden, das halte ich aber für unverantwortlich. Max -- Max Trense - [EMAIL PROTECTED] - http://www.trense.info
-- ---------------------------------------------------------------------------- PUG - Penguin User Group Wiesbaden - http://www.pug.org
