Letsencrypt installieren

Letsencrypt ist ein Open Source Projekt, welches kostenlos SSL Zertifikate zur Verfügung stellt die inzwischen auch von den meisten Browsern, Anwendungen und Apps unterstützt werden.

Damit gibt es also keinen sinnvollen Grund mehr Verbindungen zu  Serverdiensten (z. B. Webserver, EMail etc.) unverschlüsselt zu lassen.

Unter Ubuntu 18.04 wird Letsencrypt bereits in den apt-Quellen angeboten. Zusätzlich können noch Plugins für Apache oder Nginx installiert werden, welche die Anforderung, Installation, Einrichtung und Aktualisierung der Zertifikate automatisch vornehmen können!

Wie fast immer unter Linux ist die Installation schnell und einfach zu erledigen. Allerdings müsst Ihr Euch evtl. entscheiden ob Ihr das Paket ‚python3-certbot-apache‚ oder ‚python3-certbot-nginx‚ installieren wollt. Das hängt natürlich davon ab welchen Webserver Ihr einsetzt 😉

Im nachfolgenden Beispiel habe ich Nginx als Webserver eingesetzt:

apt install certbot python-certbot-nginx

Einrichtung Zertifikate (Beispiel nginx)

Nun, das war schon die Installation. Nun möchten wir aber noch sehen wie der Certbot die Zertifikate installiert. Für unsere Beispiel nehme ich die Grundkonfiguration für die Domain ‚www.meine-dolle-domain.de‘. Ich gehe davon aus, dass der diese Domain im Verzeichnis ‚/etc/nginx/sites-enabled‘ eingerichtet ist. Die Grundkonfiguration könnte z. B. so aussehen:

server {
    listen 80;
    server_name www.meine-dolle-domain.de;
    root /var/www/meine-dolle-domain.de;
    index index.html;
    location / {
        try_files $uri $uri/ =404;
    }
}

Um nun für alle unter ‚/etc/nginx/sites-enabled‘ eingerichteten Domains auf SSL mit Letsencrypt Zertifikat umzustellen (Beachte Grundsatz: Keine unverschlüsselten Verbindungen!) geben wir einfach den Befehl

certbot --nginx

ein. Certbot durchsucht nun die vorhandenen Konfigurationen und bietet Ihnen entsprechende Auswahlmenüs für Domain und automatisches SSL Redirect die Du beantworten bzw. auswählen musst. Die ausführliche Beschreibung der Menüs und der Ausgabe erspare ich uns hier mal.

Im Ergebnis sollten Iht z. B. für das o. g. Beispiel sehen können, dass nicht nur ein entsprechendes Zertifikat installiert wurde, sondern auch gleich die Webserver-Konfigurationsdatei für die Domain ‚www.meine-dolle-domain.de‘ automatisch auf SSL umgestellt wurde. Dies könnt Ihr auch im folgenden Beispiel schön sehen

server {
    server_name www.meine-dolle-domain.de;
    root /var/www/meine-dolle-domain.de;
    index index.html;
    location / {
        try_files $uri $uri/ =404;
    }
    listen 443 ssl; # managed by Certbot
    ssl_certificate /etc/letsencrypt/live/support.computerfritze.net/fullchain.pem; # managed by Certbot
    ssl_certificate_key /etc/letsencrypt/live/support.computerfritze.net/privkey.pem; # managed by Certbot
    include /etc/letsencrypt/options-ssl-nginx.conf; # managed by Certbot
    ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; # managed by Certbot
}

Testen

Gut, dass mit dem testen ist einfach! Bloss die Domain im Browser aufrufen. Wenn Ihr das SSL Redirect bei der Certbot- Konfiguration gewählt habt (eindringlich empfohlen!), sollte Ihr nun automatisch auf die HTTPS-Seite weiter geleitet werden. Ansonsten müsst Ihr halt das ‚HTTPS://‘ Eurer Domain in der Browser-Adresszeile voran stellen.

Rootkit- & Exploit-Jäger ‚rkhunter‘ installieren

Zum installieren einfach auf der Shell

apt install rkhunter

eingeben.

Anschließend die Datenbank von rkhunter mit folgendem Befehl installieren

rkhunter --update

Natürlich müssen die Logfiles von rkhunter regelmäßig überprüft werden. Automatische Benachrichtigungen können u. a. mit Hilfe des Pakets ‚mailutils‘ eingerichtet werden. Aber dazu kommen wir später

Zertifikatsbasierten Login für Hauptbenutzer einrichten

Im letzten Teil haben wir uns den Hauptbenutzer ‚ myadm‘ eingerichtet. Mit diesem Benutzer können wir uns nun per SSH auf dem Server anmelden und per ’sudo‘ mit ‚root‘ Rechten an dem Server arbeiten.

