apache_pb Dies soll keine vollständige Installationsanleitung sein, vielmehr eine Sammlung der Einstellungen, Programme und Skripte, die ich für die Administration meiner Server verwende. Solltet ihr Fehler finden, so freue ich mich über konstruktive Hinweise. Linux-Basics spar ich mir, es sollte bekannt sein wie ihr root-Rechte erlangt, Software installiert, Rechte setzt, … .

Das Server-System

Opensuse_big Der erste Schutz für euren Server ist ein passendes Betriebssystem. Wie die Überschrift bereits verrät kommt bei mir OpenSUSE zum Einsatz, genauer: Version 11.4. Einen eigenen Webserver kann man natürlich auch unter Windows betreiben, z.B. mit dem Paket von Apachefriends. Allerdings ist Windows hierfür meiner Meinung nach nicht die erste Wahl, es ist schlicht zu groß und zu Ressourcen-hungrig für die hier gestellten Aufgaben. Ein einfaches, nacktes Linux ist absolut ausreichend, es nimmt fast keinen Platz ein, lässt sich einfach Administrieren und läuft auch auf der kleinsten Kiste.

Je nach dem wie kritisch die Daten sind die auf dem Server hinterlegt werden sollen, sollte man sich genau überlegen, welche Sicherungen man einbaut. Grundsätzlich gilt: Wenn ein Externer via SSH auf den Server zugreifen kann, sind viele der Daten erst lesbar, wenn er auch das root-Passwort “errät”. Kommt der Server hingegen durch einen echten Einbruch in fremde Hände, können viele der Daten direkt von der Festplatte gelesen werden (z.B. mit einer LiveCD), das Knacken der Passwörter fällt dann auch leichter, da ein direkter Zugriff möglich ist.

Im ersten Fall helfen gute Passwörter, das Unterbinden eines direkten root-Logins via SSH (verhindert das Mitlesen des Passworts) und eine regelmäßige Durchsicht der Logs um Einbruchversuche früh zu erkennen (siehe Sicherung 2). Im zweiten Fall hilft die Unterbringung in einem sicheren Raum (Serverraum) und /oder eine Verschlüsselung des Laufwerks bzw. der Partitionen.

Grundlegend gilt allerdings: 100%ige Sicherheit gibt es nie! Auch aus gesicherten Serverräumen wird mal was geklaut, und auch alle Kriterien erfüllende Passwörter können mal geknackt werden.

Aber wir werden unser möglichstes versuchen.

Sicherung 1: SSH

SSH ist eine einfache Möglichkeit unseren Server aus der Ferne zu warten. Da in der minimalen Serverinstallation X sowieso fehlt, ist die Kommandozeile unser Freund, also SSH absolut ausreichend. SSH wird bei OpenSUSE 11.4 in der minimalen Serverinstallation gleich mit installiert, wer will kann die SSH-YAST-Konfiguration noch hinzufügen, es geht aber auch alles via Konfigdatei (/etc/ssh/sshd.config).

Um automatisierte Login-Versuche über den Standard-Port von SSH (22) zu unterbinden, lassen wir den SSH-Server auf einem beliebigen Port lauschen (Bsp: 36532). Dies kann mit Hilfe von YAST oder direkt in der ssh-Konfigurations-Datei erledigt werden. Natürlich muss dieser Port auch in der Firewall geöffnet werden. Steht der Server zudem noch hinter einer weiteren Firewall oder daheim hinter einem Router, muss auch dort der Port freigeschaltet bzw. weitergeleitet werden.

Den direkten Login von root verhindern wir mit der Einstellung  PermitRootLogin yes, es bietet sich auch an, die erlaubten Login-Versuche von sechs auf zwei zu reduzieren. Neben der Möglichkeit sich mittels Passwort zu authentifizieren, ermöglicht SSH auch einen Login mit Hilfe von Schlüsseldateien. In beiden Fällen ist darauf zu achten, die Dateien sicher zu verwahren (wenn z.B. der Heimrechner mal die Grätsche macht, sollte eine Sicherung der Schlüssel vorhanden sein). Aber auch die Passwörter sollten sicher aufbewahrt werden, entweder auf einem Zettel im Lieblingsbuch, im Gedächtnis oder mit Hilfe von speziellen Programmen (Bsp.: KeePass). Sollen die Daten nach eurem, eventuell spontanen, Verscheiden auch noch anderen Leuten zugänglich sein, solltet ihr einen Platz wählen, an dem man sie auch findet!

