Einbruchversuche über SSH (dropbear)

[hermann72pb]

...Wenn ich dann nicht noch so unendlich faul wäre, würde ich das gleich mal implementieren...

Daran scheitert es... Außerdem streng und paranoidal genommen scheitert dein Konzept daran, dass das Ganze NUR mit einer 4-Stelligen PIN (ich spinne mal so) abgesichert ist und nur für den eigentlichen Benutzer die meiste Hürde darstellt, nicht für den Angreifer.

Klar, lässt sich einiges aus deinen Vorschlägen teilweise implementieren, aber ob man es will... Z.B. könnte man auch jetzt denken per Anruf dropbear überhaupt erst zu starten und nach einer gewissen Zeit per cron oder wie auch immer wieder stoppen. Aber dropbear ist für die meisten sozusagen Schweizer Messer der Box und der Wunsch ist, dass er meistens rum um die Uhr verfügbar ist.

MfG

 

[rcb]

Ich mache es ruf per Hnady meine Box an dort ist meine HandyNummer ID hinter legt. Gib mein PIN ein und gib danach den Tele-Code für starten SSH ein. Kan mich dann auf mein Router anmelden und arbeiten. Wenn ich mich ausgeloggt hab ruf ich wieder meine Router an und deaktiviere per Tele-Code ssh und das geht bei mir sehr gut.

Was soll oder will man da noch implentieren..

 

[u.g]

Ich starte dropbear auch nur, wenn ich ihn benötige und stoppe ihn danach wieder.
Früher habe ich das über Anruf gestartet.
Heute mache ich es über ein php-Script auf dem Webserver der FB,
welches ich vorher aufrufe. Ist zwar nicht soo supersicher, aber mir reicht es.

 

[RalfFriedl]

Wenn man ein vernünftiges Paßwort auf der Box hat (noch besser public key), dann braucht man sich darum keine Sorgen zu machen.

Ich habe bisher noch nicht erlebt, daß tatsächlich versucht wurde, ein Paßwort zu raten. Vielmehr wurde versucht, verschiedenste Benutzernamen durchzuprobieren, vielleicht in der Hoffnung, daß es einen gibt, bei dem kein Paßwort gesetzt ist.

Ein Problem, das bereits angesprochen wurde, ist, daß durch den Aufbau der verschlüsselten Verbindung soviel CPU-Last erzeugt wird, daß die Box nicht mehr richtig läuft oder neu startet. Dagegen hilft aber nicht, das Anmelden zu verkomplizieren. Die einfachste Lösung dafür ist, einen anderen Port zu verwenden.

 

[timothy]

Nicht getestet, aber einen Versuch wert

Ich weiß allerdings nicht, ob das in der jeweiligen Box funktioniert ! Gefunden hier: http://www.linuxquestions.org/quest...o-block-failed-attempts-by-ip-address-342359/

Hi,

here's an easy fix. It drops new ssh connections coming from the same IP with less than 15s intervals (or any timeout you want). In my server, this has shown to stop the automated attempts on the first failed connection - and even if the attacker waits for the 15s, it makes brute-force attempts not practical.

For legit sessions, 15s is reasonable (at least for me) between session starts.

It's just two lines on the iptables configuration. No other change required:

iptables -A INPUT -p tcp -i eth0 -m state --state NEW --dport 22 -m recent --update --seconds 15 -j DROP
iptables -A INPUT -p tcp -i eth0 -m state --state NEW --dport 22 -m recent --set -j ACCEPT

(eth0 is my external interface; I'm not limiting intranet connections)

This assumes you already have
iptables -A INPUT -j ACCEPT -p tcp ! --syn -s <REMOTENET> -d <OUTERNET>
above that, to accept established connection packets.

BR,

Joao S Veiga

 

[RalfFriedl]

Ein interessanter Ansatz, aber es heißt, daß iptables auf der Box nicht übermäßig stabil läuft (der Kernel ist schon etwas älter).

 

[cuma]

iptables selbst funktioniert problemlos, nur das Modul CONNTRACK, von welchem viele andere abhängig sind (auch recent??), verursacht reboots.

 

[RalfFriedl]

Und vermutlich auch das verwendete Modul "state". Um zu wissen, in welchem Zustand die Verbindung ist, braucht man Informationen zur Verbindung.