ich wurde vor längerer Zeit gefragt, ob ich den Weg meiner Implementierung mit Apache hier niederschreiben könnte, was ich hiermit erledigen möchte.

Warum man das macht und wie das ganze mit NGINX funktioniert hat psilo sehr gut auf dieser Seite erklärt!

Deswegen möchte ich auch hier nur auf die Änderungen zu Apache eingehen und setzte also Voraus, dass man weiß was man erreichen will und auch über die genannte Seite von psilo geschaut hat!

Als kleine Änderung will ich hier gleich anmerken, dass ich keine extra Maschine als Reverse Proxy einsetzte, da ich bei mir soweit alles abgesichert habe und darin einige Erfahrung habe

Damit gehe ich also auch davon aus, dass ihr Apache auch für eure smartVISU einsetzt, wie ich es mache. Falls nicht müsst ihr natürlich apache nachinstallieren.

Unter Debian/Ubuntu/Raspbian funktioniert das mit:

sudo apt-get update
sudo apt-get install apache2

Unter Ubuntu 18.04 habe ich auch keine weiteren Module (wie libapache2-mod-XXX) für Apache benötigt. Ob dies bei allen Debian-basierenden Distributionen der Fall ist müsste man im Einzelfall prüfen. Man wird es auf jeden Fall merken, wenn sich die kommenden Befehle zum aktivieren der Module nicht durchführen lassen.

Nun müssen wir die folgenden Module aktivieren:

sudo a2enmod proxy_wstunnel
sudo a2enmod rewrite
sudo a2enmod setenvif

Bei Apache arbeite ich gerne nach dem modularen Prinzip, weswegen ich mir für die Einstellungen die ich brauche, einer eigene Konfigurationsdatei mit dem Namen /etc/apache2/smartvisu.conf angelegt habe, die ich hier entsprechend erläutern möchte.

<IfModule mod_rewrite.c>
   RewriteEngine on

   # Eine Umleitung vom Ordner zur index.php (es gab da mal einen Bug,
   # in der alten VISU, keine Ahnung ob das noch aktuell ist, schaden
   # tut es aber nicht, man kann es aber gerne auch weglassen)
   RewriteCond %{REQUEST_URI} ^/smartVISU$ [NC,OR]
   RewriteCond %{REQUEST_URI} ^/smartVISU/$ [NC]
   RewriteRule .* /smartVISU/index.php [R=302,L]

   # Mit dieser Definition wird der Reverse Proxy für Websocket aktiviert
   # Da wie oben schon erwähnt, die VISU und SH bei mir auf dem lokalen Host
   # läuft, verwende ich hier als Ziel auch localhost. Das kann man aber
   # natürlich Anpassen und soll auch nur als Beispiel dienen.
   <IfModule mod_proxy.c>

      ProxyPreserveHost On
      ProxyVia On

      # socket.io 1.0+ starts all connections with an HTTP polling request
      RewriteCond %{QUERY_STRING} transport=polling [NC]
      RewriteRule /(.*) http://localhost:2424/$1 [P]

      # When socket.io wants to initiate a WebSocket connection, it sends an
      # "upgrade: websocket" request that should be transferred to ws://
      RewriteCond %{HTTP:Upgrade} websocket [NC]
      RewriteRule /(.*) ws://localhost:2424/$1 [P]
   </IfModule>

   # Hier ist Platz für spezielle Ausnahmen (die wie unten mit SetEnvIf
   # gezeigt nicht abgebildet werden können), z.B. für eine Manifest-Datei die
   # ich mir in die VISU rein Programmiert habe. Hier wird beim Auffinden
   # des entsprechenden Query-Strings die Umgebungsvariable
   # no_auth_required auf 1 gesetzt, was dann weiter unten ausgewertet wird
   # und dann dazu führt, dass keine Anmeldung erforderlich ist
   RewriteCond %{QUERY_STRING} page=manifest
   RewriteRule ^/smartVISU/index.php - [E=no_auth_required:1]
   # !! Das ist natürlich nur ein Beispiel und wäre bei euch nicht erforderlich !!