Im nächsten Schritt wollen wir das Konto so umstellen, dass der Login mit einem Zertifikat (Zertifikat = ein Art elektronischer Ausweis) erfolgen kann. In einem späteren Schritt ändern wir die SSH Konfiguration so, dass der Login nur noch mit Hilfe eines Zertifkats möglich ist.

Dadurch muss das Passwort für den Hauptbenutzer in Zukunft nicht mehr übertragen werden. Dadurch kann das Passwort auch nicht ‚man in the middle‘ Attacken abgefangen werden. Zusätzlich ist das Zertifkat über ein Passwort gesichert, welches ich aber nur lokal (also auf meinem Rechner) eingeben muss.

Zertifkat für SSH erstellen (private & public key)

Falls Ihr keine eigene PKI-Infrasruktur für die Erstellung und Verwaltung von Zertifikaten betreibt, wird es vermutlich reichen, wenn Ihr das Zertifikat selbst erstellt. In dem Beispiel gehe ich davon aus, dass Ihr ein Zertifikat für den Benutzer ‚myadm‘ einrichten wollt. Dazu öffnet Ihr ein Terminal und haut mal folgenden Befehl raus:

ssh-keygen -t rsa -b 4096
Generating public/private rsa key pair.
Enter file in which to save the key (/home/myadm/.ssh/id_rsa): /home/myadm/.ssh/myadm
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/myadm/.ssh/myadm.
Your public key has been saved in /home/myadm/.ssh/myadm.pub.
The key fingerprint is:
SHA256:3X+IXJNfrCRGQPkDs3lpfW5WEgqfI6+UKJ23fZ+gdbA martin@cof0004
The key's randomart image is:
+---[RSA 4096]----+
| .o. |
| =. . |
| O.= . |
| .+o@ ooo|
| .So.++=++| | . + +o.o==|
| . o +oE++o|
| o + +..|
| . . o.|
+----[SHA256]-----+

Bitte das Passwort nicht einfach leer lassen nur weil ‚key-gen‘ sagt es sei optional! Okay, im Ergebnis habt Ihr jetzt zwei neue Dateien im Verzeichnis ‚/home/myadm/.ssh‘ liegen:

myadm – dies ist der private Schlüssel des Zertifkates und wird nie, nie, aber wirklich niemals aus der Hand gegeben!

myadm.pub – ist der öffentliche Teil des Schlüssels, der aber nur mit dem’private key‘ zusammen genutzt werden kann.

Für die Nutzung des privaten Schlüssels ist dann noch das Passwort erforderlich.

SSH Anmeldung mit Zertifkat