Nun haben wir unseren SSH-Zugang schon etwas besser abgesichert, je nachdem, wie wichtig die Daten auf dem Server sind, können wir die Sicherheit durch Zusatzsoftware wie z.B. den SSHGuard noch erhöhen. Hier muss jeder entscheiden, wie sicher einem sicher genug ist.

Ich empfehle aber allen, ab und an die Log-Dateien des Systems zu überfliegen, um mögliche Angriffe (meist automatische Skripte) frühzeitig zu erkennen und eventuell reagieren zu können (Port wechseln, Passwörter ändern, …).

Sicherung 2: Firewall

Die Firewall schützt unseren Computer vor ungebetenen Gästen, indem sie alle Anfragen auf Ports blockt, die von keinem aktiven Service des Servers erwartet werden. Um einen Zugriff von Extern auf den Webserver zu ermöglichen, müssen wir den Port 80 der Firewall öffnen, für unseren SSL-geschützten Server ist es der Port 443. Um uns mit Hilfe von Putty oder einem anderen SSH-Client auf dem Server einloggen zu können, muss der Port 22 geöffnet sein bzw. der Port, an dem wir unseren SSH-Server “lauschen” lassen (s. Sicherung 1).

Alle Ports die nicht benötigt werden, sollten geschlossen bleiben. Wird wie in Abschnitt 1 beschrieben, der SSH-Port verlegt, sollte der Port 22 geschlossen werden. Ebenso bleibt der 80er Port des Webservers geschlossen, wenn sowieso nur via https Anfragen ausgeliefert werden.

Sicherung 3: SSL Verschlüsselung für alles!

Der Server soll später als Webserver genutzt werden, erster Schutzmechanismus ist dabei natürlich SSL. An sich gibt es keinen Grund HTTP noch unverschlüsselt zu nutzen, auch wenn man es bisher fast nur von Webshops, Internet Banking und Co. kennt.

Ein gutes Beispiel bietet hier Google, die unter https://encrypted.google.com/ bereits eine https-geschützte Suchanfrage ermöglichen.

Um die Website via SSL absichern zu können, wird das Paket OpenSSL benötigt, welches bei der Standard-Server-Installation von OpenSUSE 11.4 bereits vorhanden ist. Mit Hilfe dieses Programms wird das Zertifikat für die Webseite erstellt. Ein erstes Zertifikat kann mit dem Befehl:

Bash
/usr/bin/gensslcert

erstellt werden. Es handelt sich dabei aber nur um ein vorläufiges Zertifikat, dass aber für erste Testzwecke vollkommen ausreichend ist. Mit folgenden Befehlen wird ein individuelles Zertifikat für den Server erstellt und im zugehörigen Verzeichnis des Webservers abgelegt.

Bash
  1. openssl req -new > /etc/apache2/ssl.csr/server.csr
  2. # Server-Schlüssel erstellen
  3. openssl rsa -in /etc/apache2/privkey.pem -out /etc/apache2/ssl.key/server.key
  4. # Zertifkat für 365 Tage erstellen
  5. openssl x509 -in /etc/apache2/ssl.csr/server.csr -out /etc/apache2/ssl.crt/server.crt -req -signkey /etc/apache2/ssl.key/server.key -days 365

Ist das Zertifikat erstellt und abgelegt, können wir den ersten Start des Servers durchführen.

Bash
#Server starten
rcapache start

Nun sollte der Server über die Adresse: https://localhost eine erste Seite anzeigen.

In der ssl.conf im Verzeichnis /etc/apache2/vhosts.d/ können nun weitere Angaben für die Website eingegeben werden. Sollen weitere Websites auf dem Server gehostet werden, so ist dies leider nur über Aliase, IP-based oder Server Name Indication (SNI) machbar, da Apache2 mit SSL noch keine name-based vhosts akzeptiert.

Eine gute Erläuterung warum dies so ist gibt es hier, eine mögliche Konfiguration eines Alias folgt im Anschluss. Diesen Alias würdet ihr zum Beispiel über den Aufruf https://website.url/test/ aufrufen können.

Apache configuration
  1. Alias /test /srv/www/test
  2. <directory /srv/www/test>
  3. #SSL-Schutz
  4. SSLRequireSSL
  5. #Zusätzlicher Verzeichnisschutz (optional)
  6. AuthType Basic
  7. AuthName “Testseite Zugang”
  8. AuthUserFile /etc/apache2/pass/passwords
  9. Require valid-user
  10. </directory>

Sicherung 4: mysql

Nach der Installation des MySQL-Servers sollte nach dem ersten Start ein root-Passwort für den MySQL-Server vergeben werden. Dies kann gleich mit dem Befehl

Bash
/usr/bin/mysql_secure_installation

 