</IfModule>

# Hier definiere ich wann man sich anmelden muss und wann nicht und
# das gilt dabei für den kompletten Webserver Stamm also ab der Wurzel.
# Das ist !Wichtig!, da so auch automatisch die Websocket-Verbindung
# per Basic Auth geschützt wird!
<Location />
   # Hier kann ich dann wieder Dinge freigeben, die ohne Anmeldung funktionieren sollen
   # (wie auch weiter oben im Beispiel, nur das es mit SetEnvIf etwas einfacher geht)
   # z.B. kann sich jeder meine Temperatur Statistik im Unterordner /mytemplogger ohne
   # Anmeldung ansehen, dazu setzte ich wieder die Umgebungsvariable no_auth_required auf 1
   SetEnvIf Request_URI ^/mytemplogger no_auth_required=1

   # Dann definiere ich die Basic Auth Parameter
   AuthName "Private"
   AuthType Basic
   AuthUserFile /etc/apache2/htpasswd
   Require valid-user

   # Hier gebe ich an, dass man sich über die lokalen Netze nicht anmelden muss,
   # dass muss also jeder für sich Anpassen. Wer kein IPv6 hat kann die /64 Adressen
   # natürlich auch weg lassen
   Require ip 192.168.XX.0/24 2a02:810c:XXX:XXX::/64 fd00:XXXX:XXXX:XXXX::/64 fe80::/64
   # Und hier wird die Ausnahme mit der Umgebungsvariable definiert, so kann man einfacher
   # Seiten oder Aufrufe als Ausnahme definieren
   Require env no_auth_required

</Location>

Dann müssen wir uns natürlich die zuvor verwendete /etc/apache2/htpasswd anlegen:

htpasswd -cB /etc/apache2/htpasswd BENUTZER
New password: MEINSUPERPASSWORD
Re-type new password: MEINSUPERPASSWORD
Adding password for user visu

# Und dann die Rechte anpassen:
chmod 660 /etc/apache2/htpasswd

Wobei BENUTZER der Benutzername ist den man anlegen möchte. Es können natürlich mehrere Benutzer angelegt werden. Man sollte aber hier wirklich ein sicheres Passwort verwenden, da dies nicht vor Brute-Force Angriffen geschützt ist. Wobei man ganz klar die Webseite nochmal in mehreren wegen etwas weiter Schützen kann. Aber dazu später mehr.

Nun kann man auf jeden fall schon seine Konfiguration für den virtuellen Host anpassen. Im Standardfall wäre dass die /etc/apache2/sites-enabled/000-default.conf oder eben die von euch genutzte Datei. Da ich bei mir mehrere virtuelle Hosts habe, die jewels ein eigenes Zertifikat (Stichwort SSL) haben (für internen Host – ohne SSL, für externen Host – mit SSL, für den vom Internet und Intern aus erreichbaren IPv6 Host – mit SSL), kann ich jetzt die smartvisu.conf überall einbinden und hab eine zentrale Stelle für die Anpassungen.

Die nötige Anpassung zum Einbinden der Konfiguration sieht wie folgt aus:

Innerhalb des <VirtualHost></VirtualHost> Blocks muss nur noch folgende Zeile eingefügt werden:

Include /etc/apache2/smartvisu.conf

Jetzt könnte man den Apache2 neustarten und testen.

service apache2 restart

Nützliche Tipps zur Absicherung

Zum Absichern gibt es mehrere Faktoren – vieles hier setzt zwar auf Verschleierung/Tarnung (was eine gute Methode ist, Angriffe gar nicht erst aufkommen zu lassen), aber natürlich nicht ausschließlich:

• ) Die Webseite auf jeden Fall mit SSL absichern!! Auch ich verwende für die externen Zugriffe den kostenfreien Service von Let’s Encrypt. Möglich wäre aber auch ein self-signed Zertifikat (Anleitungen gibt es dazu wie Sand am Meer) aber eben nicht so schön und nicht ganz so sicher, oder wer von euch prüft schon den Fingerabdruck den Zertifikats?!
• ) die Brute-Force Angriffe auf die Basic-Anmeldung kann man ganz einfach mit fail2ban Abfangen/-mildern (Abmildern deswegen, da es möglich wäre auch ein Angriff von mehreren IPs zu koordinieren, was fail2ban nicht abfangen könnte), was ich trotzdem nur jeden empfehlen kann, weswegen ich es auch kurz erklären möchte:
  Zuerst installiert man das Paket mit sudo apt-get install fail2ban
  dann erstellen wir uns eine local.conf, in dem wir das definieren was nicht in der Standardkonfiguration erfasst ist. Man könnte zwar auch die Standardkonfiguration unter /etc/fail2ban/jail.conf bearbeiten, aber übersichtlicher wird es mit meiner vorgeschlagenen Variante. Dazu öffnen wir mit dem Editor unserer Wahl die Datei /etc/fail2ban/jail.d/local.conf und aktivieren die Jail für die Definition von apache-auth wie folgt:

  [apache-auth]
  enabled = true
  

  und danach können wir fail2ban neu laden mit sudo fail2ban-client reload und den Status prüfen mit sudo fail2ban-client status.
  
  Wichtig: Hat man den Protokollpfad seines Apache Vhosts modifiziert, muss man den Pfad für die Jail nochmals prüfen und ggf. in unserer local.conf überschreiben. Prüfen kann man das nochmal in der Datei /etc/fail2ban/jail.conf bzw. /etc/fail2ban/paths-arch.conf (dort steht bei meinem Ubuntu die Variable apache_error_log).

• ) Keine Standard-Ports für den Zugriff auf den Webserver von Extern verwenden. Das hält die ganzen Scanner davon ab die Seite zufällig zu finden. Natürlich wird ein gezielter Angriff (mit Port-Scan) die Seite trotzdem aufdecken, egal welcher Port verwendet wird. Dies wiederum könnte man mit Port Knocking (fwknop/knockd) ausschalten, finde ich aber überflüssig, da es das ganze wieder unnötig verkompliziert.
• ) zusätzlichen Schutz würde auch noch eine zwei-Faktor Anmeldung bringen, z.B. über den Google Authenticator, der den offener Standard OATH (Initiative for Open Authentication) umsetzt und leicht verwendet werden kann. Dazu verweise ich aber z.B. auf diese Anleitung.
• ) Client Zertifikate wären natürlich auch möglich, halte ich aber auch für Übertrieben/zu kompliziert und diese können genau so gut über einen Trojaner geklaut werden – dann lieber 2-Faktor
• ) den Webserver vor Zugriffen aus dem Ausland schützen wäre natürlich auch unter Apache möglich, alternativ mit iptables. Aber mal ehrlich, wenn ich im Urlaub bin will ich auch darauf zugreifen und nicht extra dran denken müssen es frei zu schalten.
• ) die Seite nicht öffentlich im Web verlinken, da b) sonnst auch keinen Sinn macht. Nicht dass wir was zu verbergen haben – aber wie heist es so schön: Schlafende Hunde soll man nicht wecken
• ) dafür sorgen dass das System aktuell gehalten wird – Stichpunkt UnattendedUpgrades, was es sowohl unter Debian und Ubuntu gibt. Auch sollte nur eine Distribution eingesetzt werden, welche auch noch vom Anbieter unterstützt wird.
• ) Keine öffentliche (also ohne Anmeldung zugängliche) Index Seite auf dem internen Webserver anlegen, wo mögliche öffentliche Inhalte „sichtbar“ verlinkt sind. Auch sollten die öffentlichen Inhalte (wenn überhaupt unbedingt benötigt – man kann diese ja auch nur Intern erreichbar machen) nicht über Standard-Ordner laufen, wie z.B. wp (WordPress), Joomla, phpmyadmin, Webmail usw…
  Die Gefahr dabei besteht, dass in den gehosteten Inhalten, eine Sicherheitslücke dafür sorgt, dass jemand sich Zugriffsrechte auf den Webserver erschleichen kann, was dann wieder durch Intensivierung des Angriffs über eine Rechteausweitung zu ROOT-Rechte führen kann!!