Damit sich unser frisch gebackener Admin ‚myadm‘ auch mit dem Zertifkat an dem Server anmelden kann, müssen wir den öffentlichen teil des Zertifkates (also im Beispiel die Datei ‚myadm.pub‘ noch im Benutzerverzeichnis auf dem Server hinterlegen. Das geht ganz einfach mit dem Befehl:

ssh-copy-id -i ~/.ssh/<ZERTIFIKAT>.pub <BENUTZERNAME>@<SERVERNAME>

Der befehl fragt nun nach dem Passwort des Benutzers <BENUTZERNAME> und kopiert dann den öffentlichen Schlüssel des Zertifikats in die Datei ‚/home/<BENUTZERNAME>/.ssh/authorized_keys‘ auf dem Server.

Test

Sehr Wichtig: Nun testen ob die Anmeldung mittels Zertifikat funktioniert!

Dazu öffnet Ihr bitte ein zweites Terminal und versucht Euch mit folgendem Befehl anzumelden.

ssh -i ~/.ssh/<ZERTIFIKAT>.pub <BENUTZERNAME>@<SERVERNAME> 

Nun sollte ’ssh‘ nach Eurem Passwort für die Nutzung den privaten Teil des Schlüssels fragen und sich anschließend sofort automatisch anmelden. Es ist für die nächsten Schritte sehr, sehr wichtig, dass Ihr diesen Zugang testet! Wir stellen nämlich die Konfiguration so um dass man sich zukünftig nur noch mit einem gültigen Zertifikat anmelden kann und es besteht die Gefahr, dass Ihr Euch komplett von dem Server ausschließt…..

Linux Webserver einrichten und betreiben

Hier beschreibe ich eine Möglichkeit wie Ihr Euren eigen Webserver mit Linux einrichten und einigermaßen sicher betreiben könnt.

Wichtig ist, sich darüber im Klaren zu sein, dass die Installation des Servers das Wenigste ist. Wichtiger ist den Server im laufenden Betrieb regelmäßig zu überprüfen und zu warten! Wer dazu keine Lust hat, sollte am Besten gar nicht erst einen eigenen Server betreiben, weil er über kurz oder lang ein Sicherheitsrisiko für sich, seine Benutzer und alles anderen Im Internet darstellt.

Ich beschreibe im Folgenden kurz die Schritte zur Installation unseres Webservers und verweise in den entsprechenden Absätzen auf die jeweilige Detailbeschreibung. Wer es eilig hat oder schon weiß was er will, kann auch im nebenstehenden Kasten direkt auf den Artikel klicken.

Nun fangen wir aber mit der Installation an. Ich gehe davon aus, Ihr habt Euch irgendwo bei einem Hoster einen Server gemietet und bereits ein Ubuntu 16.04 oder 18.04 installieren lassen. Wollt Ihr zuhause einen Server installieren, installiert halt den Minimalen Ubuntu Server mit SSH.

Bitte nehmt für einen Server nur die geraden Ubuntu-LTS-Versionen mit Langzeitsupport!

Nun aber los!

1. ‚root‘ Passwort ändern.

Falls Ihr das Betriebssystem (hier Ubuntu Server 16.04/18.04) selber installiert habt, werdet Ihr schon ein eigenes Passwort vergeben haben. Falls Ihr den Server vorinstalliert vom Hoster übernommen habt, ist der erste Schritt die Einrichtung eines eigenen ‚root‘ Passworts. Wie das geht erfahrt Ihr im Artikel ‚Passwort für Benutzer ‚root‘ ändern

2. Administrative Benutzer einrichten.

Auch dieser Schritt ist wahrscheinlich nicht erforderlich, wenn Ihr Euren Server selber installiert habt. Dann habt Ihr bei der Installation schon einen Hauptbenutzer angelegt, der die Erlaubnis hat mittels ’sudo‘ auch mit ‚root‘ Rechten zu arbeiten. Habt Ihr den Server vom Hoster ist meist nur der Benutzer ‚root‘ vorinstalliert und Ihr solltet einen ‚Administrativen Hauptbenutzer einrichten mit dem Ihr bei Bedarf ‚root‘ Rechte mittels sudo ausüben dürft. Der direkt Zugang von außen (z. B. via SSH) wird für den Hrrn ‚root‘ später aus Sicherheitsgründen gesperrt.

Und hier erfahrt Ihr wie Ihr einen ‚administrativen Hauptbenutzer einrichtet‚.

3. Zertifkatsbasierter Login Hauptbenutzer

Einfach weil es sicherer und komfortabler ist, richten wir den Zugang des Hauptbenutzers so ein, dass ein Zertifikat (= elektronischer Ausweis) mit einem Passwort zur Anmeldung und eindeutigen Identifikation ausreicht.

Wie das im Detail funktioniert erfahrt Ihr im Artikel ‚Zertifikatsbasierten Login für Hauptbenutzer einrichten‚.

4. SSH Server konfigurieren

So, nun ist es Zeit den SSH Server so einzustellen, dass eine direkte Anmeldung des Benutzers ‚root‘ verboten wird und gleichzeitig der Login nur noch über Zertifkate erfolgen darf. Wie das geht, wird im Artikel ‚SSH Server / Deamon konfigurieren‚ beschrieben.

5. System aktualisieren

Nun haben wir ja schon eine einigermaßen sichere Ausgangskonfiguration. Zeit um das ‚System zu aktualisieren‚.

6. Rootkit-Jäger ‚rkhunter‘ installieren

Die Software ‚rkhunter‘ ist eine Art Anti-Schadsoftware-Scanner die sich spezielle auf sogenannte ‚root kits‘ und andere lokale Exploits (Exploits = Sicherheitslücken) prüft. Da die Ausgaben des Programms z. T. techn. Hintergrundwissen verlangt, ist es eigentlich eher etwas für gestandene Admins, aber wir werden uns dem Schritt für Schritt annähern. Zunächst einmal wollen aber den ‚Rootkit- & Exploit-Jäger ‚rkhunter‘‚ installieren.

7. SSH Angriffe ausbremsen mit ‚fail2ban‘

Wer Server im Internet betreibt, kennt das. Täglich hunderte (oder mehr?) Versuche sich auf dem Server per SSH anmelden. Das nervt und müllt die Logfiles voll :-). Dagegen bietet ‚fail2ban‘ das richtige Mittel!

Wird sich von einer IP-Adresse mit einem falschen Passwort angemeldet, wird dieser Versuch von ‚fail2ban‘ registriert. Finden nun 3 Versuche mit falschem Passwort statt, wird diese IP-Adresse für eine Weile gesperrt. Damit werden sogenannte ‚Brute Force Attacken‘ ( = das automatisierte Ausprobieren von vielen, vielen Passwörtern) zwar nicht verhindert aber ganz gewaltig ausgebremst und damit mehr oder minder sinnlos.

Ein schöner Nebeneffekt ist, dass auch nciht mehr soviele Einträge über falsche Anmeldeversuche in der Logdatei auftauchen.

Wie Ihr diese kleine aber feine Software installiert steht im Artikel ‚fail2ban installieren‚.

