RootForum Community

Hallo,

in meiner /var/messages

finde ich haufenweise Loginversuche von allen möglichen IPs die einfach einen User nach dem anderen mit PWds durchzutesten scheinen.

Ich habe einen 1&1 Root-Server mit Suse-Linux und Confixx3

Wie kann ich dafür sorgen, dass eine IP nach 3..4 erfolglosen LogIN-Versuchen für weitere Connects (eine Zeitlang) gesperrt wird?

Wäre toll wenn mir jmd weiterhelfen könnte damit ich ruhiger schlafe...


MFG

Michael

http://fail2ban.sourceforge.net/
Sehr gut, hab ich auch im Einsatz, nachdem ich mit IPTables und co. rumprobiert hatte. Kann nicht nur SSH sondern auch Apache-Logs und funktioniert problemlos.

Benutz mal die Forensuche, ein Perlscript gibt es zu dem Thema, aber frag mich nimmer wo das war. Verlegt am einfachsten den Port und nutze nur noch Preshared Keys zur Anmeldung. Keine Passworteingaben und kein Rootlogin, dann solltest du auf jeden Fall ruhig schlafen können :) Dann hat sich sogar das Script erledigt weil sich dann eh keiner wegen fehlenden Keypair anmelden kann.

Du meinst das: http://linux.newald.de/new_design/login_check.html
Das hat bei mir aber nicht immer zuverlässig funktioniert...
Tut aber im Endeffekt genau das gleiche wie fail2ban, außer dass fail2ban noch nette Mails schickt.

ändere den Port für SSH und dein Log ist leer.

Davon Standardports zu ändern halte ich persönlich gar nichts.

Ich habs über Portknocking gelöst und da ich nichts richtiges im Netz gefunden habe ein Manual geschrieben -> http://www.kai-oesterreich.de/portknocking.html

du kannst dich auch mit Keys einloggen und die Anmeldung mit dem Passwort deaktivieren, dann können die lange nach dem Passwort suchen
Wurde hier auch schon öfter angesprochen, benutze einfach die Forensuche

Hi,

fuer einen Artikel rund um SSH habe ich ein Script gebaut das
genau sowas stoppt. Es blockt neue Verbindungen auf den SSH Port
nach einer vorgegebenen Menge von Versuchen in einer definierten
Zeit. Da weder Aritkel noch das Script bisher offiziell "draussen"
ist, hier nur eine Version ohne Garantie etc. (im Test hat alles
funktioniert, es ist noch nicht alles an errorchecking drin usw. ;)
Bitte nicht damit rumspielen, wenn man sich aussperrt: _warten_!
Achja: Requirements: bash, iptables, ipt_recent, ipt_state
(will heissen: basiert auf IPTables)

Download hier: http://www.sectoor.de/ssh-brute-force-filter.sh.txt

Feedback ist Willkommen.

Gruss und n8,
Darkman

Aber zählen da nicht auch erfolgreiche Verbindungsversuche?

Ja und das ist genau das Problem warum die ip-tables-Lösung bei mir wieder rausgeflogen ist nachdem ich mich mehrmals selbst ausgesperrt hatte.

codc wrote:Davon Standardports zu ändern halte ich persönlich gar nichts.

Ich habs über Portknocking gelöst und da ich nichts richtiges im Netz gefunden habe ein Manual geschrieben -> http://www.kai-oesterreich.de/portknocking.html

Extrem Paranoide können:
Den Port ändern
Portknocker verwenden (Bevorzugt SADoor)
Anmeldung nur mit einen Preshared Key und Passwort, normale Passwortanmeldungen unterbinden
Root den direkten Login verbieten

Ich denke den Portknocker lass ich doch lieber weg ;)

@codc
knockd ist zwar sehr simpel einzurichten, aber dafür kann ich mit SADoor einen Extra Key einrichten der bei der Knocking Sequenze übermittelt werden muss. Wenn schon, dann gleich richtig :)

Alexander Newald wrote:Aber zählen da nicht auch erfolgreiche Verbindungsversuche?

Korrekt. Aus diesem Grund gibt es eine "whitelist" in dem Script.
Du kannst IPs oder IP-Bereiche ausklammern damit diese nicht geblockt
werden. Es reicht meist schon wenn man einen extra Server oder den Dial
In Bereich seines Providers freigibt, da die meisten Brute Force Attacken
aus anderen Servernetzen oder dem Ausland kommen. Damit sollte man
sich also nicht so ohne weiteres aussperren.

Gruss,
Darkman

Hi,

zum Thema Portknocking: ja, ist eine Moeglichkeit, jedoch muss man
beachten (das ist auch ein Grund GEGEN das Aendern von Standard-Ports):
Nicht jedes Netz bietet einem Vollzugriff auf alle Ports, z.B. Hotspots
filtern oftmals alles ausser web, mail und mit Glueck eben SSH, selbiges
gilt fuer Firmen. Dh. von dort aus ist "knocken" unmoeglich. Genauso
schwer wird man ne Regel fuer SSH auf Port 12345 o.ae. bekommen,
schliesslich ist ssh Port 22 ja freigegeben und wenn dann jeder seinen
eigenen Port "erfindet", nunja... als Admin wuerde ichs nicht genehmigen.

