Ich fand obenstehenden Diskussionsbeitrag recht gelungen.Using su is a security risk nowadays.
Your security is only as strong as the weakest link, and su is a weak link.
Nein, ich hab Root-Login abgeschaltet :-). Bei mir gibt's auch kein ftp.Desweiteren loggst du dich damit für jeden Sch.eiß auf deinem Server als root ein?
Da hast du ja recht, nur sehe ich es eben differenzierter, vor allem im Hinblick auf die User hier, die das lesen und umsetzen, ohne vorher auch nur ein wenig nachzudenken ;)tic wrote:Ich fand aber, so einiges was er da von sich gibt ist nicht von der Hand zu weisen und empfand das als guten Diskussionsanstoß.
Ich weiß, ich bin nicht gemeint. Aber wenn ich mich auf einer meiner Maschinen einlogge, dann in der Regel, um administrative Aufgaben wahrzunehmen. Dazu benötige ich nunmal in der Mehrheit der Fälle UID 0. Zum arbeiten, spielen und testen habe ich lokal Rechner stehen, da gibt es dann auch entsprechende Useraccounts. Auf einem ausdrücklichen Web/Mail/sonstwas(ausgenommen: Shell)-Server sollten imho so wenig user wie möglich eine Shell erhalten dürfen.Desweiteren loggst du dich damit für jeden Sch.eiß auf deinem Server als root ein?
Da hat aber mal jemand ganz übel gepennt. BF-Attacken sind bei weitem nicht das einzige Risiko, root den Zugang per SSH zu erlauben. Sorry, dass ich dich jetzt aus deiner heilen Welt holen muss, aber lies mal (z.B.) http://www.ece.cmu.edu/~dawnsong/papers/ssh-timing.pdf . Weitere Variante: man in the middle.Ich habe auch mitbekommen, dass hier das Ermöglichen des Einloggens als root via ssh eine Art "nono" zu sein scheint. Doch warum eigentlich? Selbst, wenn ich nur die Passwortabfrage habe, sehe ich eine BF-Attacke bei gut gewähltem Passwort als aussichtslos an.
Ich kann dir gerne für eine meiner Kisten einen root-Zugang geben. Du solltest dich nur nicht wundern, warum du dort als root weniger darfst als ein eingeschränkter User auf deiner Kiste.Aber wenn ich mich auf einer meiner Maschinen einlogge, dann in der Regel, um administrative Aufgaben wahrzunehmen. Dazu benötige ich nunmal in der Mehrheit der Fälle UID 0.
nicht deutlich genug hervorgehoben, bzw. habe mich beim Rest zu sehr auf BF beschränkt.Außerdem gibt es ja nun auch andere, noch sicherere Verfahren, etwas Nettes auf Challenge/Response-Basis z.B.
Darum wird hier ja über das Unterbinden des root-Login hinaus auch immer wieder zu PubKey-Auth geraten. ;)Mein Fehler, ich habe
Zitat:
Außerdem gibt es ja nun auch andere, noch sicherere Verfahren, etwas Nettes auf Challenge/Response-Basis z.B.
nicht deutlich genug hervorgehoben, bzw. habe mich beim Rest zu sehr auf BF beschränkt.
Der "Umweg" über einen normalen Useraccount stellt aber immerhin eine weitere Hürde dar, bei der man die Gefahr des o.g. durch geeignete Schutzmaßnahmen verringern kann.Nur, nehmen wir an, dass ein "man in the middle"-Angriff für jedes Scriptkiddy so einfach durchzuführen wäre, dann wäre es für dieses doch fast ebenso einfach, einen non-root-Account zu erlangen und dann, wie in dem Beitrag, auf den sich der Ausgangspost bezieht, über su die notwendigen Rechte zu erhalten?
Auch das ist mit RSBAC problemlos machbar. Eine "Gewaltenteilung" macht die Sache aber halt noch etwas sicherer.Ich gebe gerne zu, mich mit RSBAC so gut wie gar nicht auszukennen, du darfst mich nun auch gerne für naiv oder altmodisch halten, wenn ich sage, dass ich auf meinen Rechnern einen User haben möchte, der die Rechte für alles hat - alleine, weil ich oft mehrere Aufgaben erledige, wenn ich mich einmal einlogge. Für mich wäre es da eher hinderlich, für jede Aufgabe einen anderen Account zu wählen.
Na willkommen im Club. ;) Ich für meinen Teil betrachte den Serverbetrieb aber als Herausforderung in puntko Sicherheit, und möchte selbst für meine popeligen kleinen Webseiten das absolute Optimum an Sicherheit herausholen, auch wenn es den Aufwand weniger als nicht rechtfertigt.Ich muss dazusagen, dass ich Rootserver nur hobbymäßig betreibe und deswegen Aufwand gegen Nutzen abwägen muss.
Eh, du bist ja immer wieder für ein paar interessante Links gut! ;)
Du solltest dann aber fairerweise auch nicht verschweigen, dass du dich - zumindest auch - berufsweise mit IT-Sicherheit beschäftigst und das zu deinem täglich Brot gehört. ;)Ich für meinen Teil betrachte den Serverbetrieb aber als Herausforderung in puntko Sicherheit, und möchte selbst für meine popeligen kleinen Webseiten das absolute Optimum an Sicherheit herausholen, auch wenn es den Aufwand weniger als nicht rechtfertigt.
Ich hab ja auch nicht gesagt, dass es einfach ist, sondern wollte nur aufziegen, dass auch SSH nicht automatisch (gerade bezogen auf's Thema) die perfekte Sicherheit bietet. ;)aber wenn ich das richtig sehe, basiert das ganze darauf, dass der Angreifer in der Leitung hockt und mitlauschen kann. Ich würde daher davon ausgehen, dass das nur von einem sehr begrenzten Teil der Angreifer wirklich genutzt werden könnte.
Würde ich so nicht sagen. Beim Portknocking hast du "nur" zwei Hürden:Im Prinzip ist das ja der unausgegorene Anfang von Portknocking.
Nun, eigentlich unterscheidet sich doch nur 1. - Login als user vs. Portsequenz.CaptainCrunch wrote:Würde ich so nicht sagen. Beim Portknocking hast du "nur" zwei Hürden:Im Prinzip ist das ja der unausgegorene Anfang von Portknocking.
1. Reihenfolge / Abfolge des "Klopfens".
2. Login des Users auf den dadurch freigeschalteten Port.
In dieser Variante ist es immerhin eine Hürde mehr:
1. Login als User.
2. Connect auf einen bestimmten Port. Als Idee dazu: der Port wird (optional) dynamisch festgelegt, und dem User an eine definierte Emailadresse zugeschickt.
3. Weiteres Login als User/root/whatever.
Daher finde ich diese Vorgehensweise ehrbelich besser als "ordinäres" Portknocking...
Wenn der Angreifer aber die Kommunikation mitschneiden kann ist die Version mit dem User deutlich im Vorteil. Denn das richtige Password kann er nicht mitsniffern, die Portknocking-Sequenz schon.niemand wrote:Unter dem Gesichtspunkt (Angreifer muss erstmal die Sequenz erraten, anstatt sich nur als user einzuloggen und den Login zu canceln), sehe ich bei Portknocking wieder Vorteile bezüglich der Sicherheit.
