Archiv verlassen und diese Seite im Standarddesign anzeigen : Wie gefährlich ist es, OpenSSH als Server laufen zu lassen
Hi,
ich würde gerne meinen Router via ssh vom Internet aus erreichen können.
Dazu müßte ich auf diesem sshd als Dienst laufen lassen.
Meine Frage ist aber nun, da ich so etwas noch nie gemacht habe, wie sicher das ist.
Welche Sorgen müßte ich mir da machen?
Dann habe ich noch eine weitere Frage:
Mein Router hängt an einer normalen DSL Leitung.
D.h. die IP Adresse wird ständig gewechselt.
Wie kann ich daher von außerhalb wissen, welche IP Adresse mein Rechner gerade hat?
Ich dachte mir, daß ich meinen Router mir eine E-Mail schicken lasse, in dem der Router seine IP reinschreibt, aber wenn ihr da bessere Ideen habt, dann würde ich mir die gerne auch ansehen.
Der Router läuft übrigens unter Linux.
Also die meisten Linux Webserver haben einen offenen SSH-Port. Die Technik ist also bewährt. Du brauchst aber auf jeden Fall ein sicheres Passwort.
Für die IP gibt es mehrere Lösung. Z.B. DynDNS oder was selbst gebasteltes (Rechner postet alle 10 min seine IP auf Webspace).
http://de.wikipedia.org/wiki/DynDNS
Also die meisten Linux Webserver haben einen offenen SSH-Port. Die Technik ist also bewährt. Du brauchst aber auf jeden Fall ein sicheres Passwort.
Also Buchstaben, Zahlen, Zeichen, Klein- und Großschreibung.
Wie lange sollte das Passwort mindestens sein?
Und wie sieht es mit digitalen Schlüsseln aus?
Für die IP gibt es mehrere Lösung. Z.B. DynDNS oder was selbst gebasteltes (Rechner postet alle 10 min seine IP auf Webspace).
http://de.wikipedia.org/wiki/DynDNS
THX, ich werde mir DynDNS mal anschauen.
Ich habe mir das mit DynDNS jetzt mal durchgelesen, da brauch ich doch jetzt eine eigene Domainadresse oder und die kostet Geld?
Gibt es da nichts besseres?
Z.B. so eine Art Webseite die einem zu meinem Router weiterleitet oder die Ip Adresse postet.
z.b. so etwas:
www.lycos.de/user_145466/meine_ip.html
rotalever
2007-11-02, 22:23:06
Ich habe mir das mit DynDNS jetzt mal durchgelesen, da brauch ich doch jetzt eine eigene Domainadresse oder und die kostet Geld?
Nee, brauchst keine Domain und kostet auch kein Geld. Ist halt ne kostenlose subdomain.
(Keine Gewährleistung auf diese Aussage, versteht sich ;))
Habt ihr so etwas?
Wenn ja, wie sieht so eine Domain aus?
D.h. ich kann eine Domainadresse haben die z.b. lautet:
gast.dns1.us
Und kann ich über diesen Namen, also gast.dns1.us,
jeden Dienst erreichen, der auf meinem Router läuft ohne die IP Adresse des Routers direkt angeben zu müssen?
Dann noch eine Frage:
Auf der www.dns1.us Webseite steht folgendes:
You will have the same functionality as these free names - except there will be no ads delivered on your web redirects.
Heißt das, das ich irgendwie Werbung auf meinem Router laufen lassen muß?
Oder wie muß ich das verstehen?
Werbung via ssh ist ja schlecht zu realisieren,
aber nehmen wir mal an, ich würde noch zusätzlich Apache installieren und ne Webseite einrichten. Muß ich dann die Werbung von dns1.us auf meiner Webseite darstellen, damit ich deren dns1 Dienst nutzen darf?
Ich glaube da gibt es noch andere kostenlose DynDNS-Anbieter (auch deutsche) ohne merkwürdige Werbeklauseln.
Ich glaube da gibt es noch andere kostenlose DynDNS-Anbieter (auch deutsche) ohne merkwürdige Werbeklauseln.
Welche würdet ihr empfehlen?
Ich mag solche mit möglichst kurzer und einprägsammer Domain.
Daher dachte ich an dns1.us
Das ist kurz.
varip.srware.net
da gibts was was wohl recht einfach zu konfigurieren is mit webserver und sowas
Morpog
2007-11-03, 01:47:42
dyndns.com, kostenlos und Auswahl für die Subdomain.
Gast hitcher
2007-11-03, 15:56:19
Also Buchstaben, Zahlen, Zeichen, Klein- und Großschreibung.
Wie lange sollte das Passwort mindestens sein?
so um die 12 - 16 Zeichen mit Zahlen, Zeichen und Sonderzeichen ist schon mal ausreichend. Allerdings solltest es noch von Zeit zu Zeit wechseln. Könnte ja auch gestohlen oder ausgespäht werden.
`|<^Ozz-:³C%
zB. ;-)
google
2007-11-03, 16:23:57
das beste ist einfach den standartport auf irgendwas >10000 zu setzten, dann biste geschützt selbst wenn eine Sicherheitslücke bekannt wird, weil normalerweise nur nen portscan auf den standartports gemacht wird.
zusammen mit nem guten Password (>10 zeichen mit Sonderzeichen und zahlen) biste dann schon relativ sicher.
für ganz Paranoide: du kannst jedesmal ne verschlüsselte vpn verbindung zum rechner aufbauen, bevor du auf ssh zugreifst und dann den login nur auf lokale addressen beschränken.
Das kann man dann schon als sehr sicher ansehen. Aber das Problem sitzt meistens eh zwischen Stuhl und Bildschirm :)
klutob
2007-11-03, 17:20:22
das beste ist einfach den standartport auf irgendwas >10000 zu setzten, dann biste geschützt selbst wenn eine Sicherheitslücke bekannt wird, weil normalerweise nur nen portscan auf den standartports gemacht wird.
Man ist bestimmt nicht sicher, wenn man einen Dienst auf einen anderen Port legt, es werden nur die Logfiles um die typischen generischen Login Versuche erleichtert.
Grundsätzlich sollte heute ein von außen erreichbarer SSH-Dienst mindestens folgende Grundkonfiguration besitzen:
- root-Login deaktiviert (einloggen nur über User-ID+su/sudo)
- Passwortauthentifizierung abschalten, stattdessen DSA-Keys verwenden
- SSH v2 verwenden
- root-Login deaktiviert (einloggen nur über User-ID+su/sudo)
Wo ist denn die Sicherheit, wenn ich meinen root Login über su erreiche,
nachdem ich mich als normaler Nutzer eingeloggt habe?
klutob
2007-11-03, 19:00:38
Wo ist denn die Sicherheit, wenn ich meinen root Login über su erreiche,
nachdem ich mich als normaler Nutzer eingeloggt habe?
Der potentielle Angreifer muß zuerst die Key-Authentifikation brechen, um sich als eingeschränkter User/admin einloggen zu können und zusätzlich! die Passphrase des "root" Accounts kennen um das System zu manipulieren.
Weiterhin fallen die generischen root-Login Angriffe aus den Logfiles.
Der potentielle Angreifer muß zuerst die Key-Authentifikation brechen, um sich als eingeschränkter User/admin einloggen zu können und zusätzlich! die Passphrase des "root" Accounts kennen um das System zu manipulieren.
Weiterhin fallen die generischen root-Login Angriffe aus den Logfiles.
Meine Frage bezog sich nicht auf die Key-Auth. sondern auf den Root Login über su.
Wo ist der Unterschied zwischen einem direkten root login und einem indirekten über su?
Das will ich wissen.
Man muß 2 PW knacken, die des Users und die von Root, aber wenn man erstmal User ist, dann dürfte man leichtes Spiel haben über eine lokale Sicherheitslücke in den Root Account zu kommen.
schau dir mal ssl-explorer an: hhttp://sourceforge.net/projects/sslexplorer/
Wo ist der Unterschied zwischen einem direkten root login und einem indirekten über su?
Das will ich wissen.
Man muß 2 PW knacken, die des Users und die von Root, aber wenn man erstmal User ist, dann dürfte man leichtes Spiel haben über eine lokale Sicherheitslücke in den Root Account zu kommen.
1. Man muß zuerst den mit einem Paßwort gesicherten privaten Schlüssel des Nutzers brechen um auf den Server zu kommen und anschließend das Systempaßwort dieses Nutzers oder des root-Kontos ermitteln um Superuser-Rechte zu erhalten. Der zweite Schritt ist zwar in der Regel einfacher zu erledigen als der erste, aber solange der Server regelmäßig aktualisiert wird handelt es sich dabei nicht um "leichtes Spiel", sondern um eine zweite Hürde.
2. Zum Zugriff auf das System muß man nicht nur das Paßwort oder den privaten Schlüssel ermitteln, sondern auch noch den Kontonamen des Nutzers. Der Name "root" ist hingegen bekannt.
3. Handelt es sich um ein System mit vielen Nutzern, sollte sich sowieso niemand als root anmelden, da dieses Konto keiner natürlichen Person zugeordnet ist. Es wäre daher schwierig nachzuvollziehen welche Person jeweils administrative Änderungen durchgeführt hat und ebenso schwierig einzelnen Personen den Administrationszugang wieder zu entziehen.
Grundsätzliches Vorgehen zum Absichern von SSH (konkret OpenSSH welches die meisten verwenden): Handbuch hernehmen (man ssh_config), alle Optionen der Reihe nach durcharbeiten und jede in der zugehörigen Konfigurationsdatei (zB /etc/sshd.conf) möglichst restriktiv konfigurieren, dh alles was nicht unbedingt benötigt wird abschalten, deaktivieren, dichtmachen.
Alternativ kann man auch nach "hardening ssh" oder ähnlichen suchen, aber letztlich werden in den Artikeln jeweils immer nur einzelne Aspekte beleuchtet.
Das wichtigste ist IMHO ausschließlich SSH Version 2 zuzulassen, Schlüssel zu verwenden und das paßwortbasierte Anmelden zu verbieten sowie zusätzlich das Anmelden auf bestimmte Nutzer bzw Gruppen zu begrenzen. Sonst passier es, daß irgendwann mal zum Ausprobieren eines neues Dienstes ein Konto "test/test" angelegt wird und genau in der Stunde, in der man damit rumspielt, meldet sich ein Angreifer mit diesen Daten an.
2. Zum Zugriff auf das System muß man nicht nur das Paßwort oder den privaten Schlüssel ermitteln, sondern auch noch den Kontonamen des Nutzers. Der Name "root" ist hingegen bekannt.
Ok, das leuchtet ein.
Die anderen Punkte sind nicht so relevant, IMO.
ssh steht naturgemäss immer im Fokus und es werden regelmässig Schwachstellen entdeckt, so ist es durchaus empfehlenswert sshd noch zusätzlich zu dem Vorgenannten in einer Art stealthmodus zu betreiben. So ermöglicht es ein vorgeschalteter knock-deamon den Rechner im Netz zu haben, ohne von aussen sichtbare Dienste anzubieten. Erst auf eine bestimmte knock(Anklopf)-sequenz wird der ssh-Zugang für die entsprechende session freigeschaltet.
So ermöglicht es ein vorgeschalteter knock-deamon den Rechner im Netz zu haben, ohne von aussen sichtbare Dienste anzubieten. Erst auf eine bestimmte knock(Anklopf)-sequenz wird der ssh-Zugang für die entsprechende session freigeschaltet.
Klingt interessant und was brauche ich dafür?
Als Firewall verwende ich IPTables.
Die IP Adressen von denen ich auf den Rechner zugreifen möchte können aber dynamisch vergeben werden, d.h. ich kann den IP Bereich kaum einschränken.
Könnte eine Chroot umgebung nicht auch noch eine weiter Hürde darstellen?
So ermöglicht es ein vorgeschalteter knock-deamon den Rechner im Netz zu haben, ohne von aussen sichtbare Dienste anzubieten.
Das ist bei einem Server der von verschiedenen und vor allem wechselnden Personen genutzt wird allerdings nicht praktikabel. Auch wenn man nur selbst auf den Server zugreift ist das ständige Anklopfen schon nervig, vor allem wenn man nicht an seinem eigenen Rechner sitzt.
Klingt interessant und was brauche ich dafür?
Als Firewall verwende ich IPTables.
Beispielsweise: http://www.debian-administration.org/articles/268
Bei ner Suchmaschine nach "port knocking" oder "knockd" zu suchen gibt dir genügend Anleitungen.
Die IP Adressen von denen ich auf den Rechner zugreifen möchte können aber dynamisch vergeben werden, d.h. ich kann den IP Bereich kaum einschränken.
Kannst du die Zugriffe nicht wenigstens auf bestimmte Länder beschränken? Oder müssen Chinesen auf deinen Rechner zugreifen können?
http://www.debian-administration.org/articles/518
Könnte eine Chroot umgebung nicht auch noch eine weiter Hürde darstellen?
Naja "chroot" unter Linux ist nicht gerade die sicherste Methode. Außerdem schränkt das den Einsatz von SSH sehr ein.
gentoo
2007-11-11, 03:07:35
Ich verwende seit drei Jahren 24/7 einen Server mit ssh-zugang
Meine Empfehlungen die mir bis jetzt einen Einbruch erspart haben:
- Passwörter mit Sonderzeichen und Groß/Kleinschreibung
Der Vorteil liegt darin, daß meistens mit Passwortlisten versucht wird
den Server zu hacken.
-Eine restriktive sshd_config
Wenn du z.B keine root-logins erlaubst oder kein X-forwarding
unterstützt, bietest du weniger Angriffsmöglichkeiten um Sicherheitslücken ausnutzen zu können.
-Denyhosts
Dieses Tool verhindert eine weitere Verbindung von einer IP die
mehr als eine bestimmte Anzahl an User/Passwort Kombinationen probiert hat.
-Immer eine aktuelle ssh-serverapplikation
Jeder Bug sollte möglichst schnell gestopft werden.
Hoffe es hilft weiter;)
lg,
gentoo
vBulletin®, Copyright ©2000-2024, Jelsoft Enterprises Ltd.