8. Die Firewall ’shorewall‘ installieren

Okay, die Sache mit der Firewall. Eigentlich ist so eine Firewall bei einem sauber konfigurierten Server nicht wirklich nötig. Wer – wie ich – grundsätzlich prüft, dass auf dem Server wirklich nur die Ports geöffnet sind die ich brauche, braucht so eine Firewall nicht wirklich. Schließĺich prüft die auch nur ob die Nutzung eines Ports erlaubt ist oder nicht.

Aber! Mir ist es schon mehrfach passiert, dass ich beim herum konfigurieren am Server doch versehentlich (und meist nur vorübergehend) einen Port freigeschaltet habe. Schließlich basteln wir hier an sehr komplexen Konfigurationen und da macht man auch schon mal Fehler….

Hier finde ich dann eine Firewall als zweiten „Schutzwall“ ganz hilfreich. Schalte ich nun versehentlich mal einen nicht benötigten Port frei, passiert gar nichts, weil die Firewall diesen Port sperrt solange ich in der Firewall nichts anderes konfiguriere.

Allerdings sollte man hier im Artikel ‚Shorewall – Firewall installieren und einrichten‚ beschrieben Firewall Konfiguration wirklich vorsichtig, langsam und gründlich arbeiten.

9. Webserver installieren

Als nächstes installieren wir den Webserver Apache 2. Dabei sorgen wir dafür, dass alle Verbindungen zum Webserver ausschließlich per SSL, also mit dem Protokoll HTTPS, verschlüsselt werden. Dies ist inzwischen auch zwingend per Gesetz (DSGVO) vorgeschrieben.

Allerdings benötigen wir für die HTTPS Verbindungen entsprechende Zertifikate. Dafür nutzen wir die kostenlose Dienstleistung von ‚letsenrycpt‘. Wie ihr Letsencrypt installiert und einrichtet steht in dem Artikel ‚Letsencrypt installieren‚.

Anschließend installieren wir den (blanken) Webserver und konfigurieren diesen auf SSL-Only Betrieb. Wie das geht erfahrt ihr im Artikel ‚Apache 2 „ssl-only“ installieren‘.

Wie gesagt, wir haben jetzt nur eine „nackten“ Webserver.Der im Wesentlichen nur statische Seiten hosten kann. Um Anwendungen zu nutzen (z. B. WordPress) müssen noch einige Module und zusätzliche Programme (z. B. PHP) installiert werden.

Um nur die elementaren Pakete für PHP zu installieren, reicht folgendes Kommando:

apt install ibapache2-mod-php7.2 php7.2-cli php7.2-common

Im Falle von WordPress wären dies z. B. folgende Pakete:

apt install apache2-bin apache2-data apache2-utils fontconfig-config fonts-dejavu-core javascript-common libaio1 libao-common libao4 libapache2-mod-php libapache2-mod-php7.2 libapr1 libaprutil1 libaprutil1-dbd-sqlite3 libaprutil1-ldap libflac8 libfontconfig1 libgd3 libjbig0 libjpeg-turbo8 libjpeg8 libjs-cropper libjs-prototype libjs-scriptaculous liblua5.2-0 libogg0 libphp-phpmailer libsodium23 libspeex1 libtiff5 libvorbis0a libvorbisenc2 libvorbisfile3 libwebp6 libxpm4 mariadb-client-10.1 mariadb-client-core-10.1 mariadb-common php-common php-gd php-getid3 php-mysql php7.2-cli php7.2-common php7.2-gd php7.2-json php7.2-mysql php7.2-opcache php7.2-readline ssl-cert vorbis-tools

10. Mysql / MariaDB installieren

So, nun brauchen wir noch ein Datenbank-Managent-System und dann ist unser LAMP System erst mal fertig. Wichtig bei produktiven Systemen ist dass ihr nach der Installation des Mysql Server das Script ‚mysql_secure_installation‘ ausführt.

Aber das ist natürlich auch alles im Artikel ‚MySQL installieren und absichern‚ ausführlich beschrieben.

System aktualisieren

…. tja, was wohl… na klar! Auf die root-Shell!

Dann Reposirories aktualisieren

apt update

Und vor dem eigentlichen Update erstemal prüfen, was Ubuntu denn so alles aktualisieren möchte

apt -s safe-upgrade

Wenn mit den Aktualsierungsvorschlägen einverstanden sind, führen wir das Update durch

apt safe-upgrade

Fall Kernel oder zentrale Bibliotheken (z. B. libc) aktualisiert wurden, müssen wir den Server einmal neu starten (kann aber auch später gemacht werden…..)

shutdown -r now

…und fertisch!

MySQL installieren und absichern (Debian, Raspbian Ubuntu…)

