PDA

Archiv verlassen und diese Seite im Standarddesign anzeigen : SSH richtig konfigurieren



Eremit
11.05.09, 18:24
Hallo,

auf meinem Server wird dauernd versucht sich per SSH einzuloggen.
Momentan hält der Server noch und das Passwort wurde noch nicht erraten.

sshd[16566]: User root from host5.b5.nw.com... not allowed because not listed in AllowUsers
sshd[16566]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=host5.b5.nw.com... user=root

Nun möchte ich den Server aber weiter abdichten. Dabei möchte ich mich aber mit einem Passwort einloggen.

a) nach 3 Verbindungsversuchen soll von dieser IP keine Verbindung mehr Möglich sein
b) SSH soll sowieso nur zwischen 10 und 22 Uhr erreichbar sein. Vielleicht per cron regelbar?
c) bei meinem Login erscheint immer folgende Meldung:
Last login: Mon May 11 15:55:58 2009 from host-091-096-174-045.ewe-ip-backbone.de
Kann ich nicht überhaupt Verbindungen nur von Ewetel zulassen bzw. in diesem Fall alles von *.ewe-ip-backbone.de?


Hier meine sshd_config:
Port 22
Protocol 2
HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_dsa_key
UsePrivilegeSeparation yes
KeyRegenerationInterval 3600
ServerKeyBits 768
SyslogFacility AUTH
LogLevel INFO
LoginGraceTime 30
PermitRootLogin no
StrictModes yes
MaxAuthTries 2
AllowUsers "username"
MaxStartups 1:80:3
#MaxStartups 1
UseDNS no
RSAAuthentication yes
PubkeyAuthentication yes
#AuthorizedKeysFile %h/.ssh/authorized_keys
IgnoreRhosts yes
# For this to work you will also need host keys in /etc/ssh_known_hosts
RhostsRSAAuthentication no
# similar for protocol version 2
HostbasedAuthentication no
# Uncomment if you don't trust ~/.ssh/known_hosts for RhostsRSAAuthentication
IgnoreUserKnownHosts yes
PermitEmptyPasswords no
ChallengeResponseAuthentication no
#PasswordAuthentication yes
X11Forwarding no
X11DisplayOffset 10
PrintMotd no
PrintLastLog yes
TCPKeepAlive yes
#UseLogin no
Banner /etc/ssh/banner
AcceptEnv LANG LC_*
Subsystem sftp /usr/lib/openssh/sftp-server
UsePAM yes


Hoffe ihr könnt mir bei meinem Problem helfen.

Gruß.

Eremit

derRichard
11.05.09, 18:44
a) nach 3 Verbindungsversuchen soll von dieser IP keine Verbindung mehr Möglich sein
b) SSH soll sowieso nur zwischen 10 und 22 Uhr erreichbar sein. Vielleicht per cron regelbar?
c) bei meinem Login erscheint immer folgende Meldung:
Last login: Mon May 11 15:55:58 2009 from host-091-096-174-045.ewe-ip-backbone.de
Kann ich nicht überhaupt Verbindungen nur von Ewetel zulassen bzw. in diesem Fall alles von *.ewe-ip-backbone.de?

hi!

zu a:
das kannst mit fail2ban machen.
zu b:
iptables kann das. lass nur zwischen 10 und 22 uhr verbindungen zu port 22 zu.
zu c:
ebenfalls iptables oder hosts.allow.

hth,
//richard

corresponder
11.05.09, 19:13
oder ändere einfach den port, dann ist es sicherer.
weil standard anfragen ins leere laufen.


gruss

c.

Rain_maker
11.05.09, 21:00
auf meinem Server wird dauernd versucht sich per SSH einzuloggen.

Und?

"Hintergrundrauschen", der ganz normale Wahnsinn ....



Momentan hält der Server noch und das Passwort wurde noch nicht erraten.

Passwort?



Nun möchte ich den Server aber weiter abdichten. Dabei möchte ich mich aber mit einem Passwort einloggen.

Das widerspricht sich, Login mit keys ist nun mal sicherer, wenn Du einen weiteren Schutz willst, dann lege das Schlüsselpaar mit zusätzlicher Abfrage einer Passphrase für den Key selbst an.

