staging.inyokaproject.org

Ich möchte gegen Ende des Jahres einen Root Server (oder vRoot) einrichten. Bis dahin habe ich Ubuntu 10.04 lokal in einer VirtualBox laufen.

Ich habe jetzt nur eine Ubuntu Server Grundinstallation gemacht ohne jegliche Dienste. Lediglich das Paket openssl-server habe ich nachinstalliert. Damit ist Port 22 offen.

Der erste Schritt und damit meine erste Frage: wie bekommt man Port 22 möglichst sicher? Es gab dazu mal im Planeten zwei Artikel

Am wichtigsten und sinnvollsten ist wohl fail2ban, weil man damit auch noch andere Dienste schützen kann. Den Umgang mit den Keyfiles habe ich leider noch nicht so ganz verstanden

Zu PermitRootLogin hätte ich noch eine Frage: wie administriert man dann das System noch, wenn man keine Root Rechte hat?

burli schrieb:

Ich möchte gegen Ende des Jahres einen Root Server (oder vRoot) einrichten. Bis dahin habe ich Ubuntu 10.04 lokal in einer VirtualBox laufen.

Überlege Dir bitte gut, was Du machst. Du haftest für nahezu alles, was von Deinem Server ausgeht.

Am wichtigsten und sinnvollsten ist wohl fail2ban, weil man damit auch noch andere Dienste schützen kann. Den Umgang mit den Keyfiles habe ich leider noch nicht so ganz verstanden

Zu den Keyfiles hatte ich mal einen Artikel im Blog.

Zu PermitRootLogin hätte ich noch eine Frage: wie administriert man dann das System noch, wenn man keine Root Rechte hat?

Es gibt ja sudo. Du meldest Dich als user an und kannst mit "sudo -i" eine root-Shell bekommen.

Der Ubuntu Server Guide ist vielleicht einen Blick wert.

Gruss

Dirk

Lux schrieb:

Überlege Dir bitte gut, was Du machst. Du haftest für nahezu alles, was von Deinem Server ausgeht.

Das ist mir klar. Das ist der Grund, warum ich bisher davon Abstand genommen habe und wieso ich das mit größter Sorgfalt vorbereiten möchte. Deshalb habe ich nicht gleich nach allem möglichen gefragt sondern ich möchte gezielt und Schritt für Schritt jeden einzelnen Punkt abarbeiten.

Zu den Keyfiles hatte ich mal einen Artikel im Blog.

Danke, werd ich mal lesen

Es gibt ja sudo. Du meldest Dich als user an und kannst mit "sudo -i" eine root-Shell bekommen.

So lange der User das gleiche Passwort wie der Login hat ist das doch aber nutzlos, oder? Ich muss also Login User und Root voneinander trennen

Der Ubuntu Server Guide ist vielleicht einen Blick wert.

Stimmt, gar nicht mehr dran gedacht. Danke für den Hinweis.

burli schrieb:

Es gibt ja sudo. Du meldest Dich als user an und kannst mit "sudo -i" eine root-Shell bekommen.

So lange der User das gleiche Passwort wie der Login hat ist das doch aber nutzlos, oder? Ich muss also Login User und Root voneinander trennen

Nein.

Du brauchst ein Key-File und ein Passwort für das Keyfile zum Anmelden und erst, wenn das funktioniert hat, brauchst Du Passort des Users, um root werden zu können.

Gruss

Dirk

Ich nutze Denyhost zum SSH absichern, leider ist der Artikel obwohl er aktuell ist in's letzte Eck verschoben: Baustelle/Verlassen/DenyHosts aber hier mal das wichtigste:

## denyhost ##
 #blocken:
nano /etc/hosts.deny
 #zulassen:
nano /etc/hosts.allow
 #alle eingetragenen entfernen:
/etc/init.d/denyhosts stop
denyhosts --purge 
/etc/init.d/denyhosts start
 #konfigurieren:
nano /etc/denyhosts.conf