Nahezu alle Webanwendungen (z.B. WordPress, Joomla, etc.) unterstützen mindestens MySQL oder setzen sogar explizit MySQL für den Betrieb der Anwendung voraus.

Ich persönlich bevorzuge auf lizenzrechtlichen Überlegungen zwar eher PostgresSQL, aber das wird nicht von allen Anwendungen unterstützt. Alternativ käme noch MariaDB in Betracht, welches 100% OpenSource ist und vollständig kompatibel zu MySQL sein soll. Hier fehlen mir aber noch konkrete Testergebnisse, sodass es vorerst bei MySQL als fester Bestandteil des LAMP-Systems erhalten bleibt.

Der MySQL Server wird nur als „lokaler“ MySQL-Server eingerichtet, d. h. MySQL ist nicht aus dem Neztwerk erreichbar und nur für Anwendungen nutzbar, die auch auf dem gleichen Rechner / Server laufen wie das MyQL DBMS.
Warnung: Wer seinen MySQL auch im Netz verfügbar machen möchte, sollte genau wissen was er tut und in der Lage sein die Sicherheitsrisiken zu erkennen und zu bewerten!!!

Wie immer melden wir uns als „root“ auf dem zukünftigen MySQL-Server an und installieren zunächst den MySQl-Server und den MySQL-Client

apt install mysql-server mysql-client

Möchten wir MySQL auch mit PHP unter dem Apachen benutzen (z. B. LAMP -System) müssen wir noch die entsprechenden PHP-Bibliotheken installieren.

apt install php-mysql

Weitere Pakete können erforderlich sein. Dies hängt aber von den Anwendungen ab, die auf dem Server / Computer betrieben werden sollen…

Während der Installation fragt das Installationsscript nach einem „root“ Passwort. Ich persönlich lasse hier das Passwort immer leer und bestätige den Dialog einfach mit „OK„.

Nachdem „aptitude“ fertig installiert hat, machen wir den MySQL etwas sicherer indem wir folgendes Script starten:

mysql_secure_installation

Die erste Abfrage „Enter current password for root (enter for none):“ beantworten wir einfach mit „ENTER“ (wenn wir noch kein Passwort vergeben haben) oder geben das Passwort für den MySQL-Benutzer „root“ ein.

Nun fragt das Script ob wir ein „root“-Passwort vergeben wollen. Wir bestätigen dies mit „Y“ und „ENTER

Set root password? [Y/n] Y

Nun bittet uns das Script ein neues „root„-Passwort zu vergeben. Hier gebe ich dann ein entsprechend sicheres Passwort ein….

New password:

… und bestätigen das Passwort durch nochmalige Eingabe…

Re-enter new password:

Im nächsten Dialog bietet uns das Script an die im MySQL-Server vordefinierten anonymen Benutzer zu löschen. Ich halte anonymes Zugriffe auf Datenbanken für keine gute Idee und stimme dieser Frage aus vollem Herzen zu…..

Remove anonymous users? [Y/n] Y

Ebenfalls so ein offenes Scheunentor ist die Voreinstellung, dass der „root“ Benutzer der MySQL sich direkt aus dem Netzwerk am MySQL-Server anelden kann. Daher lassen wir den Netzwerkzugang für den Benutzer „root“ löschen! Damit ist ein Zugang auf den MySQL-Server als „root“ nur noch möglich, wenn ich auf dem Rechner lokal oder per SSH angemeldet bin.

Disallow root login remotely? [Y/n] Y

MySQL bringt während der Installation eine Test-Datenbank mit. Wie der Name schon sagt ist die zum „testen“ gedacht. Sowas gehört nun nicht in ein produktives Umfeld, also bitten wir das Script diese Datenbank zu löschen…

Remove test database and access to it? [Y/n] Y

Falls die Test-Datenbank nicht vorhanden ist, wird dies in einer kurzen nicht kritischen Fehlermeldung erwähnt und das Skript arbeitet weiter.

Und selbstverständlich soll MySQL die Rechteänderungen sofort vornehmen und wir bitte das Script dafür zu sorgen, dass der MySQL die Rechtetabellen neu einliest…

Reload privilege tables now? [Y/n] Y

Damit ist das Script fertig und bedankt sich i. d. R. mit einem freundlichen „Thanks for using MySQL!

Vorsichtshalber öffnen wir noch mal die Datei „/etc/mysql/mysql.conf.d/mysqld.cnf installieren und absichern (Debian, Raspbian Ubuntu…)“ und kontrollieren den Eintrag „bind-address„. Der sollte per Voreinstellung wie nachfolgend dargestellt auf das lokale Loopback-Device zeigen:

bind-address = 127.0.0.1

Sollte dies nicht der Fall sein, diesen Eintrag bitte wie oben gezeigt anpassen und den MySQL-Server neu starten.

Der MySQL-Server ist jetzt in einem halbwegs sicheren und ordentlichen Zustand und kann produktiv genutzt werden.