durchgeführt werden. Der Befehl entfernt darüber hinaus auch den Test-User, die Test-Datenbank und unterbindet von Anfang an einen root-Login von Extern. In meinem Beispiel läuft der mysql-Server auf der gleichen Maschine wie der Webserver, daher kann ich den externen Zugriff komplett verbieten und erspare mir so einige Sicherheitslücken.

Laufen auf eurem System mehrere Datenbanken für verschiedene Anwendungen, empfiehlt es sich, für jede Anwendung und Datenbank einen eigenen Nutzer anzulegen. So stellt ihr sicher, das bei bekannt werden eines Benutzernamen/Passwort-Paares, alle Datenbanken ausgelesen werden könnten. Mit Hilfe der Erweiterung phpMyAdmin lassen sich die Rechte der einzelnen Nutzer sehr gut anzeigen und auch testen. Loggt euch mit dem jeweiligen Nutzer in euer phpMyAdmin ein, und euch wird nur angezeigt, was dieser Nutzer auch sehen darf. Ob ihr schreiben, löschen oder die ganze Datenbank löschen dürft, könnt ihr so auch ganz schnell testen. Vorher aber ein Backup machen, s. Sicherung 6!

Sicherung 5: htaccess

Alle Verzeichnisse in denen der Otto-Normal-User nichts zu suchen hat, solltet ihr immer mittels .htaccess-Dateien absichern. Einige Beispiele wären /wp-admin/ wenn ihr WordPress benutzt, /phpMyAdmin/ wenn ihr das besagte Tool für die Verwaltung eurer Datenbanken nutzt, … . In der .htaccess-Datei (s.u.) legt ihr fest, dass nur Nutzer auf das Verzeichnis zugreifen können, die die benötigten Nutzerdaten kennen. Die Passwortdatei, die diese Informationen enthält, erstellt ihr mittels htpasswd2 (Anwendung siehe “man htpasswd2”).

Mit Hilfe der htaccess-Dateien ist es euch auch möglich, einige Servereinstellungen für einzelne Ordner zu ändern. So gibt es immer noch Software die z.B. die php-Einstellung “register_globals = ON” benötigt. Dies könnt ihr mit dem Zusatz “php_flag register_globals on” in der lokalen .htaccess-Datei erreichen.

Beispiel einer .htaccess-Datei zum Schutz eines Verzeichnisses (in diesem Fall der Adminbereich einer WordPress-Installation):

Apache configuration
  1. AuthType Basic
  2. AuthName „WP Adminbereich“
  3. AuthUserFile /etc/apache2/pass/passwords
  4. Require valid-user

Da die .htaccess-Datein bei jedem Seitenaufruf erneut ausgewertet werden, kann eine allzu häufiger Gebrauch den Webserver etwas ausbremsen. Solltet ihr für viele eurer Verzeichnisse spezielle Regeln aufstellen wollen, so empfiehlt es sich, dies direkt in der Serverkonfiguration zu machen. Die hier hinterlegten Regeln werden nur einmalig eingelesen, werden aber auf alle Anfragen angewendet.

Sicherung 6: Backup

Jedem ist schon einmal eine Datei verloren gegangen. Sie wurde aus versehen gelöscht, oder bei einem Programmabsturz beschädigt etc.. Auch die Daten auf dem Server können durch einen Crash, äußere Einwirkungen (Feuer, Löschwasser, …) oder durch Diebstahl beschädigt, zerstört oder eben geklaut werden.
Damit die Daten dann nicht verloren sind, müssen in regelmäßigen Abschnitten Backups angelegt werden. Bei dem hier beschriebenen Webserver ändern sich nur die Inhalte der Datenbanken, daher wird von diesen ein Backup erstellt.

Das unten aufgeführte Skript nimmt einem diese Arbeit komplett ab. Die in Zeile 4 angegebenen Namen der Datenbanken werden mit Hilfe des Befehls mysqldump in separate Dateien gesichert und mit einem Datum versehen. Damit das Skript mehrere Datenbanken sichern kann, ist darauf zu achten, dass als mysql-Nutzer ein Nutzer eingetragen wird, der für alle angegeben Datenbanken Leserechte besitzt und das Recht die Datenbanken zu Sperren (Lock Table). Letzteres wird während des Auslesens benötigt, da so verhindert wird, das irgendwer während des Backups noch etwas in der Datenbank ändert.