Port verlegen, fail2ban&Co. sind eher kosmetischer Natur, wenn schon, dann würde ich das Problem bei der Wurzel packen.

Eremit
11.05.09, 21:02
Hi,

danke für die Antworten.
Den Port ändern geht zwar aber es wird der Angreifer versucht auf vielen Ports eine Verbindung aufzubauen.
Ich bin mir auch nicht sicher ob ich auf einem VServer einfach IPTables-Routen installieren kann. Daher auch meine Idee mit dem Cron.
10 Uhr /etc/init.d/sshd start
22 Uhr /etc/init.d/sshd stop

Das mit der Hosts.allow sieht ganz interessant aus. Mal sehen ob ich da bestimmte Namensmuster zulassen kann. Die IP an sich ist ja dynamisch. Nur der "Zusatz" scheint immer der gleiche zu sein. Kann man eigentlich an ssh "rumtestesten" ohne sich selber auszuschließen wenn man immer noch eine Konsole auflässt?

fail2ban werde ich mir gleich mal ansehen.

Geändert:
Die Keys wollte ich eben nicht benutzen, da ich mich von verschiedenen Rechnern aus einlogge aber immer mit dem gleichen Provider.

Eremit

Rain_maker
11.05.09, 21:16
Geändert:
Die Keys wollte ich eben nicht benutzen, da ich mich von verschiedenen Rechnern aus einlogge

Und wo ist das Problem? Key mit Passwort schützen und auf den besagten Kisten ablegen und/oder auf USB-Stick mitnehmen.

(Geht für Windowskisten sogar mit einem portablen Putty.)

Gegen Keylogger&Co. auf verseuchten Kisten schützt das natürlich auch nicht, aber das ist bei Passwörtern noch weniger der Fall.



aber immer mit dem gleichen Provider.

Den Zusammenhang zum vorigen Halbsatz verstehe ich nicht.

ThE_FiSh
11.05.09, 21:29
zur vollständigkeit sei noch das portknocking verfahren erwähnt
http://de.wikipedia.org/wiki/Portknocking

Rain_maker
11.05.09, 21:40
Jepp, wobei für alle diese Verfahren gilt, daß sie nur als Ergänzung zum eigentlichen Absichern (Key basierter Login ist IMHO die wichtigste Maßnahme) dienen können und die Gefahr des sich Ausperrens oder des Ausgesperrt Werdens (Gab da ein paar nette DoS-Angriffe auf fail2ban&Co. aufgrund einer Schwachstelle in der Auswertung von Logfiles, die solche Tools vornehmen) automatisch erhöhen.

Mehr Code bedeutet automatisch mehr potentielle Fehler, nur reicht aber eben dummerweise ein Fehler unter Umständen schon aus um das ganze Konzept zu torpedieren.

Ich selbst nutze auch Portknocking, aber wenn z.B. der Demon mal aus irgendeinem Grund rumspinnt/hängt/abschmiert, dann hat man sich erfolgreich ausgesperrt.

HirschHeisseIch
11.05.09, 22:01
Den Port ändern geht zwar aber es wird der Angreifer versucht auf vielen Ports eine Verbindung aufzubauen.
Unterdrückt aber ziemlich erfolgreich das Hintergrund-Rauschen am sshd.


Ich bin mir auch nicht sicher ob ich auf einem VServer einfach IPTables-Routen installieren kann. Daher auch meine Idee mit dem Cron.
10 Uhr /etc/init.d/sshd start
22 Uhr /etc/init.d/sshd stop

Wieso solltest Du keine iptables-Regeln definieren können? Verstehe ich nicht...
Cron würd natürlich auch gehen...

derRichard
11.05.09, 22:21
Wieso solltest Du keine iptables-Regeln definieren können? Verstehe ich nicht...


vserver haben oft einen shared-kernel, da kann man nicht einfach so die iptables-module laden oder regeln anwenden.

//richard

HirschHeisseIch
11.05.09, 22:23
Echt?
Ich dachte bis dato, das sind autarke, virtualisierte Systeme... Man lernt eben nie aus...