Apache 2 ’ssl-only‘ installieren

Wir wollen einen Apachen installieren und so einrichten, dass er nur unter SSL auf Port 443 läuft. Damit ist die Verbindung zwischen Endanwender und den vom Apachen gehosteten Seiten und Anwendungen immer verschlüsselt. Dies ist Standard-Betriebsmodus für alle unsere Apache2-Server die über Internet erreichbar sind.

Wir melden uns (wie immer) als ‚root‘ auf der Server-Shell an und installieren erst mal den Apachen.

apt install apache2

Nun editieren wir die Datei „/etc/apache2/ports.conf

pico /etc/apache2/ports.conf

Die beiden folgenden Zeilen müssen nun wie folgt auskommentiert (auskommentieren = Zeile am Anfang mit Kommentarzeichen versehen) werden:

# NameVirtualHost *:80
# Listen 80

Bitte kontrollieren ob die nachfolgenden Zeilen ebenfalls in der Datei stehen und nicht (!!!) auskommentiert sind. Evtl. stehen da noch mehr Einträge, aber diese müssen auf jeden Fall da stehen:

<IfModule mod_ssl.c>
    Listen 443
</IfModule>

<IfModule mod_gnutls.c>
    Listen 443
</IfModule>

Nun erstellen wir exemplarisch eine initiale Konfig für einen VirtualHost. Dazu erstellen wir die Konfigurationsdatei „/etc/apache/sites-available/000-default-ssl.conf“ (Für den Betrieb von Seiten und/oder Anwendungen müssen natürlich andere und/oder weitere Konfiguration (z. B. VirtualHosts) vorgenommen werden.) …

pico /etc/apache2/sites-available/000-default-ssl.conf

… wir füllen diese Datei mit folgendem Inhalt (Platzhalter ‚<…>‘ bitte anpassen), speichern („STRG+o„) und schließen („STRG-x„) den Editor.

<VirtualHost <IP-ADRESSE>:443>
    ServerName <DER.SERVER.NAME>
    DocumentRoot /var/www/<VERZEICHNIS>
    SSLEngine on
    SSLCertificateFile /etc/ssl/certs/<ZERTIFIKATSDATEI>.crt 
    SSLCertificateKeyFile /etc/ssl/private/<SCHLUESSEL>.key
</VirtualHost>

Die Datei noch bei ‚Enableds‘ verlinken

ln -s /etc/apache2/sites-available/000-default-ssl.conf /etc/apache2/sites-anabled/

Evtl. noch den symbolischen Link ‚/etc/apache2/sites-enabled/000-default.conf‘ mit einem entschlossenem ‚rm‘ entfernen und ggf. darauf achten, dass der Port 443 des Servers auch erreichbar ist (Firewall, Router etc.).

Nun muss man noch SSL aktivieren dies macht man mit :

a2enmod ssl

Das war’s fast schon. Den alten Indianer noch mal neu starten:

/etc/init.d/apache2 restart

Und ab jetzt lauscht er nur noch auf Port 443 (‚https‘).

Shorewall – Firewall installieren und einrichten

Für Shorewall Version 5.0.4

Wie immer als root auf dem Server anmelden und über apt shorewall installieren:

apt install shorewall

Die erforderlichen Konfigurationsdaten aus dem Beispielen heraus kopieren:

cp /usr/share/doc/shorewall/examples/one-interface/interfaces /etc/shorewall/
cp /usr/share/doc/shorewall/examples/one-interface/zones /etc/shorewall/
cp /usr/share/doc/shorewall/examples/one-interface/policy /etc/shorewall/
cp /usr/share/doc/shorewall/examples/one-interface/rules /etc/shorewall/

Und nun die Datei /etc/shorewall/interfaces mit einem Editor öffnen und den Inhalt kontrollieren bzw. entsprechend den nachfolgenden Zeilen anpassen:

##########################################################
#ZONE INTERFACE OPTIONS
net eth0 dhcp,tcpflags,logmartians,nosmurfs,sourceroute=0

OK, das meiste was da steht ist, glaube ich, verständlich. Wir sagen hier im Wesentlichen, dass wir eine Netzwerkkarte eth0 haben, die wir der Zone (kommt gleich…) net zuordnen. Wenn ihr nicht sicher seit ob eure Netzwerkkarte wirklich ‚eth0‘ heißt, schaut bitte in der Datei ‚/etc/network/interfaces‘ nach. Natürlich können hier bei Bedarf auch mehr Interfaces und Zonen definiert werden.

Besonderheit Strato vServer

Beim Strato vServer heißt das Interface nicht ‚eth0‘ sondern ‚venet0‘. Die Einstellungen sind entsprechen anzupassen.

Jetzt die Datei /etc/shorewall/zones mit einem Editor öffnen und den Inhalt kontrollieren bzw. entsprechend den nachfolgenden Zeilen anpassen:

##########################################################
#ZONE TYPE OPTIONS IN OUT
# OPTIONS OPTIONS
fw firewall
net ipv4

Hier haben wir jetzt zwei Zonen definiert. Einerseits haben wir die Firewall selbst fw als  Zone vom Typ firewall festgelegt. Dabei steht fw letztlich auch als Synonym für den den Rechner selbst, da aller Netzwerkverkehr ja über die Firewall läuft. In der zweiten Zeile definieren wir eine Zone net vom Typ ipv4. Die Zone net hatten wir ja schon zuvor an die Netzwerkkarte eth0 gebunden, somit steht net für den gesamten Netzwerkverkehr der nach außen oder von außen kommt.

Jetzt die Datei /etc/shorewall/policy mit einem Editor öffnen und den Inhalt kontrollieren bzw. entsprechend den nachfolgenden Zeilen anpassen:

########################################################################
 SOURCE         DEST            POLICY          LOG LEVEL    LIMIT:BURST
 $FW             net             DROP
 net             all             DROP            info
 The FOLLOWING POLICY MUST BE LAST
 all             all             REJECT          info

Aber was bedeuten diese drei magischen Zeilen? In der Datei policy werden quasi die Grundeinstellungen gesetzt für alle Fälle die in der Datei rules nicht geregelt werden. Diese Einstellung wirr auf DROP gesetzt für den Fall, dass ein ungewollt laufendes Programm irgendetwas nach außen senden will oder Infomation über das Netzwerk sammeln will.
$FW net DROP info – aller Netzwerkverkehr von der Quelle $FW zum Ziel net wird verworfen (DROP). In dem Logfile wird ein bei loglevel info ein Eintrag gesetzt.
net all DROP info – aller Netzwerkverkehr von der Quelle net zum Ziel all wird verworfen (DROP). Logfile, wie vor.
all all REJECT info – Wenn keine von den beiden Regeln zuvor greifen sollte, kommt diese Regel zur Anwendung: Weise allen Netzwerkverkehr von und in alle Richtungen zurück.

Im Ergebnis haben wir nun jeglichen Netzwerkverkehr unterbunden, es sei denn wir definieren in den rules spezifische Regeln für erlaubten Verkehr.

Zu guter Letzt die Datei /etc/shorewall/rules mit einem Editor öffnen und den Inhalt den nachfolgenden Zeilen anpassen. Die standardmäßig vorhanden Ping/DROP Regel, kann gelöscht werden und wir starten mit folgender Mindestkonfiguration:

SSH incoming
SSH(ACCEPT) net $FW
DNS outgoing
DNS(ACCEPT) $FW net
FTP outgoing
FTP(ACCEPT) $FW net
HTTP outgoing
HTTP(ACCEPT) $FW net

Damit sind – recht minimalistisch – nur vier Verbindungen möglich:
1. Mit SSH von außen auf den Firewall
2. DNS Anfragen des Firewallrechners an die Außenwelt
3. FTP vom Firewallrechner ins Netz (für Downloads)
3. HTTP vom Firewallrechner ins Netz

Die ausgehenden DNS, FTP und HTTP Regeln sind alleine schon deswegen erforderlich, da sonst z. B. keine Sicherheitsupdates mehr über Netz installiert werden können.

In der Datei rules können nach Bedarf weitere Ports Schritt für Schritt aufgemacht werden.

Die Konfiguration testen wir schnell auf  Tipp- und/oder Syntaxfehler:

shorewall check

Wenn das soweit fehlerfrei ist bitte die Datei /etc/default/shorewall mit einem Editor öffenn und den Start von shorewall mit folgendem Eintrag erlauben

startup=1

Zum Testen ein wird der Dienst von Hand gestartet (Evtl. Fehler werden angezeigt….):

/etc/init.d/shorewall start

Die laufende SSH-Sitzung sollte i. d. R. durch den Start von shorewall nicht unterbrochen werden. Wenn der Start funktioniert öffnen wir ein weiteres Terminal (lokal) und melden uns dort per SSH auf dem Server an, damit wir sicher sein können, dass wir uns nicht ausgesperrt haben.

Ob der Server nun wirklich so schweigsam ist wie erwartet, können wir mit einem schlichten ping testen. Mit der obigen Konfiguration sollte der Server nicht mal den Hauch einer Antwort auf den Ping geben.

Ach übrigens, die Hersteller von Routern würden diese Konfiguration marketing-gerecht hochtrabend als „Stealth-Mode“ bezeichnen…….

Nun noch den folegenden Befehl eingeben damit Shoreall auch beim Start startet.

systemctl enable shorewall.service

‚fail2ban‘ installieren