TODO: Konfiguration LetsEncrypt

Um einen sicheren Zugriff auf SmartHomeNG und die smartVISU von außen (ohne VPN) zu ermöglichen, empfiehlt es sich, die Software NGINX als ReverseProxy mit Basic Authentication oder Clientzertifikaten zu nutzen.

Die Idee hinter einem ReverseProxy ist, dass man einen einzigen sicheren Eintrittspunkt in das Heimnetzwerk hat, ohne ein VPN nutzen zu müssen. Der ReverseProxy hängt direkt hinter dem Router und wird von dort via Portforwarding angesprochen. Üblicherweise wird der HTTPS Port 443 vom Router auf den ReverseProxy umgeleitet. Für die Installation ist temporär auch der HTTP Port 80 notwendig, damit ein SSL Serverzertfikat, bspw. von Let’s Encrypt, für die hinterlegte DynDNS URL installiert werden kann.

Im ReverseProxy kann ein Zugriffsschutz implementiert werden, der via Basic Authentication oder Clientzertifikate realisiert wird. Beides wird in diesem Artikel erklärt. Es wird zudem auf weitere Sicherheitsmaßnahmen, wie das Blockieren von Requests aus nicht vertrauenswürdigen Ländern, eingegangen.

Je nach angesprungenem Kontextpfad (also bspw. /smartVISU oder /alexa) wird dann in Richtung des Hauptservers und des jeweiligen Ports weitergeleitet. Das folgende Bild illustriert das schematisch:

Die folgende Dokumentation beschreibt eine Installation von NGINX als ReverseProxy auf eigenständiger Hardware unter Raspbian Stretch Lite. Dieser ReverseProxy ist bspw. auch für das Alexa Plugin oder die Nutzung von SmartHomeNG mit „EgiGeoZone“ / „Geofency“ notwendig, damit ein sicherer Zugriff aus dem Internet auf die SmartHomeNG Instanz erfolgen kann.

Annahmen

Diese Anleitung beruht auf folgenden Annahmen

• NGINX wird auf einem frisch aufgesetzten RaspberryPi mit „Raspbian Stretch Lite“ installiert.
• Der RaspberryPi dient ausschliesslich der Funktion als ReverseProxy
• Der Standarduser heißt weiterhin „pi“
• Eine DynDNS (o.ä.) Domain ist vorhanden und leitet auf die aktuelle Internet IP
• SmartHomeNG und smartVISU sind auf einem separaten Rechner im gleichen LAN installiert.

Basiskonfiguration

• Deutsches Keyboard festlegen: /etc/default/keyboard editieren und in der Zeile XKBLAYOUT="..." ein „de“ eintragen. Danach sudo reboot now eingeben, um neu zu starten.
• Aus Sicherheitsgründen das Standard-Passwort für „pi“ ändern: Als User „pi“ mit Standard-Passwort einloggen und mit passwd ein neues Passwort setzen.

NGINX installieren:

sudo apt-get update
sudo apt-get install nginx-full

GeoIP installieren:

Über GeoIP kann mittels der anfragenden IP herausgefunden werden, aus welchem Land eine Anfrage kommt. Darüber lassen sich bspw. Requests aus Risikoländern blockieren.

sudo apt-get install geoip-database libgeoip1
cd /usr/share/GeoIP/
sudo wget http://geolite.maxmind.com/download/geoip/database/GeoLiteCountry/GeoIP.dat.gz
sudo gunzip GeoIP.dat.gz

Let’s Encrypt Server-Zertifikate

