|
|
| (2 dazwischenliegende Versionen desselben Benutzers werden nicht angezeigt) |
| Zeile 1: |
Zeile 1: |
| | + | Autor: nbkr |
| | | | |
| − | Achtung: Dieses HOWTO ist noch im entstehen und als vorlaeufig (Draft) zu betrachten!
| + | Hallo, |
| | | | |
| − | Dieses ist eine Sammlung von HOWTOs, die die wichtigstens Aktionen beschreiben, die bei einem Aufsetzen und Betreiben eines root Servers wenigstens durchzufuehren sind um einen in Grundzuegen sicheren root Server zu erhalten.
| + | im diesem Post möchte ich darstellen warum man ohne Linuxkenntnisse keinen (Linux) - root Server anmieten sollte. |
| | | | |
| − | Exclamation Diese HOWTO's entlasten einen root Server Betreiber aber nicht von der Verantwortung für diesen Exclamation .
| + | Vorweg 1: In diversen Threads habe ich schon Leuten davon abgeraten einen root Server anzumieten. Das ist keinesfalls böse gemeint, im Gegenteil, es soll denjenigen nur vor Schaden bewahren. |
| | | | |
| − | Wer zu dem Thema etwas beitragen will, der melde sich bitte per PN bei mir, da die Struktur beibehalten werden sollte, wie sie im hier angegegebenen Inhalt vorhanden ist.
| + | Vorweg 2: Um ganz ehrlich zu sein muss ich folgendes gestehen. Ich habe vor jetzt knapp 4 Jahren auch einen vServer angemietet ohne Ahnung von Linux zu haben. Ich hatte Linux zwar schonmal ausprobiert aber wieder verworfen. |
| | | | |
| | + | Ich hatte damals Glück das nichts passiert ist, aber das heißt nicht das es nicht leichtsinnig und gefährlich war. Es hätte ins Auge gehen können. Deshalb auch die Anmerkung: Niemals aufs Glück vertrauen. |
| | + | ''' |
| | | | |
| − | === [[Allgemein]] ===
| + | So, jetzt zum eigentlichen Thema''' |
| | | | |
| − | Warum man ohne Linuxknowhow keinen root server mietet
| + | Ein root Server ist ein Rechner der im Internet steht und so von jedermann erreichbar ist. |
| − | http://www.linux-club.de/ftopic48323.html
| |
| | | | |
| − | Keine Ahnung aber root Server...
| + | Auch Linux ist nicht unverwundbar und absolut sicher. Es gibt immer mal wieder Sicherheitslücken im Kernel oder auch in irgendeiner Anwendung wie ein Webserver oder ein PHP Board. |
| − | http://www.linux-club.de/ftopic63549.html
| |
| | | | |
| − | http://www.netsecond.net/howto/
| + | Diese Lücken können Angreifer nutzen um sich in den Server einzuloggen. Je nachdem welche Sicherheitslücke genutzt wurde kann der Angreifer u.U. sogar Root Rechte bekommen und mit dem Server tun und lassen was er will. |
| | | | |
| − | http://www.linux-magazin.de/Artikel/ausgabe/2002/11/debserv/debserv.html
| + | Er kann ihn zum versenden von Spam nutzen. Zum Angreifen anderer Server (DDOS Angriff z.B.) oder dort Daten ablegen (z.B. pornographisches oder rechtsradiakles Material). Darüber hinaus kann er natürlich auch Daten auslesen (vertrauliche Mails, Kundendaten) oder einfach nur schön viel Traffic verursachen. |
| | | | |
| − | weitere Links folgen, und können auch gerne hizugefügt werden.
| + | Der Haken bei der Sache: Für alle Handlungen die der Angreifer macht bist erstmal DU als Serverbesitzer verantwortlich. D.h. die Staatsanwaltschaft wird erstmal DICH fragen warum auf Deinem Server Kinderpornos zu finden waren. |
| | | | |
| − | --[[Benutzer:Yehudi|Yehudi]] 17:37, 16. Aug 2006 (CEST)
| + | Dann zu argumentieren das der Server gecrackt wurde ist immer schwierig, außerdem wird die Staatsanwaltschaft DIR mit Sicherheit eine Teilschuld zuräumen. |
| | | | |
| − | === [[Sicherer Zugriff mit putty und ssh key auf einen Linux Server]] ===
| + | Serververwaltung ist nicht einfach und man muss mehr tun als den Server nur einmal aufzusetzen. Deshalb der gut gemeinte Rat: Besser erstmal in Linux einlesen und einen Server zu Hause aufbauen. Wenn dieser dann einigermaßen läuft kann man den evlt. per DynDNS ans Internet anbinden und weitermachen. |
| − | (Dieser Teil stammt von framp)
| |
| − | Dieses HOWTO beschreibt, welche Schritte notwendig sind um sicher von einem Windows Rechner per ssh mit putty und nur mit einem ssh key auf einen Linux Server mit SuSE zuzugreifen.
| |
| | | | |
| − | Saemtliche Schritte auf dem Server werden mittels putty mit Konsolbefehlen und keiner graphischen Oberflaeche beschrieben. Eine graphische Oberflaeche birgt eine Menge Sicherheitsprobleme und aus langer Linuxerfahrung leidgepruefter Serveradministratoren sollte keine graphische Oberflaeche (X, KDE, GNOME) auf einem Server installiert sein. Die konkrete Anleitung geht davon aus, dass keine Passwoerter mehr zur Authentifiziereung benutzt werden sondern asymmetrische keys. Diese kann man durch eine Passphrase sichern oder aber auch auf die Passphrase verzichten.
| + | Überleg Dir also gut, ob Du wirklich einen root Server und das potentielle Risiko damit eingehen willst. |
| − | Der Vorteil bei keiner Passphrase ist, dass ein Zugriff immer ohne Passworteingabe moeglich ist. Der Nachteil ist, dass jeder, der den private key hat oder illegalerweise kopiert unbegrenzten Zugriff hat. Wer also ohne Passwort fahren will muss seine keys absolut sicher verwahren!
| |
| | | | |
| − | Saemtliche Konfigurationsaktionen auf dem Server werden per putty mit einem normalen user und seinem password gemacht. Ein paar Aenderungen benoetigen auch den user root mit seinem passwort. Erst am Ende nach erfolgreichem Test wird die Passwortauthentifizierung ausgeschaltet. Danach ist ein ssh Zugriff nur noch mit keys moeglich und jegliche Anmeldeversuche am Linux Server sind ohne key zum Scheitern verurteilt.
| + | Achja: Es gibt übrigens keinen Zeitpunkt an dem man sagen kann "Jetzt bin ich gut genug um mich um eine Server zu kümmern". Man muss immer dazu lernen und auf dem laufenden blieben. Ein sicherer Server ist kein Zustand sondern ein Wettlauf. |
| | | | |
| − | Achtung: Am Ende der Konfiguration kann sich aus Sicherheitsgruenden niemand mehr als root per ssh auf den Server anmelden! Dieses ist nur noch dem einen Benutzer der konfiguriert wurde mit seinem Key moeglich! Wenn root Zugriff benoetigt wird muss sich erst als normaler user anmelden und kann dann mit su - root Rechte bekommen. Sind Zugriffe von weiteren Usern notwendig sind die Steps 1-2 entsprechend zu wiederholen.
| |
| | | | |
| − | Konkret wurde die HOWTO Schritte mit putty 0.58 sowie OpenSSH 4.1p1 mit SuSE 10.0 erstellt. Konkret wird in der StepByStep Anleitung das Einrichten eines eines ssh Zugriffs mit putty fuer den user framp auf dem ssh Server obelix eingerichtet.
| + | [[Category:root Server]] |
| − | | |
| − | Folgende Schritte sind notwendig um sich letzendlich per putty und ssh key auf einen ssh Server anmelden zu koennen:
| |
| − | | |
| − | 1) Erzeugen eines privaten und public keys mit putty
| |
| − | | |
| − | 2) Anpassen des putty public keys an OpenSSH und kopieren des public OpenSSH Keys auf den Server und Aufnahme des keys in der authorized_keys Datei
| |
| − | | |
| − | 3) Aenderung der sshd Konfiguration so dass keys akzeptiert benutzt werden
| |
| − | | |
| − | 4) Einrichten des putty um mit dem key auf den Server zugreifen zu koennen und Test des Zugriffs mit key
| |
| − | | |
| − | 5) Aenderung der sshd Konfiguration so dass keine passwoerter mehr erlaubt sind sondern nur moch mit keys moeglich ist
| |
| − | | |
| − | 6) Hardening des sshd Servers, d.h. Pruefen von wichtigen Parametern auf die richtige sichere Einstellung
| |
| − | | |
| − | 1) Erzeugen eines privaten und public keys mit putty
| |
| − | | |
| − | a) Starten des Programms puttygen auf dem WindowsClient. Dann ssh-2 RSA waehlen und number of bits in generated key auf 2048 setzen.
| |
| − | b) Druecken von Generate
| |
| − | c) Save the generated key druecken und sichern des public und private keys in C:\Program Files\putty als id_rsa und id_rsa_priv.ppk.
| |
| − | | |
| − | 2) Anpassen des putty public keys an OpenSSH und kopieren des public OpenSSH Keys auf den Server und Aufnahme des keys in der authorized_keys Datei
| |
| − | | |
| − | a) Oeffnen eines Befehlsfensters und kopieren des putty public files id_rsa in id_rsa_linux mit dem befehl copy id_rsa id_rsa_linux[/i]
| |
| − | b) Mit einem Windows Editor muss die Datei id_rsa_linux sorgfaeltig geandert werden: Die ersten zwei Zeilen sowie die letzte Zeile muss
| |
| − | geloescht werden. Danach muessen alle Zeilen in eine Zeile zusammengefasst werden. Achtung! Es duerfen keine Leerzeichen auftauchen. Zum Schluss muss noch ssh-rsa am Anfang der Keyzeile eingefuegt werden. Achtung: Ein Leerzeichen am Ende von rsa! Die Zeile muss dann mit ssh-rsa AAAAB3 beginnen.
| |
| − | c) Oeffnen eines Befehlsfensters und C:\Program Files\putty>pscp id_rsa_linux framp@obelix:id_rsa aufrufen. Damit wird
| |
| − | der linux public key in das home Verzeichnis des users framp kopiert.
| |
| − | d) C:\Program Files\putty>putty framp@obelix:id_rsa aufrufen. Damit wird ein Befehlsfenster auf dem Server geoeffnet.
| |
| − | e) mkdir .ssh legt das .ssh Verzeichnis an wenn es nicht schon existiert
| |
| − | f) cat id_rsa >> .ssh/authorized_keys WICHTIG ! >> benutzen !!! Ansonsten werden schon existierende Authorisierungen geloescht.
| |
| − | | |
| − | 3) Aenderung der sshd Konfiguration so dass keys akzeptiert benutzt werden
| |
| − | | |
| − | a) Im putty Fenster mit C:\Program Files\putty>pscp root@obelix:/etc/ssh/sshd_config sshd_config die sshd Konfigurationsdatei downloaden.
| |
| − | b) Editieren der Datei mit einem Windows Editor so dass die folgenden Parameter wie folgt gesetzt sind:
| |
| − | Code:
| |
| − | PubkeyAuthentication yes
| |
| − | RSAAuthentication no
| |
| − | | |
| − | c) Im putty Fenster mit C:\Program Files\putty>pscp sshd_config root@obelix:/etc/ssh/sshd_config die sshd Konfigurationsdatei uploaden.
| |
| − | d) Im Server Befehlsfenster welches in 2.a geoffnet wurde rcsshd restart eingeben.
| |
| − | | |
| − | 4) Einrichten des putty um mit dem key auf den Server zugreifen zu koennen und Test des Zugriffs mit key
| |
| − | | |
| − | a) Starten des Programms putty auf dem WindowsClient.
| |
| − | b) Beim hostname framp@obelix eintragen (userid und Server name oder IP)
| |
| − | c) Zu Connection->SSH->Auth gehen und das Private key file for authentication fuellen mit C:\Program Files\putty\id_rsa_priv.ppk.
| |
| − | d) open und erscheint ein Befehlsfenster des Servers. U.U. muss noch die Passphrase eingegeben werden
| |
| − | e) Sichern des putty Profiles
| |
| − | f) Damit ist die ssh Verbindung mit key getestet und es kann die Passwortauthentifizierung ausgeschaltet werden.
| |
| − | | |
| − | 5) Aenderung der sshd Konfiguration so dass keine Passwoerter mehr erlaubt sind sondern nur moch mit keys moeglich ist
| |
| − | | |
| − | a) Im putty Fenster mit C:\Program Files\putty>pscp root@obelix:/etc/sshd/sshd_config sshd_config die sshd Konfigurationsdatei downloaden.
| |
| − | b) Editieren der Datei mit einem Windows Editor so dass die folgenden Parameter wie folgt gesetzt sind:
| |
| − | Code:
| |
| − | PubkeyAuthentication yes
| |
| − | PasswordAuthentication no
| |
| − | ChallengeResponseAuthentication no
| |
| − | | |
| − | c) Im putty Fenster mit C:\Program Files\putty>pscp sshd_config root@obelix:/etc/sshd/sshd_config die sshd Konfigurationsdatei uploaden.
| |
| − | d) Im Server Befehlsfenster welches in 2.a geoffnet wurde rcsshd restart eingeben.
| |
| − | | |
| − | 6) Hardening des sshd Servers, d.h. Pruefen von wichtigen Parametern auf die richtige sichere Einstellung
| |
| − | | |
| − | Diese Schritte sind eigentlich nicht mehr notwendig da kein Zugriff ohne key mehr moeglich ist. Es kann aber immer sein
| |
| − | dass aus verschiedenen Gruenden doch wieder auf Passwoerter umgestellt wird (PasswordAuthentication yes). root Zugriff per ssh
| |
| − | sollte aus Sicherheitsgruenden immer ausgeschaltet sein. benoetigt man root recht kann man als normaler User per su -
| |
| − | root rechte erhalten oder man setzt sudo ein. Deshalb sollte ein jeder ssh Server auf alle Faelle noch wie folgt gesichert werden:
| |
| − | | |
| − | a) Im putty Fenster mit C:\Program Files\putty>pscp root@obelix:/etc/sshd/sshd_config sshd_config die sshd Konfigurationsdatei downloaden.
| |
| − | b) Editieren der Datei mit einem Windows Editor so dass die folgenden Parameter wie folgt gesetzt sind:
| |
| − | Code:
| |
| − | PermitRootLogin no
| |
| − | AllowGroups users
| |
| − | AllowUsers xxx yyy zzz (xxx, yyy und zzz sind user die per ssh zugreifen duerfen)
| |
| − | ClientAliveInterval 15
| |
| − | LoginGraceTime 10
| |
| − | PubkeyAuthentication yes
| |
| − | MaxAuthTries 3
| |
| − | MaxStartups 1
| |
| − | PrintLastLog yes
| |
| − | KeepAlive no
| |
| − | | |
| − | c) Im putty Fenster mit C:\Program Files\putty>pscp sshd_config root@obelix:/etc/sshd/sshd_config die sshd Konfigurationsdatei uploaden.
| |
| − | d) Im Server Befehlsfenster welches in 2.a geoffnet wurde rcsshd restart eingeben.
| |
| − | | |
| − | Als Grundlage fuer dieses HOWTO dienten u.A. folgende Threads:
| |
| − | | |
| − | [Howto] Einrichten von publikkeys unter der ssh
| |
| − | [TIP]ssh einrichten mit public-key Authentifizierung
| |
| − | [TIP]Wie sichere ich meinen ssh Server? | |
| − | [TIP]Den eigenen Server absichern
| |
| − | | |
| − | Weitere Informtionen zu putty und OpenSSH:
| |
| − | | |
| − | putty homepage
| |
| − | Was Wikipedia zu putty sagt
| |
| − | OpenSSH homepage
| |
| − | OpenSSh manuals
| |
| − | | |
| − | Weitere Threads zu ssh spezifischen Fragen und Problemen:
| |
| − | | |
| − | Kontrolliertes Ausfuehren von Befehlen als root
| |
| − | SSH Angriffe
| |
| − | Host bei ssh Connection ablehnen
| |
| − | | |
| − | Des weiteren liefert eine Suche nach ssh im Forum diverse weitere Fragen und Antworten zu ssh die hier im HOWTO nicht behandelt wurden.
| |
| − | | |
| − | Last but not least lieferte http://www.framp.de/linux/?Netzwerk_Services:ssh_server wesentliche Teile zu diesem HOWTO.
| |
| − | | |
| − | Kommentare, Anmerkungen, Ergaenzungen oder Errata bitte der Uebersichtlichkeit halber in http://www.linux-club.de/ftopic65282.html posten.
| |
| − | | |
| − | === [[Firewall]] ===
| |
| − | | |
| − | === [[FTP-Server]] ===
| |
| − | | |
| − | === [[Mail-Server]] ===
| |
| − | | |
| − | === [[LAMP]] ===
| |
Autor: nbkr
Hallo,
im diesem Post möchte ich darstellen warum man ohne Linuxkenntnisse keinen (Linux) - root Server anmieten sollte.
Vorweg 1: In diversen Threads habe ich schon Leuten davon abgeraten einen root Server anzumieten. Das ist keinesfalls böse gemeint, im Gegenteil, es soll denjenigen nur vor Schaden bewahren.
Vorweg 2: Um ganz ehrlich zu sein muss ich folgendes gestehen. Ich habe vor jetzt knapp 4 Jahren auch einen vServer angemietet ohne Ahnung von Linux zu haben. Ich hatte Linux zwar schonmal ausprobiert aber wieder verworfen.
Ich hatte damals Glück das nichts passiert ist, aber das heißt nicht das es nicht leichtsinnig und gefährlich war. Es hätte ins Auge gehen können. Deshalb auch die Anmerkung: Niemals aufs Glück vertrauen.
So, jetzt zum eigentlichen Thema
Ein root Server ist ein Rechner der im Internet steht und so von jedermann erreichbar ist.
Auch Linux ist nicht unverwundbar und absolut sicher. Es gibt immer mal wieder Sicherheitslücken im Kernel oder auch in irgendeiner Anwendung wie ein Webserver oder ein PHP Board.
Diese Lücken können Angreifer nutzen um sich in den Server einzuloggen. Je nachdem welche Sicherheitslücke genutzt wurde kann der Angreifer u.U. sogar Root Rechte bekommen und mit dem Server tun und lassen was er will.
Er kann ihn zum versenden von Spam nutzen. Zum Angreifen anderer Server (DDOS Angriff z.B.) oder dort Daten ablegen (z.B. pornographisches oder rechtsradiakles Material). Darüber hinaus kann er natürlich auch Daten auslesen (vertrauliche Mails, Kundendaten) oder einfach nur schön viel Traffic verursachen.
Der Haken bei der Sache: Für alle Handlungen die der Angreifer macht bist erstmal DU als Serverbesitzer verantwortlich. D.h. die Staatsanwaltschaft wird erstmal DICH fragen warum auf Deinem Server Kinderpornos zu finden waren.
Dann zu argumentieren das der Server gecrackt wurde ist immer schwierig, außerdem wird die Staatsanwaltschaft DIR mit Sicherheit eine Teilschuld zuräumen.
Serververwaltung ist nicht einfach und man muss mehr tun als den Server nur einmal aufzusetzen. Deshalb der gut gemeinte Rat: Besser erstmal in Linux einlesen und einen Server zu Hause aufbauen. Wenn dieser dann einigermaßen läuft kann man den evlt. per DynDNS ans Internet anbinden und weitermachen.
Überleg Dir also gut, ob Du wirklich einen root Server und das potentielle Risiko damit eingehen willst.
Achja: Es gibt übrigens keinen Zeitpunkt an dem man sagen kann "Jetzt bin ich gut genug um mich um eine Server zu kümmern". Man muss immer dazu lernen und auf dem laufenden blieben. Ein sicherer Server ist kein Zustand sondern ein Wettlauf.
