SSH: Loginanmeldung verhindern

Hey !

Ich habe das Problem, das mein Root-Server immer häufiger Brute Force Angriffen aus gesetzt ist. (Wie wahrscheinlich vile andere auch)
Nun habe schon versucht Vorkehrungen zu treffen um dieses zu verhindern.

Zum einen habe ich einen zusätzlich RSA-Pulic/ Private-Key generiert und den entsprechen eingefügt.

Und die sshd.conf entsprehend konfiguiriert mit:

Nur PublicKeyAuth auf yes
den Rest auf no

MaxStartUps auf 2:80:3
usw.

Eigentlich alles was das Internet hierfür an Empfehlungen hergibt.

Was ich erwarten würde ist:
Das gerade wenn der potentielle Benutzter (krimineller Angreifer oder nicht) den privaten schlüssel nicht besitzt der Verbindungsversuch zu dem Rechner sofort abgelehnt wird.
Was aber passiert ist:
Das ich trotz allem wenn ich z.B. über putty oder WinScp teste oder ich mir mein Log-File anschaue (alle Tests ohne privaten Schlüssel), das sowohl ich als auch diese kriminellen es immer schaffen noch den user einzugeben. Erst dann wird alles weitere abgelehnt.

Warum ist das denn so?

Kann ich genaueres denn irgendwo nachlesen warum?
Ich will es ja verstehen!
habe ich etwas verkehrt gemacht.

Ich hab zum Schluss noch das Script sshblock.sh heruntergeladen und bei mir lokal auf einem Linux getestet aber auch hier, komme ich immer noch zur Aufforderung der Eingabe des Benutzters.

Wer weis nun weiter?

Gruß Horst

Der "Angreifer" schafft es nicht einen Username einzugeben, sondern das Brute Force Script connected sich gleich mit einem Username... Da sitzt niemand am Rechzner und startet von Hand einen Versuch nach dem anderen. Das sind Script-Kiddies die ein entsprechendes Script laufen lassen und so ihr "Wörterbuch" durchlaufen lassen.

Da diese Scripts immer mit dem Standartport arbeiten, ist es hilfreich den ssh server einfach auf einen anderen Port "hören" zu lassen.

Aber wieso tauchen diese login-Versuche in meiner Log-Datei auf, wenn die gar nicht soweit kommen?
Und warum komme ich denn wenn ich meinen putty oder mit meinem scp zum LogIn-Aufforderung wenn ich keinen Privaten-Schlüssel mit angebe?


Und warum schaffen die Angreifer sich zehn oder mehrmals zu connecten obwohl ich die MaxStartUp auf 3 oder weniger beschränke.
Oder kann er das auch nicht es wir nur protokolliert.

Und wie kann solche Einträge verhindern, die ja meine Log-Datei "zumüllen"?

Ich denke dann wir jede weiterer Verbindungsversuch der von der gleichen IP kommt abgelehnt.
Auch habe ich gedacht das zusätzlich sshblock.sh Script würde mir das abnehmen.
Aber das verhalten bei dem Start von putty oder scp ist das gleiche.

Mache was verehrt oder nur was nicht richtig.


Gibt es Lektüre (online oder nicht), darüber?
Ich will es ja verstehen lund lernen wie ich so etwas sinnvoll aufhalten abwehren kann?


Horst

Installier dir "Denyhosts", das ist genau dafür gedacht. Oder leg den SSH Daemon auf einen anderen Port.

Gut das mit dem dem anderen Port ist eine Idee.
Mit dem denyhost ist das solche Sache. Da wenn ich z.B. von zuhause auf meinen root-server schauen will komme ich über eine dynamisch vergebene IP-Adresse und dann komme ich in Schwierigekeiten. Oder gibt es da einen Trick, den ich nicht erkannt habe.


Das was ich aber immer noch nicht verstehe wieso komme ich wenn ich mit dem RSA-Privat/Public-key arbeite oder wenn ich die Anzahl der Anmeldungen einschränke in der sshd.config einschränke:

immer noch mit meinem Putty/ SCP zum LogIn-Fenster?