FLOST
11.05.09, 22:24
Ich wär Vorsichtig mit dem stoppen des sshd per Cronscript.

Es dürfte nicht lange dauern und du arbeitest an nem akuten Problem und überschreitest die Uhrzeit, dann wird dir die Session unter dem Hintern weggeschossen.

Im Eifer des Gefechtes vergisst man solche Einstellungen schon mal.

Ein gewissen Hintergrundrauschen ist normal - alle dienste, die im Web angeboten werden stehen nahezu dauernd unter Angriffsversuchen, nicht nur der sshd. Wenn du alles gut abgesichert hast, kannst du nur hoffen, dass die von dir verwendete SW keinen akuten Bug enthält.

Ums kurz zu machen - sichere dein System gut ab. Bringe nur Dienste online, die du verstanden hast und überleg dir vorher ein vernünftiges Sicherungskonzept. Mehr kannst du nicht tun - es sei denn du beschäftigst dich mit dem Quellcode.

derRichard
11.05.09, 22:26
Echt?
Ich dachte bis dato, das sind autarke, virtualisierte Systeme... Man lernt eben nie aus...

wir reden hier von crap-vservern, die sind meist nur ein besseres chroot() mit uid-mappern.
kein xen, vmware, hyperv, ...

//richard

403
12.05.09, 19:43
"Key basierter Login ist IMHO die wichtigste Maßnahme"

Das geht auch noch besser mit OTP. YMMV



Ich selbst nutze auch Portknocking, aber wenn z.B. der Demon mal aus irgendeinem Grund rumspinnt/hängt/abschmiert, dann hat man sich erfolgreich ausgesperrt.

Dazu kann man z.B. cron jede Stunde einen check machen lassen.

Knockdemon? Perl als root? ;) Ich hatte mir mal ueberlegt, dass die User eine Mail mit X Schluesselbegriffen senden und dann erst der SSH Port randomisiert aufgemacht wird.
Frage ist ob der Aufwand sich lohnt, solange man das Management Interface hat.

Gruss
403

BedriddenTech
14.05.09, 10:13
Es dürfte nicht lange dauern und du arbeitest an nem akuten Problem und überschreitest die Uhrzeit, dann wird dir die Session unter dem Hintern weggeschossen.

Im Eifer des Gefechtes vergisst man solche Einstellungen schon mal.

Kill mal den sshd während Du angemeldet bist -- Du bist weiter angemeldet. Den sshd alleien zu beenden (mehr machen die meisten Initskripts nicht) ist kein Problem. "service sshd restart" u. ä. gehen auch in einer SSH-Session.

Rain_maker
14.05.09, 19:13
Knockdemon? Perl als root? ;)

Und was willst Du uns damit jetzt sagen? (Mal davon abgesehen, daß es nicht stimmt).


file /usr/sbin/knockd
/usr/sbin/knockd: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), for GNU/Linux 2.6.4, dynamically linked (uses shared libs), stripped

403
15.05.09, 20:24
Und was willst Du uns damit jetzt sagen? (Mal davon abgesehen, daß es nicht stimmt).

andere Implementierung :rolleyes:


file /usr/sbin/knockd
/usr/sbin/knockd: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), for GNU/Linux 2.6.4, dynamically linked (uses shared libs), stripped



, file knockdaemon && ls -l
knockdaemon: perl script text executable
total 208
-rw-r--r-- 1 a u 18011 Feb 12 2003 COPYING
-rw-r--r-- 1 a u 3534 Jul 12 2004 README
-rw-r--r-- 1 a u 311 Jul 6 2004 TODO
drwxr-xr-x 5 a u 4096 Feb 26 2003 doc
-rw-r--r-- 1 a u 19584 Sep 20 2004 documentation
-rwxr-xr-x 1 a u 23126 Sep 20 2004 knockclient
-rw-r--r-- 1 a u 8109 Sep 20 2004 knockclient.conf
-rwxr-xr-x 1 a u 37676 Sep 20 2004 knockdaemon
-rw-r--r-- 1 a u 11754 Sep 20 2004 knockdaemon.conf
-rw-r--r-- 1 a u 62505 Jul 12 2004 portknocking-0.25.tgz


:)

Gruss
403