fail2Ban durchsucht Logdateien und blockt IP-Adressen, die zu viele fehlgeschlagene Loginversuche haben. Es aktualisiert Firewallregeln (iptables), um diese IP-Adressen zu sperren. Hierdurch werden auch die Logfiles etwas übersichtlicher.

Im derzeitigen Stand der Installation des Linux Basis Servers haben wir als Dienst nur SSH aktiviert. Für diesen Dienst sind in der vom Paket Maintainer mitgelieferten Konfiguration schon Regeln definert, sodass eine weitergehende Konfiguration zum jetztigen Zeitpunkt nicht erforderlich ist. Ggf. ist nach der Installation weitere Dienste auch eine entsprechende Konfiguration erforderlich.

fail2ban ist mit folgenden Schritten schnell installiert:

Als root auf der Shell anmelden und fail2ban per apt installieren und starten

apt install fail2ban
/etc/init.d/fail2ban start

Nun wollen wir testen ob das Programm auch richtig funktioniert. Mit dem folgenden Befehl können wir alle einlog versuche sehen und den Test durchführen.

tail -f /var/log/fail2ban.log

Als nächstes öffnen wir eine neue Shell und versuchen uns mit falschem Passwort anzumelden. Es sollte eine Fehlermeldung kommen und auf der Servershell sollte angezeigt werden das es einen Anmeldeversuch gab. Machen wir das 5 mal, dann sollte nicht mehr ‚found‘ dort stehen sondern ‚Ban‘. Wenn dies der Fall ist haben wir alles richtig installiert.

Gut, nun sind natürlich erst einmal ausgesperrt. Der schnellste Weg dies zu ändern ist es sich eine neue IP-Adresse geben zu lassen. Dazu das DSL Kabel an Eurem Rputer einmal kurz heraus ziehen und wieder einstecken. Alternativ in den Router-Einstellungen die DSL Verbindung neu herstellen lassen.

SSH Server / Deamon konfigurieren

Für einen sicheren Betrieb wollen wir den OpenSSH  Sever etwas absichern. Ein Login soll zukünftig nur mit einem gültigen Zertifikat möglich sein und die direkte Anmeldung des privilegierten Benutzers ‚root‚ soll unterbunden werden.

ACHTUNG: Vorher muss auf dem Server ein Benutzer mit gültigen Zertifkat und Mitgliedschaft mit sudo Rechten eingerichtet sein!
Ist dies nicht der Fall, ist eine Anmeldung aus der Ferne nicht mehr möglich! Falls das noch nicht geschehen ist, bitte erst die Artikel ‚Administrativen Hauptbenutzer einrichten‘ und ‚Zertifikatsbasierten Login für einrichten‚.

Wir melden uns als root auf der Shell an und erstellen eine Sicherheitskopie von der  /etc/ssh/sshd_config .

cp /etc/ssh/sshd_config /etc/ssh/sshd_config_org

Nun editieren wir die Datei/etc/ssh/sshd_config. Hier müssen folgende Einträge eingefügt oder entsprechend geändert werden:

PermitRootLogin no
PasswordAuthentication no
ChallengeResponseAuthentication no
UsePAM yes
AuthorizedKeysFile %h/.ssh/authorized_keys
PubkeyAuthentication yes

Nun müssen wir noch den SSH Server neu starten.

/etc/init.d/ssh restart

Dabei sollte in der Regel die aktuelle aktive SSH-Sitzung von der aus Ihr den Server neu startet erhalten und aktiv bleiben!

Test

Bitte die aktuelle SSH-Sitzung für den Notfall offen halten und in einem zusätzlichen Terminal Fenster folgende Logins ausprobieren:

ssh root@<MEINSERVER>

Dieser Befehl sollte nun die Ausgabe ‚Permission denied (publickey)‚ produzieren und die Anmeldung mit Passwort ist für den Benutzer ‚root‚ nicht mehr möglich.

Gut soweit! Wir wollen nun aber auch wissen ob der zertifikatsbasierte Login mit unserem Hauptbenutzer (im Beispiel: ‚myadm‘) funktioniert. Also melden wir uns mit

ssh -i ~/.ssh/myadm myadm@<MEINSERVER>

Nun wird zunächst das Passwort für den privaten Schlüssel abgefragt und anschließend solltet Ihr automatisch angemeldet werden. Geht dies auch, müssen wir nur noch den Wechsel zum ‚root‘ prüfen. Dazu geben wir

sudo su

ein. Nun wird nach dem Passwort unseres Benutzers gefragt (also z. B. ‚myadm‘)  und anschließend solltet Ihr als root angemeldet sein.

WICHTIG: Sollte bei den Tests irgendetwas nicht funktionieren wie erwartet, geht bitte auf die immer noch offenen Notfall-Sitzung zurück, mach die SSH-Konfiguration rückgängig und startet den SSH Server neu. Anderenfalls besteht die Gefahr dass Ihr Euch von Eurem Server aussperrt!