Der Key-Informationen werden doch beim Aufbau der Verbindungen gesendet, und nicht erst nach der eingabe des Benutzers, oder irre ich da?

Wieso wird das wie beim z.B. Denyhost nicht auch geblockt?

Ich würde das gerne verstehen.

Vielleicht hat ja doch noch jemand Lektüre zur Empfehlung für mich oder einen Link in der Hinterhand?

Horst

horst_skoff schrieb:

Da wenn ich z.B. von zuhause auf meinen root-server schauen will komme ich über eine dynamisch vergebene IP-Adresse und dann komme ich in Schwierigekeiten.

Zum Vergrößern anklicken....

Wieso?
Denkbar wäre zwar dass du eine IP bekommst die vorher jemand für eine Brute Force Attacke genutzt hat und deshalb geblockt wirst.
In der Praxis ist mir das noch nie passiert. Wenn ich mir die DenyHosts Logs ansehe würde ich sagen das dies nur passieren kann wenn dein ISP in China, Indien, Südkorea, Taiwan, Russland oder den USA ist. :mrgreen:

O.K.
Vielleicht bin ich da ja verkehrt angegengen.

Wenn ich nicht meine hosts.allow bzw.hosts.deny konfiguriere.

Dann komme ich genau einmal per ssh auf meinen Server.
Danach steht meine IP in der hosts.deny und das war dann.
setzte ich
PURGE_DENY = 1m
Dann komme ich gar nicht mehr rauf!

Ich habe also meine IP-Adresse bzw. die IP-Adressen aus meinen Netz
in der hosts.allow mit
sshd 192.168.0.* : ALLOW

freigegeben und in der deny.host ebenfalls

sshd: 192.168.0.* : ALLOW


Wenn ich also eine dynamische IP-bekomme komme ich meines erachtes ja auch nur einmal drauf und das war es dann.
Wie,wann und wird überhaupt die IP-Adresse wieder aus der hosts.deny ausgetragen.


Habe ich vielleicht einen Konfigurationsfehler gemacht?



Horst

Ach so villeicht
mit

./denyhosts start –purge

starten richtig?

Ich gehe mal davon aus, dass es sich beim Server um einen handelt der in einem Rechenzentrum steht, nicht bei dir unterm Schreibtisch. Wenn Du dann auch kein VPN hast, so ist die Angabe der IP 192.168.0.* extrem sinnlos, denn solche privaten Adressen werden im Internet nicht geroutet. Dein Server wird also niemals eine solche Adresse sehen.

Ja der Server steht im RZ
Nein mit der IP-Adresse war ja auch nur ein Beispiel.
Da hier einen Referenz-Server habe auf dem ich zu Testzwecken die gleiche Konfiguration habe. Deswegen die 192.168. Adresse als Beispiel.

Wenn ich im RZ einen Fehler mache, dann darf ich die Jungs von der Feuerwehr anrufen, um das zu reparieren.

Meine wichtigste Fragen bleiben aber noch:
Das was ich aber immer noch nicht verstehe wieso komme ich wenn ich mit dem RSA-Privat/Public-key arbeite oder wenn ich die Anzahl der Anmeldungen einschränke in der sshd.config einschränke noch mit meinem Putty/ SCP zum LogIn-Fenster?

Der Key-Informationen werden doch beim Aufbau der Verbindungen gesendet, und nicht erst nach der Eingabe des Benutzers, oder irre ich da?

Wieso wird das wie beim z.B. Denyhost nicht auch geblockt, sondern als LogIn Versuch protokloiert, wenn die über die automatischen Brute-Force-Scripte nicht bis zum LogIn kommen sollten.

Ich würde das gerne verstehen.
Durch eine Lektüre oder/ und einen Link , wo ich mich einlesen kann?

horst_skoff schrieb:

Meine wichtigste Fragen bleiben aber noch:
Das was ich aber immer noch nicht verstehe wieso komme ich wenn ich mit dem RSA-Privat/Public-key arbeite oder wenn ich die Anzahl der Anmeldungen einschränke in der sshd.config einschränke noch mit meinem Putty/ SCP zum LogIn-Fenster?

