SSH brute force

[manarak]

Habe seit ein Paar wochen tonnenweise SSH brute force dinger in den secure logs (sind jeden Tag mehrere MB gross deswegen). Glücklicherweise sind die activen account mit riesen-passwörtern versehen.

Gibt es irgendwas, womit man die idioten nach dem 3. Versuch von derselben IP oder so für 1 Stunde blockieren kann?

[Roger Wilco]

Gibt es irgendwas, womit man die idioten nach dem 3. Versuch von derselben IP oder so für 1 Stunde blockieren kann?

Ja -> SuFu.

[darkman]

Gibt es irgendwas, womit man die idioten nach dem 3. Versuch von derselben IP oder so für 1 Stunde blockieren kann?

Schau Dir mal das hier an:
http://www.sectoor.de/ssh-brute-force-filter.sh.txt
entsprechende Einstellungen darin vornehmen bevor Du es nutzt.

Gruesse,
Darkman

[manarak]

Danke - ich bekomme jedoch "iptables has no recent module support" als fehlermeldung zurück.
Du must wissen, ich verwende Plesk als Adminhilfe.

[alexander newald]

Versuch mal mein SSH Blocker

http://www.newald.de/index.php?id=305

[manarak]

danke, werd ich machen!

[manarak]

Hallo Alexander

Danke für das Script - es scheint zu funktionieren?

Ich musste noch IPC-shareable installieren.

Dann habe ich das Script per Kommandozeile aufgerufen.
.ipblock wurde im /tmp angelegt.

Muss ich sonst noch was unternehmen?
Wird der IP Blocker bei einem Reboot auch wieder gestartet?

[alexander newald]

Nein, wenn der nicht mit in die rc.d Sctipte eingetragen wird.

[lord_pinhead]

Warum verwendest du nicht einfach ein paar Preshared Keys mit einen Otto Normal User und schaltest das ganz Passwortsystem ab, dann kann man nur noch mit den Preshared Keys auf die Kiste und dazu braucht man (wenn eingestellt) auch das Passwort, jeder der normales Passwortsystem versucht wird gleich abgewiesen. Noch eine Stufe härter ist dann Portknocking, aber nutz mal die Suchfunktion, das wurde hier schon so oft besprochen, sicher deine Kiste lieber wirklich statt dir um ein paar Script Kiddies Sorgen zu machen.

[alexander newald]

Und jeder Benutzer ist gewillt (oder kann) Keys benutzern ? Nicht wirklich...

[lord_pinhead]

Wenn man Putty nutzt ist das kein Aufwand. Die Keys erstellen, das Passwort festlegen in den Keys und den Nutzer sicher zusenden. Der macht mit Putty nur ein Profil und muss wie immer sein PW eingeben, da ist nicht viel Aufwand dahinter.

[oxygen]

Ich denke auch, im Normalfall sind SSH Keys auch für Windows-Otto-Normal User kein Problem. Leute die zu Hause Linux einsetzten, werden das sowieso begrüßen.
Schwierig wird es erst, wenn man unterwegs mal drauf will und halt nicht immer Usb Stick oß mit sich rum schleppt.

[outofbound]

Damit sie ihren Private Key, für den sie keine Phrase angegeben haben, überall hinkopieren? Nein danke. ;)

Gruss,

Out

[lord_pinhead]

Passphrase muss schon sein ;)

[sbkwi]

Ich habe bei mir fail2ban installiert. Gibt es für Debian als Paket, sonst direkt bei fail2ban.sourceforge.net. Die Konfiguration ist relativ einfach und leicht erweiterbar. Ich überwache damit brute force attacks auf ssh, apache und proftpd und habe es so eingestellt, daß eine IP nach drei Fehlversuchen für eine Stunde gesperrt wird. Das hilft!

[tommbutu]

hier noch mehr

http://www.csc.liv.ac.uk/~greg/sshdfilter/

http://nodomain.cc/archives/190-SSH-Bru ... oppen.html

http://denyhosts.sourceforge.net/

What steps can I take to make sshd more secure?

OpenSSH has many settings that can be adjusted in order to increase security. You may wish to refer to OpenSSH security websites or to the many books on the subject. However, here are some things that you may wish to consider based on my experience:

1. Disable logins to root. This can be accomplished by setting the PermitRootLogin setting in the sshd_config file (typically, /etc/ssh/sshd_config).
PermitRootLogin no

