Login-Versuche bei SSH

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.
 
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 ......
 
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.
 
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.
 
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).

:-)
 
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?
 
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
 
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?
 
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).
 
Zuletzt bearbeitet von einem Moderator:
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
 
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.
 

Ähnliche Themen

Keine grafische Oberfläche (Debian Installation)

SSH Login nur mit einer bestimmten IP die in einer Textdatei gespeichert wird

Welches Linux/Unix für ehemaligen OSX Nutzer?

PATH wird nicht richtig durchsucht

Sicherheitsfragen zu PHP-Anwendungen auf der Webseite

Zurück
Oben