Gruss,
Darkman

Limitiert neue SSH-Verbindungen auf 5 pro Minute pro IP (kann für bestimmte Anwendungsfälle zu restriktiv sein).

Lord_Pinhead wrote: @codc
knockd ist zwar sehr simpel einzurichten, aber dafür kann ich mit SADoor einen Extra Key einrichten der bei der Knocking Sequenze übermittelt werden muss. Wenn schon, dann gleich richtig :)

Ich weiss das es bessere Lösungen gibt aber ich hab das auch nur wegen den Log-gespamme eingerichtet. Ohne Keys ist bei mir sowieso kein Login über ssh möglich und root erst recht nicht. Portknocking sozusagen als Logfile-Kosmetik.

aldee wrote:

Code: Select all

$ cat /etc/network/if-up.d/iptables
#!/bin/sh

IPTABLES="/sbin/iptables"

$IPTABLES -A INPUT -p tcp --dport 22 -m state --state NEW -m recent --set --name SSH -j ACCEPT
$IPTABLES -A INPUT -p tcp --dport 22 -m recent --update --seconds 60 --hitcount 5 --rttl --name SSH -j LOG --log-prefix "SSH_flood "
$IPTABLES -A INPUT -p tcp --dport 22 -m recent --update --seconds 60 --hitcount 5 --rttl --name SSH -j REJECT

Limitiert neue SSH-Verbindungen auf 5 pro Minute pro IP (kann für bestimmte Anwendungsfälle zu restriktiv sein).

Bekomme bei der ersten zeile schon folgenden Fehler :

~# IPTABLES -A INPUT -p tcp --dport 22 -m state --state NEW -m recent --set --name SSH -j ACCEPT
iptables: No chain/target/match by that name

Sagt mir leider nix, brauch eure Hilfe weil mir die logs überquellen mit root brute force attacken.

Thx JPsy

Hi,

MrMasterJPsy wrote:Bekomme bei der ersten zeile schon folgenden Fehler :

~# IPTABLES -A INPUT -p tcp --dport 22 -m state --state NEW -m recent --set --name SSH -j ACCEPT
iptables: No chain/target/match by that name

Sagt mir leider nix, brauch eure Hilfe weil mir die logs überquellen mit root brute force attacken.

Das liegt vermutlich daran das Dir irgend ein Support bei IPTables
fehlt. Wenn Du mal im Thread weiter oben guckst, siehst Du ein Script
das ich gepostet habe, das sollte Dir auch sagen welches Modul fehlt.
Wenn Du das fehlende Modul dann weisst, musst Du den entsprechenden Support
nur noch in Deinen Kernel einpflanzen (sofern Du auch iptables selbst
gebaut hast halt auch da).

Gruss,
Darkman

Darkman wrote:Hi,

zum Thema Portknocking: ja, ist eine Moeglichkeit, jedoch muss man
beachten (das ist auch ein Grund GEGEN das Aendern von Standard-Ports):
Nicht jedes Netz bietet einem Vollzugriff auf alle Ports, z.B. Hotspots
filtern oftmals alles ausser web, mail und mit Glueck eben SSH, selbiges
gilt fuer Firmen. Dh. von dort aus ist "knocken" unmoeglich. Genauso
schwer wird man ne Regel fuer SSH auf Port 12345 o.ae. bekommen,
schliesslich ist ssh Port 22 ja freigegeben und wenn dann jeder seinen
eigenen Port "erfindet", nunja... als Admin wuerde ichs nicht genehmigen.

Gruss,
Darkman

Du meinst jetzt wenn ich in der Firma sitze wo ein hoffentlich fähiger Admin mich nicht Routet, sondern ein Proxy vorsetzt, dann ist die SSH eh dicht, egal welcher Port. Portänderung ist eigentlich ein besserer Versuch seine Logfiles sauber zu halten, als mit Portknocking. Ich hab mich schonmal ausgesperrt durch Knocking und das war nur der Simple knockd, von daher mach ich das an Rootserver nicht. Die SSH ist die allerletzte Stelle wo ich mir Sorgen mache das jemand reinkommt. Bots laufen immer auf die 22 an und da bekommen sie bei mir halt nix, das ist der einzige Grund warum ich das mache und er ist sicherer bevor ich mich aus versehen aussperre. Wenn jemand so schlau ist und den Port rausfindet (was ja heute nimmer schwer ist) wird der mir sicher nicht aufn Sack gehen auf die SSH, der versucht es zuerst über Schwachstellen im FTP oder Webserver, das sind die gefährlichereren Punkte um die man sich sorgen machen sollte. Die Einträge in der Logfile können mir Schnuppe sein, immerhin fehlt es dem Angreifer einfach an den Keys und dem dazugehörigen Passwort. Wenn es jetzt jemand manuell versucht wird er es ganz schnell merken ;) Und wenn ein Fehler in der SSH mal wieder bekannt wird, dann laufen hunderte von Bots durchs Netz und versuchen mit Port 22 den Rechner zu kapern, was entweder durch Portknocking und verstecken des Ports verhindert wird, oder einfach nur durch ein simples ändern des Ports. Klar das im ersten moment Knocking besser ist, aber man kann sich sicher auch leicht dadurch ausschliessen. Manche erinnern sich nicht mal mehr an den Port wenn sie Ihn ändern, meinst du die können sich 3 oder 4 merken :D Wie gesagt, man kann es auch echt übertreiben. Man könnte ja auch einfach 2 SSH machen auf 2 Ports. Eine SSH ist ein Fake, einer durch das Portknocking geschützt, ist auch möglich. Wer ein bischen Programmieren kann, kann schnell eine einfache Emulation bauen die dann nix macht als Müll auszugeben, so läuft man nicht gefahr bei einen Exploit doch noch unterlegen zu sein. Aber jeder macht sich seine Mühe mit der Sicherheit, oder auch nicht :) Ein einheitliches Konzept gibt es nicht, nur Tipps was eigentlich Schwachsinn ist, und was nicht. Mein letztes Beispiel ist z.b. eigentlich schon leichter schwachsinn :D