Hier kannst du sehen wer sich versucht hat einzuloggen:

#ssh#
grep sshd /var/log/auth.log
oder:
zless /var/log/auth.log.*.gz | grep sshd
zless /var/log/auth.log.*.gz | grep Accepted

und den Standartport 22 kannst du auch ändern wenn du ganz sicher gehen willst, in der Datei "/etc/ssh/sshd_config", danach musst du dich halt mit der Zusatzoption "-p DEINNEUERPORT" anmelden.

Zu fail2ban und warum man es vielleicht nicht nutzen sollte kannst du folgenden Artikel lesen. (Den Link zum Artikel habe ich übrigens auf rootforum.org entdeckt, dort ein wenig zu blättern kann auch nicht schaden)

Ok, dass heißt, sowohl mit Denyhost als auch fail2ban kann man sich eher noch zusätzliche Löcher einfangen, ähnlich wie mit Firewalls unter Windows. Frei nach dem Motto, weniger ist manchmal mehr.

Also mal zusammenfassen: die wichtigste Maßnahme ist logischerweise ein sicheres Passwort gefolgt von PermitRootLogin. Ich habe nur das, was Lux erklärt hat, noch nicht ganz verstanden. Gibt es im Wiki oder irgendwo dazu was, wie man das einrichtet?

hm, ich verstehe die Sicherheitsbedenken bei DenyHosts nicht, es kommt doch keiner an die log-Dateien ran und auch wenn, hätte er ja nur in ganz bestimmten Fällen den Namen des Benutzers!?

burli schrieb:

Gibt es im Wiki oder irgendwo dazu was, wie man das einrichtet?

SSH (Abschnitt „Authentifizierung-ueber-Public-Keys“)

@bongobong: Im Artikel wird am Beispiel vom SSH Server gezeigt, was passiert, wenn man ein falsches Protokoll benutzt. Per "nc" sendet man dem SSH Server z.B. die Nachricht "User root from 192.168.5.1 not allowed because none of user’s groups are listed in AllowGroups". Blöderweise loggt der SSH Server die Zeichenkette, die empfangen wurde, und ein Log analyse Tool springt auf die Zeile an und sperrt für den entsprechenden Nutzer den SSH Zugang. Statt der IP lässt sich hier auch "all" einsetzen, und SSH ist komplett dicht.

Wie im Artikel erwähnt kann man das mit SQL Injections vergleichen, man muss daran denken dass die Logs Nutzereingaben enthalten, welchen man keinesfalls vertrauen darf - und bei einem schlecht programmierten Log analyse Tool können daher zusätzlich Sicherheitslöcher entstehen.

bongobong schrieb:

hm, ich verstehe die Sicherheitsbedenken bei DenyHosts nicht, es kommt doch keiner an die log-Dateien ran und auch wenn, hätte er ja nur in ganz bestimmten Fällen den Namen des Benutzers!?

Wenn ich das richtig verstanden habe werden Zugriffe mitgeloggt. Wenn Denyhosts läuft parst er diese Logs und führt anscheinend irgendwelche Befehle aus, die letztendlich irgendwelche Config Dateien ändern, wenn die richtigen Befehle da drin stehen

burli schrieb:

Ich habe nur das, was Lux erklärt hat, noch nicht ganz verstanden. Gibt es im Wiki oder irgendwo dazu was, wie man das einrichtet?

Was genau hast Du nicht verstanden?

Gruss

Dirk

Lux schrieb:

Was genau hast Du nicht verstanden?

Ich bin noch etwas verwirrt. Ich muss das erstmal sortieren, deshalb mal eins nach dem anderen.

Erstmal grundsätzlich zur Authentifizierung über SSH mit Public-Key: ich muss auf jedem Client Rechner, der Zugriff auf den SSH-Server erhalten soll, einen Schlüssel generieren und den dabei erzeugten Public Key auf den Server hochladen. Soweit richtig?