Damit das Skript nun nicht immer manuell aufgerufen werden muss, bedienen wir uns der cronjobs. Mit dem Befehl “crontab –e” öffnet ihr die Steuerdatei für eure cronjobs. Hier könnt ihr nun Befehle anlegen, die zu einer bestimmten Uhrzeit, an einem bestimmten Tag etc. ausgeführt werden sollen. Hier ist also der richtige Platz für unser Skript, so stellen wir sicher, dass die uns wichtigen Daten alle 24h, oder wenn es bei euch arg dynamisch zugeht, auch öfter, gesichert werden.

Weitere Infos zu den cronjobs findet ihr hier.

Bash
  1. #!/bin/bash
  2. DATUM=date '+%Y-%m-%d'
  3. #Dump der MYSQL-Datenbanken
  4. datenbanken=„name1 name2 name3“
  5. #Alle Dumps werden erstellt
  6. for name in echo $datenbanken
  7. do
  8. /usr/bin/mysqldump -uwp -pPASSWORT –opt $name > /home/backup/mysql/$name${DATUM}.sql
  9. #Komprimieren der Dateien und Verschluesseln
  10. #Archiv Header verschluesseln: -mhe=on
  11. #Passwort fuer das Archiv: -pPASSWORT
  12. /usr/bin/7z a -mhe=on -pPASSWORT /home/backup/mysql/$name${DATUM}.7z /home/backup/mysql/$name${DATUM}.sql
  13. #Ursprungsdatei loeschen
  14. /bin/rm /home/backup/mysql/$name${DATUM}.sql
  15. #Nur fuer root lesbar
  16. /bin/chmod og-rwx /home/backup/mysql/$name${DATUM}.7z
  17. done

 

Habt ihr noch andere dynamische Dateien die ihr sichern wollt, so könnt ihr die zugehörigen Verzeichnisse ebenfalls in verschlüsselte Archive sichern lassen. Dies ist zum Beispiel bei WordPress der Fall, hier finden sich in /wp-content/uploads eure eingebundenen Bilder und andere Daten die ihr auf eure WordPress-Seite hochgeladen habt.

Darüber hinaus solltet ihr natürlich auch den Code eurer Website zumindest einmalig irgendwohin sichern, schreibt ihr daran noch oft herum, dann macht euch ein Skript dafür, s.o..

Sicherung 7: Backup in die Cloud

Alle Backups werden auf einen zentralen FTP-Server übertragen um einen Datenverlust im Falle eines Brandes, Diebstahls etc. zu vermeiden. Die Backups sind alle, wie in Kapitel 6 erläutert, verschlüsselt und werden zudem über eine verschlüsselte Leitung auf den FTP-Server transferiert.

Da unsere Daten mittels cronjob jede Nacht auf den FTP-Server übertragen werden sollen, kann für diese Aktion nur ein Kommandozeilenprogramm in Betracht kommen. Um die Übermittlung der Daten mittels FPES sicherzustellen, bedarf es in diesem Fall eines kleinen Tricks. Die Daten werden nicht direkt in einer Kommandozeile an den Server übertragen, sondern der FTP-Server wird mittels curlftpfs gemountet. Die Verbindung zwischen curlftpfs und dem Server erfolgt dabei mittels TLS. Auf das gemountete Verzeichnis kann nun mittels einfacher cp, mv und rm Befehle zugegriffen werden.

Sollen mehrere Dateien aus verschiedenen Ordnern gesichert werden, verwenden wir das Programm rsync, ansonsten ist der cp-Befehl ausreichend.

Die einzelnen Befehle lauten:

Bash
  1. #!/bin/bash
  2. mountpunkt=„“
  3. username=„“
  4. password=„“
  5. servername=„“
  6. # Mounten des FTP -Servers
  7. curlftpfs $username:$password@$servername $mountpunkt -o allow_other , disable_eprt ,tlsv1
  8. # Synchonisation
  9. rsync –delete /home/[Verzeichnis der Backups] $mountpunkt
  10. # Oder einfaches Kopieren
  11. cp /home/[Verzeichnis der Backups]/Datei $mountpunkt
  12. # Unmounten des FTP -Servers
  13. fusermount -u $mountpunkt

Ende

Unser Server ist nun bestimmt nicht 100%ig sicher, aber die ersten wichtigen Schritte haben wir getan. Eine weitere, hier nicht genannte Sicherheitslücke, stellen “Einbrüche” über eure Website dar. Hier kann mittels SQL-Injection, Cross-Site-Scripting und weitere Techniken Zugriff auf euren Server bzw. eure Daten erlangt werden. Als Gegenmaßnahme hilft hier nur umsichtiges Programmieren bzw. regelmäßige Updates der verwendeten Softwarepakete.

OpenSUSE Webserver – Apache2 und MySQL, aber sicher!

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.