Login-Versuche bei SSH

[sim4000]

Na klar, wenn er eingeloggt ist bringts was ...
Also vor dem Einloggen wurde der Kanal ja schon verschlüsselt, dann soll sich das ganze auf den Login-Prozess dieser SSH-Verbindung beziehen. Sei es durch PID oder sonstiges.

Wenn er eingeloggt ist, ist es aus. Dann bringt jegliche Ausbremsung nichts mehr. Ein Bot hat alle Zeit der Welt.

 

[larry]

Aber dann hat er erstmal lange zu tun.

 

[Gast1]

Stimmt, er hat nach dem erfolgreichen Login sicher ne Menge zu tun, dazu gehören aber sicher NICHT weitere Loginversuche.

:-)

Und vorher hat der Prozess auch keine PID (und falls doch, dann gibt es für den nächsten Versuch eine neue PID und wieder greift Deine tolle Idee nicht).

Und damit wären wir wieder am Anfang ......

 

[Bâshgob]

Aber dann hat er erstmal lange zu tun.

Womit zu tun? In den von ihm selbst schon kompromittierten Account einzudringen während er exakt dort eingeloggt ist?

ROTFLMAO

'tschuldigung, aber sinnloser gehts nun wirklich nicht.

 

[Gast1]

Ich warte jetzt nur noch auf eine Antwort der Marke "Und wenn meine Idee nicht funktioniert, dann......" (siehe Bild)

http://img125.imageshack.us/img125/1245/pepebz3.th.jpg

Am Unterhaltungswert gemessen ist dieser Thread jedenfalls eine wahre Perle.

:-)

 

[larry]

Soweit ich das richtig verstanden hab, forkt ssh bei einer neuen Verbindung, also gibts schon mal ne neue PID... man muss sich dafür noch nicht einmal eingeloggt haben.
Ja, für den nächsten Versuch gibt es natürlich eine andere PID. Ich hab eine Packetfilter-Regel, die die Verbindungen limitiert, aber das ist ein anderes Thema.

 

[Gast1]

Ich hab eine Packetfilter-Regel, die die Verbindungen limitiert, aber das ist ein anderes Thema.

Stimmt, das ist das Thema "die nächte potentielle Self-DoS" Lücke (sofern die Regel schlecht gemacht ist).

Sollte sie gut gemacht sein (auf die sich einloggende IP bezogen), dann ist Deine Idee wieder sinnlos, da obsolet bzw. im Endeffekt eine Variante dessen, was fail2ban macht (bis zum timeout der schon durch Loginversuche bestehenden Verbindungen).

Und selbst dann greift das wieder nicht, wenn jemand seine automatisierten Logins gleichzeitig über Bots mit verschiedenen IPs abschiesst (und böse Zungen behaupten, daß so etwas ab und zu auch wirklich passieren sollte).

Aber mach ruhig weiter, ich will hier schliesslich was Lernen (was verrate ich nicht).

:-)

 

[larry]

Natürlich mach ich weiter, will ja auch was dazulernen... Das mit log-Injection hab ich mir mal durchgelsen... gut... was dazu gelernt.
Wenn ich fail2ban richtig verstanden hab, dann holt sich das Tool Informationen aus den Logfiles. Das macht wohl ein Packetfilter nicht. Weiß nicht, was du mit einer "Variante dessen was fail2ban" macht meinst.
Wenn die Bots mit verschiedenen IPs kommen, ist es mit oder ohne Filterregel gleich. Was hat das mit dem anderem zu tun?

 

[Gast1]

Wenn die Bots mit verschiedenen IPs kommen, ist es mit oder ohne Filterregel gleich. Was hat das mit dem anderem zu tun?

Es hat damit zu tun, daß Deine ganze Idee nichts bringt, egal ob mit oder ohne Filterregel, allerdings mit Filteregel oder Fail2ban das Ganze nicht nur nichts bringt (wie schon vorher) sondern auch keine weitere Funktionalität bringt, was die anderen Mechanismen nicht eh schon machen.

Warum wurde Dir hier schon mehrfach gesagt.

Wenn ich fail2ban richtig verstanden hab, dann holt sich das Tool Informationen aus den Logfiles. Das macht wohl ein Packetfilter nicht. Weiß nicht, was du mit einer "Variante dessen was fail2ban" macht meinst.

Befasse Dich mit den Grundlagen von TCP/IP, Stichworte "timeout" (bei Filterregel "DROP") bzw. Zurücksetzen der Verbindung (bei REJECT oder ohne Paketfilter).

Und zum Thema "DROP/DENY oder REJECT" hier noch was zum Lesen:

http://www.iks-jena.de/mitarb/lutz/usenet/Firewall.html#Deny

 

[larry]

Idee??? Das ist doch bei JunOS implementiert?
Bei einer Bruteforce-Attacke, ist der Bot, falls er kein Zeitlimit hat, erstmal durch dieses Verfahren beschäftigt. Andere Admins freuen sich nicht darüber?

 

[Gast1]

Idee??? Das ist doch bei JunOS implementiert?

Ändert nichts daran, daß es komplett bescheuert ist.

Bei einer Bruteforce-Attacke, ist der Bot, falls er kein Zeitlimit hat, erstmal durch dieses Verfahren beschäftigt. Andere Admins freuen sich nicht darüber?

[ ] Du hast den zuletzt verlinkten Artikel gelesen und verstanden.

 

[larry]

Wer sagt denn, dass Logfiles mit im Spiel sind?

 

[Gast1]

Ich nicht, wieso?

Hat mit den Logfiles auch nicht die Bohne zu tun, die Idee/Implementierung ist und bleibt bescheuert, warum hab ich Dir schon ganz vorne geschrieben, (DoS).

Und im zuletzt von mir verlinkten Artikel steht nicht ein Wort über Logfiles (zumindest sicher nicht in dem von mir verlinkten Abschnitt).

Das zeigt aber auch nur, daß Du ihn eben nicht gelesen hast (wie schon so einiges, was Dir hier geschrieben wurde).

 

[keks]

die Idee/Implementierung ist und bleibt bescheuert

Fakt ist das ich durch den einsatz von fail2ban (welches unter Debian etch natürlich gepatcht ist ) das ddos von ca 500 Versuchen PRO Host und pro Tag, auf insgesamt 5 Versuche pro Host und Tag eindämmen konnte.
Ich wollte genau diese Funktionalität, die mir fail2ban bietet, haben.
Fakt ist auch das ich fail2ban auch einfach abschalten könnte, ohne ein Sicherheitsverlust zu haben.

Hinzu kommt ein sicher konfigurierter sshD, der keine Rootlogins zulässt, eine allgemeine IPtables Firewall, die alle unnötigen Ports zumacht und außerdem sind meine Passwörter sicher.

Edit: Sicherheit auf fail2ban aufzubauen ist natürlich ein Irrglaube!

Keks

 

[marce]

Fakt ist das ich durch den einsatz von fail2ban (welches unter Debian etch natürlich gepatcht ist ) das ddos von ca 500 Versuchen PRO Host und pro Tag, auf insgesamt 5 Versuche pro Host und Tag eindämmen konnte.

DDOS? Der Begriff ist hier falsch. Du meinst einfache Loginversuche.

Gegen (D)DOS-Angriffe hilft fail2ban nicht - kann es auch nicht.

 

[keks]

DDOS? Der Begriff ist hier falsch. Du meinst einfache Loginversuche.

Stimmt, ich meine verteite Bruteforce Angriffe, nicht nur auf den sshD sondern auch auf den Apache/htaccess.