Diese Website existiert nur weil wir Werbung mit AdSense ausliefern.
Bitte den AdBlocker daher auf dieser Website ausschalten! Danke.

SSH: Loginanmeldung verhindern

Alles rund um die Systemverwaltung, die Administration und Konfiguration Eures Linuxsystems

Moderator: Moderatoren

Antworten
horst_skoff
Member
Member
Beiträge: 61
Registriert: 22. Jun 2006, 14:24

SSH: Loginanmeldung verhindern

Beitrag von horst_skoff » 10. Apr 2008, 10:06

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

Werbung:
timotool
Member
Member
Beiträge: 54
Registriert: 18. Jan 2008, 23:49
Wohnort: Dortmund

Beitrag von timotool » 10. Apr 2008, 10:25

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.
Linux: OpenSuse 12.1
Kernel: 3.1.10-4.1_x86_64
System: DL380 G4 2x Xeon 3.6 GHz, 12GB Ram , 5x 300GB HP/Fujitsu SCSI320 10k @ Raid 5 + 1 Hotspare

horst_skoff
Member
Member
Beiträge: 61
Registriert: 22. Jun 2006, 14:24

Beitrag von horst_skoff » 10. Apr 2008, 10:58

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

Benutzeravatar
nbkr
Guru
Guru
Beiträge: 2857
Registriert: 10. Jul 2004, 15:47

Beitrag von nbkr » 10. Apr 2008, 11:04

Installier dir "Denyhosts", das ist genau dafür gedacht. Oder leg den SSH Daemon auf einen anderen Port.
Kann gar nicht sein, ich bin gefürchtet Wald aus, Wald ein.

horst_skoff
Member
Member
Beiträge: 61
Registriert: 22. Jun 2006, 14:24

Beitrag von horst_skoff » 10. Apr 2008, 15:23

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

Benutzeravatar
panamajo
Guru
Guru
Beiträge: 2587
Registriert: 12. Feb 2005, 22:45

Beitrag von panamajo » 10. Apr 2008, 15:39

horst_skoff hat geschrieben: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.
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:

horst_skoff
Member
Member
Beiträge: 61
Registriert: 22. Jun 2006, 14:24

Beitrag von horst_skoff » 10. Apr 2008, 16:20

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

horst_skoff
Member
Member
Beiträge: 61
Registriert: 22. Jun 2006, 14:24

Beitrag von horst_skoff » 10. Apr 2008, 16:30

Ach so villeicht
mit

./denyhosts start –purge

starten richtig?

Benutzeravatar
nbkr
Guru
Guru
Beiträge: 2857
Registriert: 10. Jul 2004, 15:47

Beitrag von nbkr » 10. Apr 2008, 16:46

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.
Kann gar nicht sein, ich bin gefürchtet Wald aus, Wald ein.

horst_skoff
Member
Member
Beiträge: 61
Registriert: 22. Jun 2006, 14:24

Beitrag von horst_skoff » 11. Apr 2008, 07:46

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?

Benutzeravatar
framp
Moderator
Moderator
Beiträge: 4247
Registriert: 6. Jun 2004, 20:57
Wohnort: bei Stuttgart
Kontaktdaten:

Beitrag von framp » 11. Apr 2008, 19:34

horst_skoff hat geschrieben: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?
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 :wink:

horst_skoff
Member
Member
Beiträge: 61
Registriert: 22. Jun 2006, 14:24

Beitrag von horst_skoff » 14. Apr 2008, 09:18

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.

horst_skoff
Member
Member
Beiträge: 61
Registriert: 22. Jun 2006, 14:24

Beitrag von horst_skoff » 29. Apr 2008, 11:59

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

Benutzeravatar
/dev/null
Moderator
Moderator
Beiträge: 1265
Registriert: 4. Sep 2005, 20:02
Wohnort: in Hengasch

Beitrag von /dev/null » 29. Apr 2008, 12:54

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
openSuSE Tumbleweed, Kernel 4.16.x.-desktop x86_64, KDE, Thunderbird 52.7.x
PC: Intel ® Core ™ i5- 2500, NB: TUXEDO Intel ® Core ™ i5- 4340M
S/MIME, denn ich will bestimmen, wer meine Mails lesen kann.
Schau hier: http://www.thunderbird-mail.de

Antworten

Wer ist online?

Mitglieder in diesem Forum: 0 Mitglieder und 1 Gast