Ein eigenständiger Webserver ermöglicht es Websites schneller auszuliefern, eigene Software zu installieren und alle Einstellungen selbst zu treffen. Dabei ist man nicht auf die Vorgaben eines Hosters beschränkt, im Gegenzug muss man sich aber selbst um die Konfiguration und Absicherung des Servers kümmern. Diese Anleitung kann auf vServer, Root Server oder Droplets angewandt werden. So gut wie alle Hoster bieten diverse Linux Distributionen an, die automatisch auf dem jeweiligen Server installiert werden können. Die einzige Vorgabe die für die Durchführung dieser Anleitung erfüllt werden muss, ist der Einsatz von Ubuntu in der Version 18.04. Neben dem Server selbst benötigen wir natürlich auch Zugang zu dem Server per SSH und einem Root User. Diese Informationen sollten euch nach der Einrichtung über die Weboberfläche des Hosters zur Verfügung gestellt werden. Haben wir alle benötigten Informationen können wir direkt loslegen. Sollte euer Hoster euch die Möglichkeit geben SSH Keys für die Anmeldung zu benutzen solltet Ihr diese Option unbedingt nutzen. Die Vorgehensweise für die Anmeldung ist in diesem Fall bei jedem Hoster leicht unterschiedlich und wird in den meisten Fällen vom Hoster direkt beschrieben.
In dieser Anleitung arbeite ich mit einem Server der bei DigitalOcean gehostet wird. Interessierte können sich über diesen Link einen Account erstellen (Affiliate Link). Wenn Ihr euch über den Link registriert erhaltet Ihr 100 US-Dollar an Guthaben das Ihr über einen Zeitraum von 60 Tagen verbrauchen könnt. Nach den 60 Tagen verfällt das Guthaben und alle damit verbundenen Services. Wenn Ihr mit dem Service zufrieden seid könnt Ihr euch zusätzliches Guthaben kaufen. Sobald Ihr mehr als 25 US-Dollar aufladet erhalte Ich für das Referral 25 US-Dollar auf mein Konto gutgeschrieben. Für euch ergeben sich dadurch keine höheren Preise oder andere Nachteile. Natürlich könnt Ihr auch andere Hoster wie z.B. Hetzner nutzen, die Entscheidung liegt bei euch.
Sind Sie nicht mehr zufrieden mit Ihrer Website? Kämpfen Sie mit langen Ladezeiten auf Ihrer Website oder Ihrem Webshop oder benötigen Sie einen zeitgemäßen Online Auftritt? Ich biete Website Erstellung, Suchmaschinenoptimierung sowie WordPress Plugin Entwicklung in Wien und Niederösterreich.
Grundlegendes Server Setup
Anmeldung
Sobald unser Server aufgesetzt wurde und wir die benötigten Anmeldeinformationen bzw. SSH Keys haben können wir loslegen. Für die Fernwartung nutzen wir SSH. Linux und Mac User können direkt über das Terminal eine Verbindung aufbauen. Windows Nutzer können auf Tools wie Putty oder MobaXterm zurückgreifen. Der Vorteil von MobaXterm ist, dass man Profile für die jeweiligen Server einfacher verwalten kann. Ich verwende MobaXterm für die Verwaltung, die Screenshots in dieser Anleitung stammen also direkt daraus.
Wir starten die Verbindung zu unserem Server (per Terminal) über den folgenden Befehl (solltet Ihr SSH Keys nutzen müsst Ihr den Pfad zu den Keys zusätzlich angeben). Je nach verwendeter Software gibt es andere Schritte die man für die Anmeldung durchgehen muss. Sollte euer Hoster die jeweiligen Optionen nicht beschreiben könnt Ihr auch direkt Google für die Vorgehensweise in eurem Fall befragen.
ssh root@ip_des_servers
Solltet Ihr euch per Passwort mit dem Server verbinden werdet Ihr eventuell aufgefordert euer Passwort zu ändern. Folgt dabei einfach den Schritten die euch am Schirm angezeigt werden. Legt euch auch direkt z.B. eine Excel Liste zu in der Ihr die wichtigsten Kennwörter speichert.
Nach der erfolgreichen Anmeldung sollte eure SSH Sitzung in etwa folgendes anzeigen.
Firewall
Nach erfolgreicher Anmeldung starten wir direkt mit der ersten Konfiguration unserer Firewall. Ubuntu wird mit einer passenden Lösung Namens UFW ausgeliefert. Die in dieser Anleitung genutzten Apps registrieren jeweils eigene Profile die für die einfache Verwendung in Verbindung mit UFW genutzt werden können.
Um zu sehen welche Apps gerade installiert sind und per UFW direkt gesteuert werden können geben wir den folgenden Befehl ein:
ufw app list
Das Kommentar sollte uns den folgenden Output liefern:
Available applications:
OpenSSH
OpenSSH ist derzeit die einzige Anwendung am Server die per UFW konfiguriert werden kann. Unsere Firewall ist derzeit noch nicht aktiviert. Bevor wir die Firewall aktivieren können müssen wir aber OpenSSH freigeben um uns nicht selbst auszusperren. Die Freigabe erfolgt mithilfe von „ufw allow AppName“. Für OpenSSH sieht der Befehl also wie folgt aus:
ufw allow OpenSSH
Der Output sollte wie folgt aussehen:
Rules updated
Rules updated (v6)
Unsere Regeln wurden also erfolgreich aktualisiert, Zeit die Firewall zu aktivieren. Dazu geben wir den folgenden Befehl ein.
ufw enable
Bevor die Firewall aktiviert wird, erfolgt noch eine Sicherheitsabfrage die Ihr per „y“ bestätigen müsst. Anschließend sollte euch der folgende Output gezeigt werden.
Firewall is active and enabled on system startup
Perfekt, nun werfen wir noch schnell einen Blick auf den aktuellen Status unserer Firewall mithilfe von:
ufw status
Hier werden uns jetzt die registrierten Apps mit den jeweiligen Firewall-Einstellungen angezeigt. Die Liste ist in unserem Fall recht kurz. Solltet Ihr bereits weitere Software installiert haben, könnte die Liste etwas länger ausfallen.
Nachfolgend ein Bild das die letzten Eingaben zeigt.
User Account erstellen
In Linux Systemen ist der Root User der uneingeschränkte Administrator des Systems. Damit hat das Konto Zugriff auf alle Aspekte des Systems und kann diese somit auch bewusst oder unbewusst negativ beeinflussen. Direkt nach der erfolgreichen Anmeldung erstellen wir aus diesem Grund einen neuen User den wir unserer Root Benutzergruppe hinzufügen, dadurch aber nicht alle Rechte erhält die dem eigentlichen Root User zugesprochen werden.
Um einen neuen Nutzer anzulegen geben wir den folgenden Befehl ein. In unserem Fall bennenen wir den User „osulzer“.
adduser osulzer
Wir bestätigen die Eingabe mit Enter und werden direkt nach einem Passwort gefragt. Nutzt ein starkes Passwort. Solltet Ihr noch keinen Passwort Manager nutzen ist jetzt vielleicht ein guter Zeitpunkt damit zu beginnen. Alternativ könnt Ihr ein eigenes Passwort erstellen und dieses an einem sicheren Ort abspeichern. Nach dem Passwort werdet Ihr über weitere Details zu dem User gefragt, Ihr könnt hier entweder mehr Informationen angeben oder einfach per Enter-Taste weiterspringen.
Jetzt fügen wir den neuen User der Root-Gruppe hinzu. Anschließend kann unser User „sudo“ Befehle ausführen.
usermod -aG sudo osulzer
Der Output eurer SSH Session sollte jetzt in etwa wie folgt aussehen.
SSH Zugang für neuen Benutzer erstellen
Für anfallende Arbeiten auf unserem Server verwenden wir in Zukunft unseren neuen Benutzer. Damit wir den Nutzer direkt für das Login auf unserem Server nutzen können müssen aber noch ein paar Einstellungen getroffen werden. Solltet Ihr euch ausschließlich per Usernamen und Passwort am Server Anmelden reicht es die Verbindung per „ssh osulzer@ip_des_servers“ im Terminal einzugeben und sich zu verbinden. Die sichere Methode per SSH Keys erfordert weitere Vorkehrungen.
Achtung: Bleibt aus Sicherheitsgründen mit dem Root User vorerst auf eurem Server angemeldet. Schließt das Fenster also nicht bis das neue Login getestet wurde und funktioniert.
SSH Key Authentizierung aktivieren
In Zukunft möchten wir uns nur noch mit unserem neu erstellten User anmelden. Dafür müssen wir die SSH Keys die derzeit root zugewiesen sind, für unseren neuen User konfigurieren. Wir nutzen dafür rsync um die Zugriffsrechte beim kopieren der Keys zu behalten. Bleibt bitte mit eurer root SSH Session angemeldet, sollte es nämlich beim kopieren der Keys zu einem Fehler gekommen sein, könntet Ihr euch aus dem Server aussperren. Zum kopieren nutzen wir den folgenden Befehl, in eurem Fall müsst Ihr die Stellen an denen ich „osulzer“ eintrage den von euch gewählten Usernamen auswählen. Bevor der Eingabe hier noch eine kurze Klarstellung. Der Teil des Befehls “chown=osulzer:osulzer“ bedeutet nicht „Username:Kennwort“ sondern „Username:Usergruppe“. In unserem Fall müsst Ihr also zweimal den Usernamen getrennt mit „:“ eingeben. Achtet auch darauf, dass der Teil „~/.ssh“ keinen Slash am Schluss hat, sonst wird statt dem Ordner der Inhalt des Ordners kopiert.
rsync --archive --chown=osulzer:osulzer ~/.ssh /home/osulzer
Nach der Ausführung des Befehls sollte es möglich sein, dass Ihr euch mit eurem neuen Nutzer per SSH anmeldet. Anders als beim bislang verwendeten root user müsst Ihr mit eurem neuen User für die Ausführung von Befehlen die Änderungen am System vornehmen den Zusatz „sudo“ am Anfang des Befehls eingeben. Der Befehl fragt anschließend das Kennwort ab welches Ihr bei der Erstellung des Nutzers eingeben habt.
Ab sofort arbeiten wir nur noch über diesen User, schließt also eure root Session mit dem Server und macht mit der neuen SSH Session auf dem Ihr mit dem von euch erstellten User angemeldet seit weiter.
Für die Konfiguration von Nginx und SSL benötigen wir eine Domain die auf unseren Server zeigt. Je nachdem wo Ihr eure Domains registriert habt, gibt es unterschiedliche Einstellungen und Oberflächen um die DNS-Einstellungen der Domain zu ändern. Wichtig ist, dass der „A“-Eintrag der Domain auf die IP-Adresse es Servers zeigt. Nachfolgend eine Kurzerklärung für die Einträge.
Name | Typ | Inhalt |
*.euredomain.com | A | server_ip_adresse |
www.euredomain.com | A | server_ip_adresse |
euredomain.com | A | server_ip_adresse |
Die Änderung dieser Einstellungen kann ein paar Stunden dauern. In der Zwischenzeit könnt Ihr mit der Installation von Nginx fortfahren bis wir zum Punkt mit der Konfiguration des Server Blocks für die Domain kommen. Ab diesem Zeitpunkt sollte eure Domain im besten Fall bereits auf euren neuen Server zeigen.
Kurzer Tipp:
Ihr könnt den DNS-Cache auf eurem Rechner zurücksetzen um schneller die aktualisierten Adressen zu erhalten.
Windows User
Startet eine Eingabeaufforderung und gebt den folgenden Befehl ein:
ipconfig /flushdns
Mac OSX
sudo dscacheutil -flushcache
Linux User
sudo /etc/init.d/nscd restart
Nginx Installation
Wer bislang nur mit normalen Webspace zu tun gehabt hat, wird vielleicht nicht direkt wissen um was es sich bei Nginx handelt. Nginx bietet eine bessere Performance und spart im Vergleich zu Apache wichtige Server Ressourcen. Nachteile im Vergleich zu Apache sind z.B. der größere Aufwand um zusätzliche Module zu installieren und die fehlende Möglichkeit z.B. Servervariablen in einer .htaccess Datei zu ändern. Welche Lösung Ihr schlussendlich für euren Server nutzt bleibt euch überlassen, in diesem Tutorial bearbeiten wir Nginx.
Bevor wir mit der Installation von Nginx beginnen aktualisieren wir unseren lokalen Paketindex. Dafür geben wir den folgenden Befehl ein.
sudo apt update
Sollten euch an dieser Stelle angezeigt werden das Updates verfügbar sind, könnt Ihr diese über den folgenden Befehl installieren.
sudo apt upgrade
Jetzt aktualisieren wir Nginx direkt über das Ubuntu Repository
sudo apt install nginx
Kurz nach der Ausführung des Befehls fragt euch das System ob Ihr die neuen Dateien herunterladen wollt. Bestätigt den Befehlt mittels „y“
Ubuntu startet Nginx direkt nach der Installation, wir müssen den Dienst also nicht separat registrieren. Bevor wir Anfragen per HTTP testen können müssen wir Nginx aber noch in unserer Firewall freigeben. Werfen wir dazu zuerst einen Blick auf die durch Nginx registrierten Profile in der UFW Firewall.
sudo ufw app list
Output:
Available applications:
Nginx Full
Nginx HTTP
Nginx HTTPS
OpenSSH
Nginx hat uns gleich mehrere Profile zur Verfügung gestellt. Wir können auf Wunsch Anfragen die über HTTP kommen blockieren und nur HTTPS Anfragen zulassen. Da wir HTTP Requests später zu HTTPS weiterleiten und deswegen die Anfragen nicht direkt blockieren wollen wählen wir das Profil „Nginx Full“ zur Freigabe. Dazu geben wir den folgenden Befehl ein.
sudo ufw allow 'Nginx Full'
Output:
Rule added
Rule added (v6)
Nun sollte der Server auf HTTP Anfragen reagieren. Startet den Browser eures Vertrauens und navigiert zur IP-Adresse oder der Domain die auf die IP Adresse des Servers zeigt. Hat alles geklappt sollte euch die folgende Nachricht angezeigt werden.
Gratulation, Nginx läuft, wir sind aber noch nicht fertig. Anders als bei Apache müssen wir bei der Benutzung von Nginx PHP selbst installieren. Wir verwenden dazu php-fpm was für „fastCGI process manager“ steht. Nginx leitet PHP Anfragen an diese Software weiter um PHP Code auszuführen. Neben php-fpm installieren wir an dieser Stelle auch gleich die passende Schnittstelle um später auch die Möglichkeit zu haben über PHP auf unsere MySQL Datenbank zugreifen zu können. Als diese Anleitung erstellt wurde, installiert der folgende Befehl PHP in der Version 7.2.
sudo apt install php-fpm php-mysql
Jetzt sind die benötigten Packages installiert, wir müssen Nginx aber noch klarmachen, dass diese packages genutzt werden sollen. Nginx nutzt sogenannte Server Blocks die es euch ermöglichen z.B. mehrere Websites auf einem Server laufen zu lassen. Die jeweiligen Websites können dabei voneinander getrennte Konfigurationen nutzen. Nginx zeigt nach der Installation auf das Verzeichnis „/var/www/html“, zum jetzigen Zeitpunkt zeigt der Server also direkt auf den Inhalt des Ordners. Für unsere Domain erstellen wir ein eigenes Verzeichnis mit der passenden Ordnerstruktur. Der folgende Befehl erledigt das für uns mithilfe des -p Parameters.
sudo mkdir -p /var/www/euredomain.com/html
Anschließend übergeben wir die Inhaberschaft an die $USER Umgebungsvariable.
sudo chown -R $USER:$USER /var/www/euredomain.com/html
Nun setzen wir noch die Zugriffsrechte
sudo chmod -R 755 /var/www/euredomain.com
Den erstellten Ordner unter /var/www/euredomain.com/html nutzen wir als Ausgangspunkt für unsere Website. Bevor das klappt müssen wir Nginx aber noch konfigurieren. Dazu erstellen wir einen neuen Serverblock unter /etc/nginx/sites-available/.
sudo nano /etc/nginx/sites-available/euredomain.com
Fügt jetzt den folgenden Code als Start-Konfiguration ein.
server {
listen 80;
listen [::]:80;
root /var/www/euredomain.com/html;
index index.php index.html index.htm index.nginx-debian.html;
server_name euredomain.com www.euredomain.com;
location / {
try_files $uri $uri/ =404;
}
location ~ \.php$ {
include snippets/fastcgi-php.conf;
fastcgi_pass unix:/var/run/php/php7.2-fpm.sock;
}
location ~ /\.ht {
deny all;
}
}
Wir nutzen den Nano Editor dieser speichert eure Eingabe mit „STRG+O –> Enter“ und schließt das Fenster anschließend mit STRG+X.
Was machen wir hier genau?
listen – Unser Serverblock lauscht auf Port 80 nach Anfragen und zeigt anschließend den Inhalt des Verzeichnisses /var/www/euredomain.com/html.
root – Anschließend geben wir an in welchem Ordner Nginx nach Dateien suchen soll und welche Dateien als index zugelassen werden.
server – Hier geben wir an, dass der Block sich auf Anfragen die per http://www.euredomain.com sowie http://euredomain.com eintrudeln bezieht.
location / gibt an, dass wir eine 404-Fehlerseite ausgeben wenn keine index Datei gefunden wurde. „
location ~ \.php$ – verweist auf das Programm das sich um die Interpretation von PHP kümmert. In unserem Fall wird die php7.2-fpm.sock eingebunden.
location ~ /\.ht – Nginx unterstützt keine .htaccess Dateien und würde diese direkt in Klartext ausgeben. Mit dieser Einstellung verhindern wir die Ausgabe an Besucher.
Um unseren neuen Server Block beim nächsten Start von Nginx auszuführen müssen wir einen symlink zur neuen konfiguration erstellten.
sudo ln -s /etc/nginx/sites-available/euredomain.com /etc/nginx/sites-enabled/
Solltet Ihr Domains mit langen Namen nutzen, solltet Ihr noch die folgende Einstellung von Nginx aktivieren. Gebt dafür den folgenden Befehl ein:
sudo nano /etc/nginx/nginx.conf
In der Datei suchen wir den Punkt „server_names_hash_bucket_size“ und entfernen das #-Symbol davor. Speichert die Datei und schließt den Editor.
Bevor wir Nginx neu starten testen wir die neue Konfiguration.
sudo nginx -t
Hat alles funktioniert sollte der Output wie folgt aussehen.
Nun starten wir Nginx neu um die neuen Einstellungen zu aktivieren
sudo systemctl restart nginx
Ein Besuch eurer Domain sollte euch jetzt eine 404 Fehlerseite zeigen. Keine Panik, die Fehlermeldung ist korrekt, wir haben ja noch keine Dateien in unserem Public Verzeichnis. Das lässt sich schnell ändern. Wir erstellen einfach eine index.php Datei.
nano /var/www/euredomain.com/html/index.php
In die Datei fügen wir folgendes ein und speichern.
Unser Server sollte jetzt Details zur genutzten PHP Version ausgeben. Das bedeutet, dass PHP erfolgreich ausgeführt wird.
Die wir diese Informationen nicht öffentlich zugänglich machen sollten, löschen wir die index.php Datei jetzt wieder.
rm /var/www/euredomain.com/html/index.php
Nginx DSGVO Konform machen
IP Adressen anonymisieren (problematisch)
Standardmäßig speichert Nginx jede Anfrage an den Server in der access.log Datei ab. Dabei wird auch die IP-Adresse des Besuchers gespeichert. Da IP-Adressen als personenbezogene Daten gelten, haben wir die Möglichkeit die IP Adresse zu anonymisieren. Dazu nutzen wir ein kleines Script das ein findiger StackOverflow Nutzer geschrieben hat. Das Problem an der folgenden Änderung: Auch Angreifer werden durch diese Methode anonymisiert und sind somit nicht mehr nachverfolgbar. Ich empfehle die Speicherdauer der Logfiles auf 7 Tage zu minimieren (nächster Punkt) und dazu passend im Datenschutzhinweis auf die Dauer der Speicherung der Daten hinzuweisen.
sudo nano /etc/nginx/nginx.conf
Direkt nach „http {„ fügen wir den folgenden Code ein.
map $remote_addr $ip_anonym1 {
default 0.0.0;
"~(?P(\d+)\.(\d+)\.(\d+))\.\d+" $ip;
"~(?P[^:]+:[^:]+):" $ip;
}
map $remote_addr $ip_anonym2 {
default .0;
"~(?P(\d+)\.(\d+)\.(\d+))\.\d+" .0;
"~(?P[^:]+:[^:]+):" ::;
}
map $ip_anonym1$ip_anonym2 $ip_anonymized {
default 0.0.0.0;
"~(?P.*)" $ip;
}
log_format anonymized '$ip_anonymized - $remote_user [$time_local] '
'"$request" $status $body_bytes_sent '
'"$http_referer" "$http_user_agent"';
Unter „Logging Settings“ sucht Ihr jetzt nach dem Eintrag
access_log /var/log/nginx/access.log;
und ändern diesen in:
access_log /var/log/nginx/access.log anonymized;
Speichert jetzt die Datei und testet die Änderungen mit
sudo nginx -t
Hat alles geklappt starten wir Nginx neu
sudo service nginx restart
Ruft eure Website jetzt einmal auf um eine neuen Eintrag in der Access Log zu generieren. Anschließend kontrollieren wir ob die letzten Stellen der IP Adresse genullt wurden.
sudo nano /var/log/nginx/access.log
Die letzte Stelle der IP Adresse sollte ab sofort immer auf 0 gestellt werden.
Log Files automatisch löschen (empfohlen)
Logfiles sollten nach 7 Tagen gelöscht werden wenn diese personenbezogene Daten beinhalten. Wir haben die Daten bereits anonymisiert, die Änderung Logfiles statt 14 Tage nur 7 Tage aufzubewahren ist aber trotzdem keine schlechte Idee. Für die Umstellung sind auch nur ein paar zusätzliche Handgriffe notwendig. Zuerst öffnen wir die passende Konfigurationsdatei.
sudo nano /etc/logrotate.d/nginx
In der Datei Ändern wir anschließend die Zahl neben „rotate“ von 14 auf 7. Der Inhalt der Datei sollte anschließend wie folgt aussehen.
/var/log/nginx/*.log {
daily
missingok
rotate 7
compress
delaycompress
notifempty
create 0640 www-data adm
sharedscripts
prerotate
if [ -d /etc/logrotate.d/httpd-prerotate ]; then \
run-parts /etc/logrotate.d/httpd-prerotate; \
fi \
endscript
postrotate
invoke-rc.d nginx rotate >/dev/null 2>&1
endscript
}
Speichert die Datei und schließt den Editor. Wir müssen keinen service neu starten um die Änderungen zu übernehmen, da logrotate mittels crontab ausgeführt wird.
Nginx Service per Befehlszeile steuern
Damit Ihr mit Nginx ein bisschen fester im Sattel sitzt nachfolgend noch ein paar grundlegende Befehle zur Steuerung des Nginx Prozesses.
Nginx Server stoppen
sudo systemctl stop nginx
Nginx Server starten
sudo systemctl start nginx
Nginx Server neustarten
sudo systemctl restart nginx
Nginx nach Änderungen von Einstellungen neu laden
sudo systemctl reload nginx
Nginx Autostart deaktivieren
sudo systemctl disable nginx
Nginx Autostart aktivieren
sudo systemctl enable nginx
Nginx Server Logs
Sollte es zu Problemen kommen, legt Nginx z.B. Fehlermeldungen in den folgenden Dateien ab.
/var/log/nginx/access.log – Beinhaltet informationen zu allen Zugriffen
/var/log/nginx/error.log – Beinhaltet alle Fehlermeldungen
SSL Zertifikat einrichten
Für Anfragen die per HTTPS eintrudeln benötigen wir ein passendes Zertifikat. Unser Zertifikat erstelllen wir uns mit Let’s Encrypt selbst, dazu benötigen wir nur eine passende Domain die auf die IP Adresse unseres Servers zeigt. Mehr Details dazu findet Ihr weiter oben. Für die Einrichtung des Let’s Encrypt Zertifikats nutzen wir Certbot. Um die neueste Version des Packages zu erhalten, fügen wir zuerst das Repository der Entwickler hinzu.
sudo add-apt-repository ppa:certbot/certbot
Bestätigt die Eingabe mit Enter und drückt anschließend nochmals Enter um die Installation zu bestätigen. Jetzt installieren wir den Certbot für Nginx.
sudo apt install python-certbot-nginx
Dank des speziell für Nginx entwickelten Plugins ist doe Konfiguration des Zertifikats schnell erledigt. Ändert im Befehl die jeweiligen Domainnamen auf eure Domain. Nach der Bestätigung müsst Ihr eine E-Mail Adresse angeben und die AGB annehmen. Let’s Encrypt bestätigt anschließend das die gewählte Domain wirklich auf den Server zeigt. Zusätzlich habt Ihr die Möglichkeit alle HTTP Anfragen direkt zu HTTPS umzuleiten. Diese Option solltet Ihr unbedingt aktivieren. Anschließend wird das Zertifikat erstellt und automatisch für euren Nginx Server Block konfiguriert.
sudo certbot --nginx -d euredomain.com -d www.euredomain.com
Output:
Please choose whether or not to redirect HTTP traffic to HTTPS, removing HTTP access.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
1: No redirect - Make no further changes to the webserver configuration.
2: Redirect - Make all requests redirect to secure HTTPS access. Choose this for
new sites, or if you're confident your site works on HTTPS. You can undo this
change by editing your web server's configuration.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Select the appropriate number [1-2] then [enter] (press 'c' to cancel): 2
Redirecting all traffic on port 80 to ssl in /etc/nginx/sites-enabled/euredomain.com
Redirecting all traffic on port 80 to ssl in /etc/nginx/sites-enabled/euredomain.com
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Congratulations! You have successfully enabled https://euredomain.com and
https://www.euredomain.com
You should test your configuration at:
https://www.ssllabs.com/ssltest/analyze.html?d=euredomain.com
https://www.ssllabs.com/ssltest/analyze.html?d=www.euredomain.com
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
IMPORTANT NOTES:
- Congratulations! Your certificate and chain have been saved at:
/etc/letsencrypt/live/euredomain.com/fullchain.pem
Your key file has been saved at:
/etc/letsencrypt/live/euredomain.com/privkey.pem
Your cert will expire on 2019-05-22. To obtain a new or tweaked
version of this certificate in the future, simply run certbot again
with the "certonly" option. To non-interactively renew *all* of
your certificates, run "certbot renew"
- Your account credentials have been saved in your Certbot
configuration directory at /etc/letsencrypt. You should make a
secure backup of this folder now. This configuration directory will
also contain certificates and private keys obtained by Certbot so
making regular backups of this folder is ideal.
- If you like Certbot, please consider supporting our work by:
Donating to ISRG / Let's Encrypt: https://letsencrypt.org/donate
Donating to EFF: https://eff.org/donate-le
Das hat geklappt. Besucht jetzt eure Domain, die Anfrage die vorher über http:// durchgegangen ist, sollte jetzt auf https:// weitergeleitet werden. Sofern euer Browser keine Warnmeldung im Bezug auf das verwendete Zertifikat anzeigt sind wir so gut wie fertig. Let’s Encrypt Zertifikate haben ein Ablaufdatum, wir müssen also noch testen ob die automatische Verlängerung auch wirklich funktioniert. Dafür führen wir den folgenden Befehl aus.
sudo certbot renew –dry-run
Output:
Congratulations, all renewals succeeded. The following certs have been renewed:
/etc/letsencrypt/live/euredomain.com/fullchain.pem (success)
** DRY RUN: simulating 'certbot renew' close to cert expiry
** (The test certificates above have not been saved.)
MySQL Server installieren und konfigurieren
Eine MySQL Datenbank darf auf unserem Server natürlich nicht fehlen. Wir starten also direkt die Installation.
sudo apt install mysql-server
MySQL bietet einen Wizard der uns durch die Installation führt und uns auf diverse wichtigen Themen aufmerksam macht. Den Wizard starten wir mit folgendem Befehl:
sudo mysql_secure_installation
Output:
Securing the MySQL server deployment.
Connecting to MySQL using a blank password.
VALIDATE PASSWORD PLUGIN can be used to test passwords
and improve security. It checks the strength of password
and allows the users to set only those passwords which are
secure enough. Would you like to setup VALIDATE PASSWORD plugin?
Das Validate Password Plugin hilft dabei unsichere Kennwörter zu blockieren. Wir nutzen das Plugin und bestätigen mit „y“
There are three levels of password validation policy:
LOW Length >= 8
MEDIUM Length >= 8, numeric, mixed case, and special characters
STRONG Length >= 8, numeric, mixed case, special characters and dictionary file
Please enter 0 = LOW, 1 = MEDIUM and 2 = STRONG:
Nun müssen wir uns entscheiden wie scharf die Passwortkontrolle ablaufen soll. Ich wähle hier Medium (also die Option 1), da es ein guter Kompromiss zwischen Sicherheit und Nutzbarkeit ist.
Please set the password for root here.
New password:
Gebt jetzt das gewünschte Passwort mit Berücksichtigung der Vorgaben ein und bestätigt die Eingabe. Alle weiteren Abfragen sollten mit „y“ bestätigt werden.
Output:
By default, a MySQL installation has an anonymous user,
allowing anyone to log into MySQL without having to have
a user account created for them. This is intended only for
testing, and to make the installation go a bit smoother.
You should remove them before moving into a production
environment.
Remove anonymous users? (Press y|Y for Yes, any other key for No) : y
Success.
Normally, root should only be allowed to connect from
'localhost'. This ensures that someone cannot guess at
the root password from the network.
Disallow root login remotely? (Press y|Y for Yes, any other key for No) : y
Success.
By default, MySQL comes with a database named 'test' that
anyone can access. This is also intended only for testing,
and should be removed before moving into a production
environment.
Remove test database and access to it? (Press y|Y for Yes, any other key for No) : y
- Dropping test database...
Success.
- Removing privileges on test database...
Success.
Reloading the privilege tables will ensure that all changes
made so far will take effect immediately.
Reload privilege tables now? (Press y|Y for Yes, any other key for No) : y
Success.
All done!
Das wars auch schon wieder, MySQL ist jetzt auf dem Server eingerichtet. Sofern Ihr phpMyAdmin nutzen möchtet, solltet Ihr dafür einen eigenen Nutzer anlegen. Aus Sicherheitsgründen solltet Ihr bei der Erstellung eines neuen Nutzers ausschließlich Verbindungen über den localhost zulassen. Für die Erstellung verbinden wir uns zuerst mit der Datenbank.
sudo mysql
Neuen Nutzer erstellen:
CREATE USER 'username'@'localhost' IDENTIFIED BY 'deinpw';
GRANT ALL PRIVILEGES ON *.* TO 'phpmyadmin'@'localhost' WITH GRANT OPTION;
FLUSH PRIVILEGES;
Diesen erstellten Nutzer kann man anschließend z.B. für phpMyAdmin nutzen um auf die Datenbank zuzugreifen. Nutzer können auch auf die jeweiligen Datenbanken beschränkt werden.
Zusätzliche Server Sicherheit
Fail2Ban
Wir verbinden uns über das Internet mit unserem Server, was bedeutet das andere dies theoretisch auch tun können. Speziell beim Einsatz einer simplen „User/Passwort“ Authentifizierung können Angreifer z.B. mittels Bruteforce millionenfach Kennwörter ausprobieren um Zugang zum Server zu erlangen. Solltet Ihr euch per SSH Keys mit dem Server verbinden habt Ihr bereits einen Vorteil, eine zusätzliche Sicherheitsabfrage ist aber immer eine gute Idee. Fail2Ban überwacht die Logfiles eures Servers und sucht nach gescheiterten Login Versuchen und setzt bei einer von euch gewählten Anzahl an gescheiterten Versuchen die IP des Angreifers auf eine Sperrliste. Angreifer haben damit also z.B. nur 3 Versuche euer Kennwort herauszufinden bevor die Sperre greift und der Server alle Verbindungen zu der jeweiligen Adresse ablehnt. Jetzt stellt sich natürlich die Frage, ob dies auch mit der DSGVO vereinbar ist. Meiner Meinung nach greift hier das berechtigte Interesse nicht gehacked zu werden und natürlich auch die Pflicht Daten zu schützen. Die Entscheidung für oder gegen Fail2Ban liegt aber bei euch, für fundierte rechtliche Auskunft bin ich leider nicht die richtige Ansprechperson.
Nichts desto trotz hier eine schnelle Einführung in Fail2Ban.
Installation:
sudo apt-get install fail2ban
Aktivierung des Prozesses beim Serverstart und starten von Fail2Ban
sudo systemctl start fail2ban
sudo systemctl enable fail2ban
Der service sollte jetzt laufen, wir brauchen nur noch eine passende Config Datei, diese erstellen wir mit:
sudo nano /etc/fail2ban/jail.local
In die Datei fügen wir die folgende Startkonfiguration ein:
[sshd]
enabled = true
port = 22
filter = sshd
logpath = /var/log/auth.log
maxretry = 3
Speichert die Datei jetzt und schließt den Editor mit STRG + X. Um die Änderungen zu übernehmen starten wir den service neu.
sudo systemctl restart fail2ban
Ab sofort werden Angreifer nach drei fehlgeschlagenen Loginversuchen ausgesperrt. Ihr könnt Fail2Ban jetzt natürlich selbst ausprobieren, geht davor aber auf Nummer sicher, dass Ihr abseits von SSH noch eine Möglichkeit habt euch mit dem Server zu verbinden.
IP Adresse aus Sperrliste entfernen:
Um eine IP Adresse aus der Sperrliste zu löschen könnt Ihr folgenden Befehl verwenden (statt IP_ADRESSE muss natürlich die betroffene IP Adresse angegeben werden:
sudo fail2ban-client set sshd unbanip IP_ADRESSE
Damit habt Ihr Fail2Ban rudimentär konfiguriert. Mehr über die Benutzung dieses essentiellen Tools bekommt Ihr über die Kommandozeile:
man fail2ban
Fazit
Euer Server ist jetzt bereit für den Einsatz. Speziell in Sachen Sicherheit gibt es viele Möglichkeiten euren Server vor unbefugten Zugriffen zu schützen. In den nächsten Schritten könnt Ihr euch z.B. über Server Monitoring /blog/linux-root-server-vserver-monitoring informieren. Auch in Sachen Sicherheit gibt es noch einige Punkte die wir in dieser Anleitung nicht durchgegangen sind. Solltet Ihr über eine statische IP Adresse ins Internet gehen empfiehlt es sich auch den Zugang zu SSH auf eure IP-Adresse einzuschränken. Externe Anfragen die nicht von euch kommen werden dadurch direkt blockiert. Es gibt immer was zu lernen und das ist auch gut so.