Lord_Pinhead wrote:Du meinst jetzt wenn ich in der Firma sitze wo ein hoffentlich fähiger Admin mich nicht Routet, sondern ein Proxy vorsetzt, dann ist die SSH eh dicht, egal welcher Port.

Nunja, das ist auch nicht so pauschal zu sehen. Wer nen SSHd "braucht",
arbeitet mit hoher Wahrscheinlichkeit im IT-Bereich. In genau jenem
Bereich ist, je nach Firma, es i.d.R. auch entweder eh moeglich auf
Port 22 rauszuconnecten, oder wenig problematisch fuer SSH eine
Freischaltung zu bekommen. Wenn man natuerlich in einer Bank arbeitet,
ists eher unwahrscheinlich das sowas erlaubt ist, da darueber auch
"boeses" reingeroutet werden kann, allerdings kenne ich keinen echten
IT-Professional der es NICHT geschafft hat von der Arbeit aus auf
seine Kiste zu kommen (wobei die wenigen das brauchen, schliesslich
arbeitet man ja und ssh't nicht daheim rum um z.B. mit mutt private
E-Mails zu lesen ;)

Was ich frueher mal genutzt habe um bestimmte Dienste vor Fremdzugriff
zu schuetzen, war ein SSL/htaccess geschuetzer Bereich auf dem Webserver
wo ich meine IP per "klick" in der Firewall hab freischalten koennen
(was nach einer Zeit X dann wieder expired war sofern das Browserfenster
nicht mehr reloaded hat).
Heute wuerde ich so gebastel nicht mehr Einsetzen wenns um wirklich
wichtige Systeme geht, sondern auf eine wirklich "professionelle"*
Loesung zurueckgreifen, also ein VPN.

Gruss,
Darkman

* = Es gibt natuerlich auch sehr simple, einfach aufzusetzende VPN
Loesungen wie z.B. PPTP, diese meine ich hierbei eher weniger ;)

*säufz*

Also das mit nem Script will bei mir nciht klappen... ich werd den port wechseln vom SSH udn versuchen nen Auth key einzubauen.

Hat dazu wer ne verständliche Anleitung ? hab im Webserver Buch zwar eine kurze beshcreibung aber ist nciht wirklich ausführlich wegen dem erstellen der keys...

Thx JPsy

MrMasterJPsy wrote:*säufz*

Also das mit nem Script will bei mir nciht klappen...

Hast Du mein Script probiert? Wenn ja, was fuer ne Fehlermeldung
wirft es denn aus?

Gruss,
Darkman

Sorry, aber dein Scrypt demotiviert mich total - das bekomm ich ncihtmal gestartet, und der sinnvolle hinweis auf "Usage Dateiname.sh start|stop" ist nciht wirklich hilfreich dabei, weil er leider genau das ignoriert...

Es kann doch ncith in hexerei ausarten nur um den SSH login abzusichern... mir war ja klar das es hart wird mit dem Rooty aber das jede Kleinigkeit ein kampf ist mit Linux hab ich echt unterschätzt.

JPsy

ja was gibst du denn bitte ein?! waer z.B. mal ne Massnahme (und vorher bitte konfigurieren.)

Darkman wrote:ja was gibst du denn bitte ein?!

Code: Select all

sh ssh-brute-force-filter.sh start

waer z.B. mal ne Massnahme (und vorher bitte konfigurieren.)

^^ *gg* ich wußte das das nun kommen würde. Ja, hab das Script aber umbenannt - aber daran wirds ja ncith liegen, oder ?

Sonst würd ich ja nciht langsam verzweifeln...

# sh ssh_login.sh start
Looks like you don't know what you're doing ;-)

8O

hiho,

MrMasterJPsy wrote: # sh ssh_login.sh start
Looks like you don't know what you're doing ;-)

haste denn auch das Script konfiguriert .. also nicht nur umbenannt .. sondern mal REINGESCHAUT *G* (*wink mit dem Zaunpfahl*)

greetZ
Cat