(nach https://goneuland.de/debian-9-stretch-lets-encrypt-zertifikate-mit-certbot-erstellen/)

Über Let’s Encrypt lassen sich kostenlos SSL Zertifikate, bspw. für dyndns-Domains, ausstellen.

Certbot installieren:

sudo apt-get install certbot

Nun die Datei /etc/nginx/snippets/letsencrypt.conf bearbeiten:

sudo nano /etc/nginx/snippets/letsencrypt.conf

Dort folgenden Inhalt einfügen, damit certbot die Identität überprüfen kann.:

location ^~ /.well-known/acme-challenge/ {
 default_type "text/plain";
 root /var/www/letsencrypt;
}

sudo mkdir -p /var/www/letsencrypt/.well-known/acme-challenge

sudo nano /etc/nginx/sites-available/default

Dort unterhalb von listen [::]:80 default_server; die Zeile include /etc/nginx/snippets/letsencrypt.conf; einhängen:

server {
        listen 80 default_server;
        listen [::]:80 default_server;
        include /etc/nginx/snippets/letsencrypt.conf;
[...]

sudo service nginx restart

Temporär Port 80 im Router auf den RaspberryPi weiterleiten !

sudo certbot certonly --rsa-key-size 4096 --webroot -w /var/www/letsencrypt -d <mydomain>.<myds>.<me> 

Nachdem man seine E-Mail eingegeben hat, sollte die Generierung erfolgreich durch laufen und mit

Generating key (4096 bits): /etc/letsencrypt/keys/0000_key-certbot.pem
Creating CSR: /etc/letsencrypt/csr/0000_csr-certbot.pem

enden.

Port 80 im Browser wieder schließen, dafür Port 443 (https) entsprechend auf den ReverseProxy-RaspberryPi weiterleiten!

NGINX Konfiguration

/etc/nginx/nginx.conf bearbeiten und direkt im „http“ Block die GeoIP Einstellungen hinzufügen. Unter der Konfiguration der „virtual hosts“ noch einen Block als Schutz gegen Denial of Service Angriffe ergänzen:

http {
    ##
    # GeoIP Settings
    # Nur Länder aus erlaubten IP Bereichen dürfen den ReverseProxy
    # passieren!
    # https://www.howtoforge.de/anleitung/nginx-besucher-mit-dem-geoip-modul-nach-landern-blocken-debianubuntu/
    ##
    geoip_country /usr/share/GeoIP/GeoIP.dat;
    map $geoip_country_code $allowed_country {
        default yes;
        BY no;
        BR no;
        KP no;
        KR no;
        RS no;
        RO no;
        RU no;
        CN no;
        CD no;
        NE no;
        GH no;
        IQ no;
        IR no;
        SY no;
        UA no;
    }
[...]
    ##
    # Virtual Host Configs
    ##

    include /etc/nginx/conf.d/*.conf;
    include /etc/nginx/sites-enabled/*;

    ##
    # Harden nginx against DDOS
    ##

    client_header_timeout 10;
    client_body_timeout   10;
}

NGINX mit sudo service nginx restart neu starten.

/etc/nginx/conf.d/<mydomain>.<myds>.<me>.conf erstellen

server {
    server_tokens off;
    
    ## Blocken, wenn Zugriff aus einem nicht erlaubten Land erfolgt ##
    if ($allowed_country = no) {
        return 403;
    }    
    
    # https://www.cyberciti.biz/tips/linux-unix-bsd-nginx-webserver-security.html
    ## Block download agents ##
    if ($http_user_agent ~* LWP::Simple|BBBike|wget) {
        return 403;
    }

    ## Block some robots ##
    if ($http_user_agent ~* msnbot|scrapbot) {
        return 403;
    }

    ## Deny certain Referers ##
    if ( $http_referer ~* (babes|forsale|girl|jewelry|love|nudit|organic|poker|porn|sex|teen) )
    {
        return 403;
    }

    listen 443 ssl default_server;
    server_name <mydomain>.<myds>.<me>;

    ##
    # SSL
    ##
    
    ## Activate SSL, setze SERVER Zertifikat Informationen ## 
    # Generiert via Let's Encrypt! 
    ssl on;
    ssl_certificate /etc/letsencrypt/live/<mydomain>.<myds>.<me>/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/<mydomain>.<myds>.<me>/privkey.pem;
    ssl_session_cache builtin:1000 shared:SSL:10m;
    ssl_prefer_server_ciphers on;
    # unsichere SSL Ciphers deaktivieren!
    ssl_ciphers    HIGH:!aNULL:!eNULL:!LOW:!3DES:!MD5:!RC4;
    
    ##
    # HSTS
    ##

    add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;

    ##
    # global
    ##

    root /var/www/<mydomain>.<myds>.<me>;
    index index.php index.htm index.html;
    
    # Weiterleitung zu SmartHomeNG (Websocket Schnittstelle) mit Basic Auth
    # Nur Verbindungen gegen "/" durchlassen! Also weder auf Dateien noch Verzeichnisse (= nur Websocket Connects)
    location = / {
        auth_basic "Restricted Area: smartVISU";
        auth_basic_user_file /etc/nginx/.smartvisu;      
        proxy_pass http://<SmartHomeNG LAN IP>:<Websocket Port>;        
    }

    # Zugriff auf die smartVISU mit Basic Auth
    location /smartVISU {      
        auth_basic "Restricted Area: smartVISU";
        auth_basic_user_file /etc/nginx/.smartvisu;
        proxy_pass http://<smartVISU Server LAN IP>/smartVISU;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
    
    # Alexa Plugin Weiterleitung
    location /alexa {
        auth_basic "Restricted Area: Alexa";
        auth_basic_user_file /etc/nginx/.alexa;
        proxy_pass http://<SmartHomeNG LAN IP>:<Alexa Plugin Port>/;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }

    # Network Plugin Weiterleitung
    location /shng {
        auth_basic "Restricted Area: SmartHomeNG";
        auth_basic_user_file /etc/nginx/.shng;
        proxy_pass http://<SmartHomeNG LAN IP>:<Network Plugin Port>/;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

NGINX reloaden:

/etc/init.d/nginx reload

Passwort-Files für unterschiedliche User für smartVISU, Alexa, Network Plugin erstellen

sudo apt-get install apache2-utils

sudo htpasswd -c /etc/nginx/.smartvisu <username>
sudo htpasswd -c /etc/nginx/.alexa <username>
sudo htpasswd -c /etc/nginx/.shng <username>

Dann ein Passwort vergeben.

Der Zugriff auf https://../smartVISU sollte nun klappen.

Nacharbeiten: Port 80 in NGINX deaktivieren

Da NGINX im LAN aktuell noch auf Port 80 konfiguriert ist, sollte man in der /etc/nginx/sites-available/default noch ein return 403 ergänzen und NGINX neu starten:

server {
        listen 80 default_server;
        listen [::]:80 default_server;

        return 403;

        include /etc/nginx/snippets/letsencrypt.conf;

/etc/init.d/nginx reload

Client Zertifikate erstellen (optional)

openssl.cnf editieren

sudo nano /etc/ssl/openssl.cnf

Folgende Zeilen anpassen:

dir = /etc/ssl/ca                       # Directory where everything is kept
[...]
new_certs_dir = $dir/certs               # default place for new certs.
[...]
certificate = $dir/ca.crt               # The CA certificate
[...]
crl = $dir/crl.pem                      # The current CRL
private_key = $dir/private/ca.key       # The private key
[...]
default_md = sha1 # use public key default MD

Drei neue Verzeichnisse und drei Dateien anlegen:

sudo mkdir -p /etc/ssl/ca/certs/users
sudo mkdir -p /etc/ssl/ca/crl
sudo mkdir -p /etc/ssl/ca/private

sudo touch /etc/ssl/ca/index.txt
sudo touch /etc/ssl/ca/index.txt.attr

In der Datei crlnumber den Wert „01“ eintragen und speichern.

sudo nano /etc/ssl/ca/crlnumber

Zertifikat für Certification Authority (CA) erstellen, Passwort für die CA wählen und eigene Daten eingeben:

sudo openssl genrsa -des3 -out /etc/ssl/ca/private/ca.key 4096
sudo openssl req -new -x509 -days 1095 -key /etc/ssl/ca/private/ca.key -out /etc/ssl/ca/certs/ca.crt
sudo openssl ca -name CA_default -gencrl -keyfile /etc/ssl/ca/private/ca.key -cert /etc/ssl/ca/certs/ca.crt -out /etc/ssl/ca/private/ca.crl -crldays 1095

Client Zertifikat für einen User erstellen und ein Passwort für das Client Zertifikat vergeben:

sudo openssl genrsa -des3 -out /etc/ssl/ca/certs/users/<USERNAME>.key 1024
sudo openssl req -new -key /etc/ssl/ca/certs/users/<USERNAME>.key -out /etc/ssl/ca/certs/users/<USERNAME>.csr

Bei folgendem Schritt das Passwort für die CA eingeben:

sudo openssl x509 -req -days 1095 -in /etc/ssl/ca/certs/users/<USERNAME>.csr -CA /etc/ssl/ca/certs/ca.crt -CAkey /etc/ssl/ca/private/ca.key -CAserial /etc/ssl/ca/serial -CAcreateserial -out /etc/ssl/ca/certs/users/<USERNAME>.crt

Bei folgendem Schritt mit dem Passwort für das Client Zertifikat bestätigen und ein Export Passwort wählen:

sudo openssl pkcs12 -export -clcerts -in /etc/ssl/ca/certs/users/<USERNAME>.crt -inkey /etc/ssl/ca/certs/users/<USERNAME>.key -out /etc/ssl/ca/certs/users/<USERNAME>.p12 

<USERNAME>.p12 File herunterladen:

sudo cp /etc/ssl/ca/certs/users/<USERNAME>.p12 /home/pi
cd /home/pi/
sudo chown pi <USERNAME>.p12

Bspw. nun via SFTP ziehen und aufs Datei aufs Android Handy übertragen und ausführen oder im Browser unter Zertifikate“ importieren. Dabei muss es mit Export Passwort bestätigt werden.

Client Zertifikate in NGINX nutzen (optional)

Anleitung nach https://arcweb.co/securing-websites-nginx-and-client-side-certificate-authentication-linux/

/etc/nginx/conf.d/<mydomain>.<myds>.<me>.conf bearbeiten und die Zeilen im SSL Block ergänzen („ab Client Zertifikat spezifisch“)

    ##
    # SSL
    ##

    ## Activate SSL, setze SERVER Zertifikat Informationen ##
    # Generiert via Let's Encrypt!    
    ssl on;
    ssl_certificate /etc/letsencrypt/live/<mydomain>.<myds>.<me>/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/<mydomain>.<myds>.<me>/privkey.pem;
    ssl_session_cache builtin:1000 shared:SSL:10m;
    ssl_prefer_server_ciphers on;
    # unsichere SSL Ciphers deaktivieren!
    ssl_ciphers    HIGH:!aNULL:!eNULL:!LOW:!3DES:!MD5:!RC4;

    # Client Zertifikat spezifisch
    ssl_client_certificate /etc/ssl/ca/certs/ca.crt;
    ssl_crl /etc/ssl/ca/private/ca.crl;
    ssl_verify_client optional;
    ssl_session_timeout 5m;

Die smartVISU relevanten Teile könnten jetzt folgendermaßen über Clientzertifikate geschützt werden:

    # Weiterleitung zu SmartHomeNG (Websocket Schnittstelle) mit Clientzertifikat
    location = / {
        # Clientzertifikat gültig?
        if ($ssl_client_verify != SUCCESS) {
                return 403;
        }
        proxy_pass http://<SmartHomeNG LAN IP>:<Websocket Port>;      
    }

    # Zugriff auf die smartVISU mit Clientzertifikat
    location /smartVISU {  
        # Clientzertifikat gültig?    
        if ($ssl_client_verify != SUCCESS) {
                return 403;
        }
        proxy_pass http://<smartVISU Server LAN IP>/smartVISU;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }

Wer es doppelt sicher haben möchte, kann die Basic Auth in den jew. Blöcken auch beibehalten.

Testbar ist das Ganze, wenn es im Browser ohne Zertifikat einen 403er Fehler gibt und mit Zertifikat die smartVISU aufbaut.

Erweiterung: Stärkere Diffie-Hellman-Parameter

Damit die Sicherheit „perfekt“ wird, sollten stärkere Diffie-Hellman-Schlüssel verwendet werden. Dazu muss ein neues .pem File generiert werden. Es empfiehlt sich, die Erzeugung dieses Files nicht direkt auf den Raspi, sondern auf einem PC mit stärkerer CPU durchzuführen. Ein Test auf einem Raspi3 dauerte 24 Stunden (!). Ein Intel 4790k brauchte hingegen nur 30 Minuten.

Folgendes ist zu tun:

cd /etc/ssl/certs
sudo openssl dhparam -out dhparam.pem 4096

Alternativ kann die Datei auch einfach in /etc/ssl/certs kopiert werden.

Danach ist in der SSL Konfiguration von NGINX folgende Zeile zu ergänzen und NGINX neu zu starten:

# Konfiguration editieren
sudo nano /etc/nginx/conf.d/\<mydomain\>.\<myds\>.\<me\>.conf 

## Dort folgende Zeile im Block SSL einfügen:

##
# SSL
##
[...]
ssl_dhparam /etc/ssl/certs/dhparam.pem;
[...]

## NGINX neu starten
sudo service nginx restart

Die Sicherheit der eigenen https-Domain kann nun unter https://www.ssllabs.com/ssltest/ getestet werden. Mit den oben genannten Maßnahmen sollte ein A+ erreicht werden.

Der versiertere Nutzer kann sich unter https://mozilla.github.io/server-side-tls/ssl-config-generator/ auch gleich eine eigene Konfiguration generieren lassen.

Wartung: Zertifikat nach 3 Monaten erneuern

Nach 3 Monaten muss das Let’s Encrypt Serverzertifikat erneuert werden. Damit das Erneuerungs-Skript funktioniert, muss Port 80 im NGINX freigegeben, bzw. über einen separaten server Block auf HTTPS umgeleitet werden:

server {
    listen 80 default_server;
    listen [::]:80 default_server;
    server_name _;
    return 301 https://$host$request_uri;
}

Die Erneuerung geht dann wie folgendermaßen:
sudo certbot certonly --rsa-key-size 4096 --webroot -w /var/www/letsencrypt -d <mydomain>.<myds>.<me>

Im nun folgenden Dialog Option 2 (2: Renew & replace the cert (limit ~5 per 7 days)) auswählen. Danach NGINX neu starten:
sudo service nginx restart

Der Test über https://www.ssllabs.com/ssltest/ oder der Aufruf im Browser gibt nun Aufschluß über die Laufzeit des verlängerten Zertifikats.

Tipp: Endet die Erneuerung mit einem Timeout, kann dies ggf. an einer fälschlicherweise an den DNS Server propagierten IPV6 Addresse liegen. In diesem Fall testweise bei den DynDNS Einstellungen diese deaktivieren.

(Die in diesem Artikel verwendeten Screenshots und Grafiken wurden selber erstellt. Verwendete Symbole und Icons stammen von https://openclipart.org. Das Titelbild ist unter der Creative Commons Zero (CC0) Lizenz veröffentlicht und wurde von www.pexels.com bezogen.)