Zum Vergrößern anklicken....

Vermutlich irgendwas in der sshd_config falsch gesetzt.

Hast Du mal hier im LC Wiki nachgelesen? Das steht im Detail beschrieben wie man mit putty einen ssh Server mit einem Key dicht macht ... und ein Step beschreibt wie man den Password Logon ausschaltet. Prüf mal Deine Config dagegen

Hey meines ist die ssd.conf korrekt.

Aber vielleicht übersehe ich etwas!?!

ich sende Sie deswegen noch mal mit.

Vielleicht hat jemand Zeit ein Auge drauf zu werfen.

---------------------------sshd.conf----------------------------

# $OpenBSD: sshd_config,v 1.70 2004/12/23 23:11:00 djm Exp $

# This is the sshd server system-wide configuration file. See
# sshd_config(5) for more information.

# This sshd was compiled with PATH=/usr/bin:/bin:/usr/sbin:/sbin

# The strategy used for options in the default sshd_config shipped with
# OpenSSH is to specify options with their default value where
# possible, but leave them commented. Uncommented options change a
# default value.


Port 22

Protocol 2


LogLevel INFO

# Authentication:
PubkeyAuthentication yes

AuthorizedKeysFile /etc/ssh/authorized_keys


# For this to work you will also need host keys in /etc/ssh/ssh_known_hosts

# To disable tunneled clear text passwords, change to no here!
PasswordAuthentication no
PermitEmptyPasswords no
ChallengeResponseAuthentication no
UsePAM no
X11Forwarding yes
PermitRootLogin no
AllowUsers myuser
ClientAliveCountMax 2
MaxAuthTries 1
MaxStartups 3:80:4
LoginGraceTime 15
PermitEmptyPasswords no
PrintLastLog yes
# override default of no subsystems
Subsystem sftp /usr/lib/ssh/sftp-server

# This enables accepting locale enviroment variables LC_* LANG, see sshd_config(5).
AcceptEnv LANG LC_CTYPE LC_NUMERIC LC_TIME LC_COLLATE LC_MONETARY LC_MESSAGES
AcceptEnv LC_PAPER LC_NAME LC_ADDRESS LC_TELEPHONE LC_MEASUREMENT
AcceptEnv LC_IDENTIFICATION LC_ALL

---------- sshd.conf ende------------

Alles was hier nicht mit aufgeführt ist, ist auskommentiert und habe zu besseren Lesbarkeit weggelassen.

habe jetzt seid 1 1/2 Wochen mein SSH-Port geändert.
Seitdem ist ruhe.

Die Frage nur wie lange.

Trotzdem hätte ich das andere gerne Verstehen gelernt.

mmh...

Hi Horst,

ich sehe in deiner conf, dass du wohl an alles gedacht hast. Sogar an die Begrenzung auf einen einzigen Fehlversuch (reicht ja auch bei PubkeyAuthentication völlig ...).

Ich kann jetzt nur von SUSE sprechen.
Selbst bei einem derartig gesicherten Zugang wird jeder ungültige Versuch im Sicherheitslog gespeichert. Der "Angreifer" kommt bei deiner/(meiner) Konfiguration zwar nicht ins Netz, aber er müllt uns das Log voll.
Um das zu vermeiden, habe ich mir fail2ban installiert. Es wertet /var/log/messages aus und legt für ein paar Minuten passende temporäre Firewallregeln an. Ist also im Prinzip mit DenyHosts zu vergleichen, sperrt aber an anderer Stelle (und wertet neben ssh- auch noch weitere Angriffe aus).
Ergebnis: jeder Spielmatz bringt mir nur einen einzigen Logeintrag.

Aber um das nochmals klar zu sagen: Die eigentliche Sicherheit machst du mit der PubkeyAuthentication und den anderen Sicherheitseinstellungen. Das Blockieren der IP behindert durch ordentliche Verzögerung natürlich auch ... .

Nebenbei: das Verbiegen des Ports nenne ich gern "Verstecken spielen" ... . An Sicherheit gewinnst du dabei nichts, es hält max. das Log klein.

MfG Peter