Dabei hab ich das Problem, dass ich nur von den Rechnern aus Zugriff habe, für die ein entsprechender Public Key vorliegt. Außerdem sperre ich mich selbst aus, sollte ich, warum auch immer, den Private Key verlieren. Soweit auch richtig?

Das ganze hat mit PermitRootLogin erstmal nichts zu tun, oder?

burli schrieb:

Erstmal grundsätzlich zur Authentifizierung über SSH mit Public-Key: ich muss auf jedem Client Rechner, der Zugriff auf den SSH-Server erhalten soll, einen Schlüssel generieren und den dabei erzeugten Public Key auf den Server hochladen. Soweit richtig?

Auf jedem Client-Rechner machst Du ein

ssh-keygen
ssh-copy-id -i ~/.ssh/id_rsa.pub deinuser@deinserver

richtig!

Dabei hab ich das Problem, dass ich nur von den Rechnern aus Zugriff habe, für die ein entsprechender Public Key vorliegt. Außerdem sperre ich mich selbst aus, sollte ich, warum auch immer, den Private Key verlieren. Soweit auch richtig?

Du müsstest ihn auf allen Deinen Maschinen verlieren. Richtig. Aber, dafür hast Du hoffentlich ein Backup.

Das ganze hat mit PermitRootLogin erstmal nichts zu tun, oder?

Nein!

Gruss

Dirk

Lux schrieb:

Auf jedem Client-Rechner machst Du ein

ssh-keygen
ssh-copy-id -i ~/.ssh/id_rsa.pub deinuser@deinserver

richtig!

Ich muss dabei die Dateinamen nicht ändern? Der Server hält die anhand anderer Informationen auseinander.

Funktioniert der Private Key auch von einem anderen Rechner aus, wenn ich z.B. die Festplatte in einen neuen Rechner einbaue?

Du müsstest ihn auf allen Deinen Maschinen verlieren. Richtig. Aber, dafür hast Du hoffentlich ein Backup.

Noch nicht, weil das Thema Schlüssel für mich noch ein Buch mit sieben Siegeln ist, wie man vielleicht bemerkt. Ich muss mir dafür etwas einfallen lassen. Wie/wo sichert ihr eure Schlüssel? USB Stick? Auf CD brennen?

Das ganze hat mit PermitRootLogin erstmal nichts zu tun, oder?

Nein!

Ok, muss ich das gleiche Spiel dann nochmal auf dem Server für den Root machen? (Das ist der Punkt, der mich ursprünglich verwirrt hat)

burli schrieb:

Ich muss dabei die Dateinamen nicht ändern? Der Server hält die anhand anderer Informationen auseinander.

Auf dem Server gibt es im Homeverzeichnis des Users, zu dem Du Dich verbinden willst, ebenfalls ein .ssh-Verzeichnis. Darin ist eine Datei namens authorized_keys in die alle berechtigten Schlüssel eingetragen werden.

Funktioniert der Private Key auch von einem anderen Rechner aus, wenn ich z.B. die Festplatte in einen neuen Rechner einbaue?

Ja.

Noch nicht, weil das Thema Schlüssel für mich noch ein Buch mit sieben Siegeln ist, wie man vielleicht bemerkt. Ich muss mir dafür etwas einfallen lassen. Wie/wo sichert ihr eure Schlüssel? USB Stick? Auf CD brennen?

Ich habe ein ganzes Bündel an Artikel zu ssh geschrieben. Lies die einfach mal und probier das mit Deiner virtuellen Maschine aus.

Ok, muss ich das gleiche Spiel dann nochmal auf dem Server für den Root machen? (Das ist der Punkt, der mich ursprünglich verwirrt hat)

Nein, das musst Du nicht. Du kannst Dich als User verbinden und dann als User auf dem Server mit "sudo -i" zu root werden.

Es gibt überhaupt keine Notwendigkeit dafür, dass Du Dich als root via ssh anmelden musst.

Gruss

Dirk