2. Disable password logins entirely by editing the PasswordAuthentication setting. By doing so, each user with access to the server will need to create ssh keys (which is beyond the scope of this document).
PasswordAuthentication no

3. Run sshd on a different port. By default, sshd runs on port 22. Most sshd hackers will only attack port 22 so if you run sshd on a different port, the chances of being compromised are reduced dramatically. However, by running sshd on an alternate port requires each user to be aware of this (so if your server is accessed by many user accounts then this solution might not be feasible). To run sshd on an alternate port simply edit the sshd_config and set the Port setting appropriately:
Port 9922

To access yourserver running on port 9922 you would connect using the -p command line option:
$ ssh -p 9922 yourserver

Alternatively, you can edit your $HOME/.ssh/config file or your site-wide /etc/ssh/ssh_config file and add an entry similar to:

Host yourserver
Port 9922

4. Install DenyHosts!

Note: After saving changes to the sshd_config file you will need to restart the sshd server for these settings to take effect

[Outlaw]

Hallo Leute,

ich habe aktuell gerade ne brute force am Hals, bekomme jedoch weder das erstgenannte Skript zum laufen, noch Alexanders, beide mit den bereits genannten Fehlern.

@Alex

Wo bekomme ich diesen IPC-Shareable für SuSE 9.1 her ??

Gruß Outi

[Outlaw]

Wie kann ich den aktuellen BF stoppen ??

Gruß Outi

[Roger Wilco]

Wie kann ich den aktuellen BF stoppen ??

Code: Select all

/etc/init.d/sshd stop

[Outlaw]

Danke, hat sich erledigt, der BF hat aufgehört.

Naja, wenn ich den SSHD stoppe, komme ich ja selbst nicht mehr rein .... ;):D

Hab bei der Gelegenheit noch eine weitere Attacke von heute Nacht entdeckt, die erfolglos blieb. Sonst nix weiter in den Logs, alls paletti ....

Gruß Outi

[Outlaw]

hier noch mehr

http://www.csc.liv.ac.uk/~greg/sshdfilter/

http://nodomain.cc/archives/190-SSH-Bru ... oppen.html

http://denyhosts.sourceforge.net/

What steps can I take to make sshd more secure?

OpenSSH has many settings that can be adjusted in order to increase security. You may wish to refer to OpenSSH security websites or to the many books on the subject. However, here are some things that you may wish to consider based on my experience:

1. Disable logins to root. This can be accomplished by setting the PermitRootLogin setting in the sshd_config file (typically, /etc/ssh/sshd_config).
PermitRootLogin no

2. Disable password logins entirely by editing the PasswordAuthentication setting. By doing so, each user with access to the server will need to create ssh keys (which is beyond the scope of this document).
PasswordAuthentication no

3. Run sshd on a different port. By default, sshd runs on port 22. Most sshd hackers will only attack port 22 so if you run sshd on a different port, the chances of being compromised are reduced dramatically. However, by running sshd on an alternate port requires each user to be aware of this (so if your server is accessed by many user accounts then this solution might not be feasible). To run sshd on an alternate port simply edit the sshd_config and set the Port setting appropriately:
Port 9922

To access yourserver running on port 9922 you would connect using the -p command line option:
$ ssh -p 9922 yourserver

Alternatively, you can edit your $HOME/.ssh/config file or your site-wide /etc/ssh/ssh_config file and add an entry similar to:

Host yourserver
Port 9922

4. Install DenyHosts!

Note: After saving changes to the sshd_config file you will need to restart the sshd server for these settings to take effect

Sehr interesante Geschichte das, werde mir mal alle Punkte nacheinander vornehmen.

Danke für die Hinweise.

Gruß Outi

[alexander newald]

perl -MCPAN -e "install IPC::Shareable"

[lord_pinhead]

@Outlaw
Du kannst einfach den sshd stoppen, sollange du noch eingeloggt bist wird die Verbindung nicht getrennt. Ein kleiner Cronjob der dann den Dienst irgendwann wieder startet ist ja schnell geschrieben. Aber wer Keys nutzt, dem kann das relativ egal sein ;)

[ponchofiesta]

Von dieser Methode mit dem iptables-recent-Modul bin ich ja nicht sehr begeistert. Es hat mich manchmal direkt bei der ersten Verbindung ausgesperrt und nach dem Sperr-Timeout kam ich trotzdem nicht rein. Manchmal hat es abrer auch funktioniert, wie es sollte :roll: