One place for hosting & domains

      So installieren Sie Drupal mit Docker Compose


      Der Autor hat die United Nations Foundation dazu ausgewählt, im Rahmen des Programms Write for DOnations eine Spende zu erhalten.

      Die ursprüngliche WordPress-Version dieses Tutorials wurde von Kathleen Juell verfasst.

      Einführung

      Drupal ist ein Content-Management-System (CMS), das in PHP geschrieben und unter der Open-Source-Lizenz GNU General Public License vergeben wird. Menschen und Organisationen in der ganzen Welt verwenden Drupal, um öffentliche Websites, persönliche Blogs, Unternehmen und mehr zu betreiben. Was Drupal von anderen CMS-Frameworks abhebt, ist seine wachsende Community und eine Reihe von Funktionen, die sichere Prozesse, zuverlässige Leistung, Modularität und Flexibilität zur Anpassung umfassen.

      Drupal erfordert die Installation des LAMP-Stacks (Linux, Apache, MySQL und PHP) oder des LEMP-Stacks (Linux, Nginx, MySQL und PHP), aber das Installieren einzelner Komponenten ist eine zeitaufwendige Aufgabe. Wir können Tools wie Docker und Docker Compose verwenden, um den Prozess der Installation von Drupal zu vereinfachen. Dieses Tutorial verwendet Docker-Images zur Installation einzelner Komponenten in den Docker-Containern. Mit der Verwendung von Docker Compose können wir mehrere Container für die Datenbank, die Anwendung und für die Vernetzung/Kommunikation zwischen ihnen definieren und verwalten.

      In diesem Tutorial installieren wir Drupal mit Docker Compose, damit wir die Containerisierung nutzen und unsere Drupal-Website auf Servern bereitstellen können. Wir führen Container für eine MySQL-Datenbank, einen Nginx-Webserver und Drupal aus. Außerdem sichern wir unsere Installation, indem wir TLS/SSL Zertifikate mit Let’s Encrypt für die Domäne erlangen, die wir mit unserer Website verknüpfen möchten. Schließlich richten wir einen cron-Job ein, um unsere Zertifikate zu erneuern, damit unsere Domäne sicher bleibt.

      Voraussetzungen

      Um diesem Tutorial zu folgen, benötigen Sie:

      • Einen Server, auf dem Ubuntu 18.04 ausgeführt wird, zusammen mit einem non-root user mit sudo-Privilegien und einer aktiven Firewall. Eine Anleitung für das Setup finden Sie im Leitfaden für die Ersteinrichtung des Servers.
      • Docker, gemäß Schritt 1 und 2 unter So installieren und verwenden Sie Docker unter Ubuntu 18.04 auf Ihrem Server installiert. Dieses Tutorial wurde unter der Version 19.03.8 getestet.
      • Docker Compose, gemäß Schritt 1 unter So installieren Sie Compose unter Ubuntu 18.04 auf Ihrem Server installiert. Dieses Tutorial wurde unter der Version 1.21.2 getestet.
      • Einen registrierten Domänennamen. Dieses Tutorial verwendet in allen Bereichen your_domain. Einen Domänennamen können Sie kostenlos bei Freenom erhalten oder Sie nutzen eine Domänenregistrierungsstelle Ihrer Wahl.
      • Die beiden folgenden DNS-Einträge für Ihren Server eingerichtet. Falls Sie ein DigitalOcean-Konto nutzen, können Sie in der Einführung in DigitalOcean-DNS im Einzelnen nachlesen, wie Sie diese hinzufügen:
        • Einen A-Eintrag mit your_domain, der auf die öffentliche IP-Adresse Ihres Servers verweist.
        • Einen A-Eintrag mit www.your_domain, der auf die öffentliche IP-Adresse Ihres Servers verweist.

      Schritt 1 — Definieren der Webserver-Konfiguration

      Bevor wir Container ausführen, müssen wir die Konfiguration für unseren Nginx-Webserver definieren. Unsere Konfigurationsdatei enthält einige Drupal-spezifische Location-Blocks, zusammen mit einem Location-Block zur Weiterleitung von Verifizierungsanforderungen von Let’s Encrypt an den Certbot-Client für automatisierte Zertifikatserneuerungen.

      Zuerst erstellen wir ein Projektverzeichnis für unser Drupal-Setup namens drupal:

      Rufen Sie das neu erstellte Verzeichnis auf:

      Nun können wir ein Verzeichnis für unsere Konfigurationsdatei erstellen:

      Öffnen Sie die Datei mit nano oder Ihrem bevorzugten Texteditor:

      • nano nginx-conf/nginx.conf

      In dieser Datei fügen wir einen Serverblock mit Anweisungen für unseren Servernamen und die Dokumenten-root hinzu sowie Location-Blocks, um die Anforderung des Certbot-Clients nach Zertifikaten, PHP-Verarbeitung und statischen Asset-Anforderungen zu leiten.

      Fügen Sie den folgenden Code in die Datei ein. Achten Sie darauf, your_domain durch Ihren eigenen Domänennamen zu ersetzen:

      ~/drupal/nginx-conf/nginx.conf

      server {
          listen 80;
          listen [::]:80;
      
          server_name your_domain www.your_domain;
      
          index index.php index.html index.htm;
      
          root /var/www/html;
      
          location ~ /.well-known/acme-challenge {
              allow all;
              root /var/www/html;
          }
      
          location / {
              try_files $uri $uri/ /index.php$is_args$args;
          }
      
          rewrite ^/core/authorize.php/core/authorize.php(.*)$ /core/authorize.php$1;
      
          location ~ .php$ {
              try_files $uri =404;
              fastcgi_split_path_info ^(.+.php)(/.+)$;
              fastcgi_pass drupal:9000;
              fastcgi_index index.php;
              include fastcgi_params;
              fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
              fastcgi_param PATH_INFO $fastcgi_path_info;
          }
      
          location ~ /.ht {
              deny all;
          }
      
          location = /favicon.ico {
              log_not_found off; access_log off;
          }
          location = /robots.txt {
              log_not_found off; access_log off; allow all;
          }
          location ~* .(css|gif|ico|jpeg|jpg|js|png)$ {
              expires max;
              log_not_found off;
          }
      }
      

      Unser Serverblock enthält folgende Informationen:

      Anweisungen:

      • listen: Diese weist Nginx an, an Port 80 zu lauschen, sodass wir das Webroot-Plugin von Certbot für unsere Zertifikatsanforderungen nutzen können. Beachten Sie, dass wir noch nicht Port 443 einschließen – wir aktualisieren unsere Konfiguration, um SSL einzuschließen, sobald wir erfolgreich unsere Zertifikate erlangt haben.

      • server_name: Damit definieren Sie den Servernamen und den Serverblock, der für Anfragen an den Server verwendet werden sollte. Achten Sie darauf, your_domain in dieser Zeile durch Ihren eigenen Domänennamen zu ersetzen.

      • index: Die Anweisung index definiert die Dateien, die als Indizes bei der Verarbeitung von Anfragen an unseren Server dienen. Wir haben hier die Standardreihenfolge der Priorität geändert und index.php vor index.html geschoben, damit Nginx Dateien namens index.php wenn möglich priorisiert.

      • root: Unsere root-Anweisung benennt das root-Verzeichnis für Anfragen an unseren Server. Dieses Verzeichnis, /var/www/html, wird als Bereitstellungspunkt in der Erstellungszeit durch Anweisungen in unserer Drupal Dockerfile erstellt. Diese Dockerfile-Anweisungen stellen auch sicher, dass die Dateien aus der Drupal-Version auf diesem Volume bereitgestellt werden.

      • rewrite: Wenn die angegebene reguläre Expression (^/core/authorize.php/core/authorize.php(.*)$) mit einer URI-Anfrage übereinstimmt, wird die URI wie in der Ersatzzeichenfolge (/core/authorize.php$1) angegeben geändert.

      Location-Blocks:

      • location ~ /.well-known/acme-challenge: Dieser Location-Block verwaltet Anfragen an das Verzeichnis .well-known, in dem Certbot eine temporäre Datei ablegt, um zu validieren, dass das DNS für unsere Domäne auf unserem Server aufgelöst wird. Mit dieser Konfiguration können wir das Webroot-Plugin von Certbot verwenden, um Zertifikate für unsere Domäne zu erlangen.

      • location /: In diesem Location-Block verwenden wir eine try_files-Anweisung, um nach Dateien zu suchen, die individuellen URI-Anfragen entsprechen. Anstatt jedoch einen 404 Not Found-Status auszugeben, übergeben wir die Steuerung an die Datei index.php von Drupal mit den Anforderungsargumenten.

      • location ~ .php$: Dieser Location-Block verwaltet die PHP-Verarbeitung und überträgt diese Anfragen an unseren drupal-Container. Da unser Drupal-Docker-Image auf dem php:fpm-Image basiert, schließen wir auch Konfigurationsoptionen ein, die in diesem Block für das FastCGI-Protokoll spezifisch sind. Nginx erfordert einen unabhängigen PHP-Prozessor für PHP-Anfragen: In unserem Fall werden diese Anfragen vom php-fpm-Prozessor verwaltet, der im php:fpm-Image enthalten ist. Außerdem enthält dieser Location-Block FastCGI-spezifische Anweisungen, Variablen und Optionen, die Anfragen an die in unserem Drupal-Container ausgeführte Drupal-Anwendung überträgt, den bevorzugten Index für die analysierte Anfrage-URI festlegt und URI-Anfragen analysiert.

      • location ~ /.ht: Dieser Block verwaltet .htaccess-Dateien, da Nginx diese nicht bedient. Die Anweisung deny_all stellt sicher, dass .htaccess-Dateien nie für Benutzer bereitgestellt werden.

      • location = /favicon.ico, location = /robots.txt: Diese Blocks stellen sicher, dass Anfragen an /favicon.ico und /robots.txt nicht protokolliert werden.

      • location ~* . (css|gif|ico|jpeg|jpg|js|png)$: Dieser Block schaltet die Protokollierung für statische Asset-Anfragen ab und stellt sicher, dass diese Assets in hohem Maße zwischenspeicherbar sind, da ihre Bereitstellung in der Regel aufwendig ist.

      Weitere Informationen zu FastCGI-Proxying finden Sie in Verstehen und Implementieren von FastCGI-Proxying in Nginx. Informationen zu Server- und Location-Blocks finden Sie in Verstehen von Nginx-Server- und Location-Block-Auswahlalgorithmen.

      Wenn die Bearbeitung abgeschlossen wurde, speichern und schließen Sie die Datei.

      Nach Einrichtung der Nginx-Konfiguration können Sie Umgebungsvariablen erstellen, die zur Laufzeit an Ihre Anwendungs- und Datenbankcontainer übergeben werden.

      Schritt 2 — Definieren der Umgebungsvariablen

      Unsere Drupal-Anwendung benötigt eine Datenbank (MySQL, PostgresSQL, etc.) zum Speichern von Informationen im Zusammenhang mit der Website. Der Drupal-Container benötigt Zugriff auf bestimmte Umgebungsvariablen zur Laufzeit, um Zugriff auf den Datenbank-Container (MySQL) zu ermöglichen. Diese Variablen enthalten sensible Informationen wie die Zugangsdaten der Datenbank, sodass wir sie nicht direkt in der Docker-Compose-Datei offenlegen können – der Hauptdatei, die Informationen darüber enthält, wie unsere Container ausgeführt werden.

      Es wird immer empfohlen, die sensiblen Werte in der .env-Datei festzulegen und ihre Zirkulation zu beschränken. Dadurch werden diese Werte nicht in unsere Projekt-Repositorys kopiert und öffentlich verfügbar gemacht.

      Erstellen und öffnen Sie im Haupt-Projektverzeichnis ~/drupal eine Datei namens .env:

      Fügen Sie die folgenden Variablen in die .env-Datei ein und ersetzen Sie dabei die hervorgehobenen Abschnitte mit den Zugangsdaten, die Sie verwenden möchten:

      ~/drupal/.env

      MYSQL_ROOT_PASSWORD=root_password
      MYSQL_DATABASE=drupal
      MYSQL_USER=drupal_database_user
      MYSQL_PASSWORD=drupal_database_password
      

      Wir haben nun das Passwort für das MySQL-root-Administratorkonto sowie unseren bevorzugten Benutzernamen und das Passwort für unsere Anwendungsdatenbank hinzugefügt.

      Unsere .env-Datei enthält sensible Informationen. Es wird daher immer empfohlen, sie in die .gitignore– und .dockerignore-Dateien des Projekts einzufügen, damit sie nicht in unseren Git-Repositorys und Docker-Images hinzugefügt werden.

      Wenn Sie mit Git zur Versionskontrolle arbeiten möchten, initialisieren Sie Ihr aktuelles Arbeitsverzeichnis als ein Repository mit git init:

      Öffnen Sie die .gitignore-Datei:

      Fügen Sie Folgendes hinzu:

      ~/drupal/.gitignore

      .env
      

      Speichern und schließen Sie die Datei.

      Öffnen Sie in ähnlicher Weise die .dockerignore-Datei:

      Fügen Sie Folgendes hinzu:

      ~/drupal/.dockerignore

      .env
      .git
      

      Speichern und schließen Sie die Datei.

      Wir haben nun die Maßnahmen zur Sicherung unserer Zugangsdaten als Umgebungsvariablen ergriffen. Im nächsten Schritt definieren wir unsere Dienste in einer docker-compose.yml-Datei.

      Schritt 3 — Definieren der Dienste mit Docker Compose

      Docker Compose ist ein Tool zum Definieren und Ausführen von Docker-Anwendungen mit mehreren Containern. Wir definieren eine YAML-Datei, um die Dienste unserer Anwendung zu konfigurieren. Ein Dienst oder service in Docker Compose ist ein Container, der ausgeführt wird. Compose ermöglicht uns, diese Dienste zusammen mit geteilten Volumes und Netzwerken zu verknüpfen.

      Wir erstellen verschiedene Container für die Drupal-Anwendung, die Datenbank und den Webserver. Außerdem erstellen wir einen Container, der Certbot ausführt, um Zertifikate für unseren Webserver zu erlangen.

      Erstellen Sie eine docker-compose.yml-Datei:

      Fügen Sie den folgenden Code hinzu, um die Compose-Dateiversion und den mysql-Datenbankdienst zu definieren:

      ~/drupal/docker-compose.yml

      version: "3"
      
      services:
        mysql:
          image: mysql:8.0
          container_name: mysql
          command: --default-authentication-plugin=mysql_native_password
          restart: unless-stopped
          env_file: .env
          volumes:
            - db-data:/var/lib/mysql
          networks:
            - internal
      

      Wir behandeln diese nacheinander mit allen Konfigurationsoptionen des mysql-Dienstes:

      • image: Hiermit wird das Image festgelegt, das wir zum Erstellen des Containers verwenden/pullen. Es wird immer empfohlen, das Image mit dem richtigen Versions-Tag unter Ausschluss des latest-Tags zu verwenden, um zukünftige Konflikte zu vermeiden. Lesen Sie dazu mehr in Best Practices für Dockerfiles in der Docker-Dokumentation.

      • container_name: Hiermit wird der Name des Containers definiert.

      • command: Diese Option wird verwendet, um den Standardbefehl (CMD-Instruktion) im Image zu überschreiben. MySQL hat verschiedene Authentifizierungs-Plugins unterstützt, aber mysql_native_password ist die traditionelle Methode zur Authentifizierung. Da PHP und damit Drupal nicht die neuere MySQL-Authentifizierung unterstützen, müssen wir das --default-authentication-plugin=mysql_native_password als standardmäßigen Authentifizierungsmechanismus festlegen.

      • restart: Diese Option wird verwendet, um die Neustartregel des Containers festzulegen. Die Regel unless-stopped startet einen Container neu, bis er manuell gestoppt wird.

      • env_file: Hiermit werden die Umgebungsvariablen aus einer Datei hinzugefügt. In unserem Fall werden die Umgebungsvariablen aus der im vorherigen Schritt definierten .env-Datei gelesen.

      • volumes: Hiermit werden Host-Pfade oder benannte Volumes, die als Suboptionen eines Dienstes angegeben sind, bereitgestellt. Wir stellen ein benanntes Volume namens db-data im Verzeichnis /var/lib/mysql des Containers bereit, in der MySQL standardmäßig seine Datendateien schreibt.

      • networks: Hiermit wird das internal-Netzwerk, an das sich unser Anwendungsdienst anschließt, definiert. Wir definieren die Netzwerke am Ende der Datei.

      Wir haben unsere mysql-Dienstdefiniton definiert. Nun fügen wir die Definition des drupal-Anwendungsdienstes am Ende der Datei hinzu:

      ~/drupal/docker-compose.yml

      ...
        drupal:
          image: drupal:8.7.8-fpm-alpine
          container_name: drupal
          depends_on:
            - mysql
          restart: unless-stopped
          networks:
            - internal
            - external
          volumes:
            - drupal-data:/var/www/html
      

      In dieser Dienstdefinition benennen wir unseren Container und definieren eine Neustartregel, wie wir es beim mysql-Dienst getan haben. Außerdem fügen wir einige Optionen hinzu, die für diesen Container spezifisch sind:

      • image: Hier verwenden wir Drupal-Image 8.7.8-fpm-alpine. Dieses Image verfügt über den php-fpm-Prozessor, den unser Nginx-Webserver zur Verwaltung der PHP-Verarbeitung benötigt. Darüber hinaus verwenden wir das aus dem Alpine-Linux-Projekt erlangte alpine-Image, das die Größe des Gesamtimages reduziert und in den Best Practices für Dockerfiles empfohlen wird. Drupal verfügt über weitere Versionen von Images, die Sie auf Dockerhub finden können.

      • depends_on: Diese Option wird verwendet, um Abhängigkeit zwischen Diensten auszudrücken. Das Definieren des mysql-Dienstes als Abhängigkeit unseres drupal-Containers stellt sicher, dass unser drupal-Container nach dem mysql-Container erstellt wird und ermöglicht einen reibungslosen Start unserer Anwendung.

      • networks: Hier haben wir diesen Container zusammen mit dem internal-Netzwerk dem external-Netzwerk hinzugefügt. Dadurch wird sichergestellt, dass unser mysql-Dienst nur über das internal-Netzwerk aus dem drupal-Container zugänglich ist, während dieser Container über das external-Netzwerk für andere Container weiterhin zugänglich bleibt.

      • volumes: Wir stellen ein benanntes Volume namens drupal-data im Bereitstellungspunkt /var/www/html bereit, der vom Drupal-Image erstellt wurde. Wenn wir ein benanntes Volume auf diese Weise verwenden, können wir unseren Anwendungscode mit anderen Containern teilen.

      Als Nächstes fügen wir die Nginx-Dienstdefinition nach der drupal-Dienstdefinition hinzu:

      ~/drupal/docker-compose.yml

      ...
        webserver:
          image: nginx:1.17.4-alpine
          container_name: webserver
          depends_on:
            - drupal
          restart: unless-stopped
          ports:
            - 80:80
          volumes:
            - drupal-data:/var/www/html
            - ./nginx-conf:/etc/nginx/conf.d
            - certbot-etc:/etc/letsencrypt
          networks:
            - external
      

      Auch hier benennen wir unseren Container und machen ihn in der Reihenfolge des Starts vom Drupal-Container abhängig. Außerdem verwenden wir ein alpine-Image – das Nginx-Image 1.17.4-alpine.

      Diese Dienstdefinition enthält auch die folgenden Optionen:

      • ports: Hiermit wird Port 80 zur Verfügung gestellt, um die Konfigurationsoptionen zu aktivieren, die wir in unserer Datei nginx.conf in Schritt 1 definiert haben.

      • volumes: Hier definieren wir sowohl das benannte Volume als auch den Host-Pfad:

        • drupal-data:/var/www/html: Hiermit wird unser Drupal-Anwendungscode im Verzeichnis /var/www/html, das wir als die root in unserem Nginx-Serverblock festgelegt haben, bereitgestellt.
        • ./nginx-conf:/etc/nginx/conf.d: Hiermit wird das Nginx-Konfigurationsverzeichnis auf dem Host in dem entsprechenden Verzeichnis im Container bereitgestellt. Dadurch wird sichergestellt, dass alle Änderungen, die wir an Dateien auf dem Host vornehmen, im Container reflektiert werden.
        • certbot-etc:/etc/letsencrypt: Hiermit werden die relevanten Let’s-Encrypt-Zertifikate und die Schlüssel für unsere Domäne in dem entsprechenden Verzeichnis des Containers bereitgestellt.
        • networks: Wir haben das external-Netzwerk nur definiert, damit dieser Container mit dem drupal-Container, aber nicht mit dem mysql-Container kommunizieren kann.

      Schließlich fügen wir unsere letzte Dienstdefinition für den certbot-Dienst hinzu. Achten Sie darauf, sammy@your_domain und your_domain durch Ihre eigene E-Mail-Adresse und den Domänennamen zu ersetzen:

      ~/drupal/docker-compose.yml

      ...
        certbot:
          depends_on:
            - webserver
          image: certbot/certbot
          container_name: certbot
          volumes:
            - certbot-etc:/etc/letsencrypt
            - drupal-data:/var/www/html
          command: certonly --webroot --webroot-path=/var/www/html --email sammy@your_domain --agree-tos --no-eff-email --staging -d your_domain -d www.your_domain
      

      Diese Definition weist Compose an, das Image certbot/certbot von Docker Hub zu pullen. Außerdem werden benannte Volumes verwendet, um Ressourcen für den Nginx-Container freizugeben, einschließlich der Domänenzertifikate und des Schlüssels in certbot-etc und des Anwendungscodes in drupal-data.

      Wir haben auch depends_on verwendet, um sicherzustellen, dass der certbot-Container gestartet wird, nachdem der webserver-Dienst ausgeführt wird.

      Wir haben hier keine networks angegeben, da dieser Container mit keinem Dienst über das Netzwerk kommunizieren wird. Es werden nur die Domänenzertifikate und der Schlüssel hinzugefügt, die wir mit den benannten Volumes bereitgestellt haben.

      Außerdem haben wir die Option command eingeschlossen, die einen Unterbefehl angibt, der mit dem Standardbefehl certbot des Containers ausgeführt werden soll. Der Certbot-Client unterstützt Plugins zur Erstellung und Installation von Zertifikaten. Wir verwenden das webroot-Plugin, um ein Zertifikat zu erlangen, indem wir certonly und --webroot in die Befehlszeile einfügen. Lesen Sie mehr über das Plugin und zusätzliche Befehle in der offiziellen Certbot-Dokumentation.

      Fügen Sie nach der certbot-Dienstdefinition die Netzwerk- und Volume-Definitionen hinzu:

      ~/drupal/docker-compose.yml

      ...
      networks:
        external:
          driver: bridge
        internal:
          driver: bridge
      
      volumes:
        drupal-data:
        db-data:
        certbot-etc:
      

      Mit dem networks-Schlüssel der obersten Ebene können wir die zu erstellenden Netzwerke angeben. networks ermöglicht die Kommunikation über die Dienste/Container auf allen Ports, da sie sich auf demselben Docker-Daemon-Host befinden. Wir haben zwei Netzwerke, internal und external, definiert, um die Kommunikation der Dienste webserver, drupal und mysql zu sichern.

      Der volumes-Schlüssel wird verwendet, um die benannten Volumes drupal-data, db-data und certbot-etc zu definieren. Wenn Docker Volumes erstellt, werden die Inhalte des Volumes in einem Verzeichnis des Host-Dateisystems, /var/lib/docker/volumes/, gespeichert, das von Docker verwaltet wird. Die Inhalte jedes Volumes werden dann von diesem Verzeichnis in jedem Container bereitgestellt, der das Volume verwendet. Auf diese Weise können Code und Daten zwischen Containern geteilt werden.

      Die fertige docker-compose.yml-Datei sieht so aus:

      ~/drupal/docker-compose.yml

      version: "3"
      
      services:
        mysql:
          image: mysql:8.0
          container_name: mysql
          command: --default-authentication-plugin=mysql_native_password
          restart: unless-stopped
          env_file: .env
          volumes:
            - db-data:/var/lib/mysql
          networks:
            - internal
      
        drupal:
          image: drupal:8.7.8-fpm-alpine
          container_name: drupal
          depends_on:
            - mysql
          restart: unless-stopped
          networks:
            - internal
            - external
          volumes:
            - drupal-data:/var/www/html
      
        webserver:
          image: nginx:1.17.4-alpine
          container_name: webserver
          depends_on:
            - drupal
          restart: unless-stopped
          ports:
            - 80:80
          volumes:
            - drupal-data:/var/www/html
            - ./nginx-conf:/etc/nginx/conf.d
            - certbot-etc:/etc/letsencrypt
          networks:
            - external
      
        certbot:
          depends_on:
            - webserver
          image: certbot/certbot
          container_name: certbot
          volumes:
            - certbot-etc:/etc/letsencrypt
            - drupal-data:/var/www/html
          command: certonly --webroot --webroot-path=/var/www/html --email sammy@your_domain --agree-tos --no-eff-email --staging -d your_domain -d www.your_domain
      
      networks:
        external:
          driver: bridge
        internal:
          driver: bridge
      
      volumes:
        drupal-data:
        db-data:
        certbot-etc:
      

      Nun sind unsere Dienstdefinitionen fertig. Als Nächstes starten wir den Container und testen unsere Zertifikatsanforderungen.

      Schritt 4 — Erlangen der SSL-Zertifikate und Zugangsdaten

      Wir können unsere Container mit dem Befehl docker-compose up starten, der die Container in der von uns angegebenen Reihenfolge erstellt und ausführt. Wenn unsere Domain-Anfragen erfolgreich sind, sehen wir den richtigen Exit-Status in unserer Ausgabe und die richtigen Zertifikate, die im Ordner /etc/letsencrypt/live im Webservercontainer bereitgestellt werden.

      Um die Container im Hintergrund auszuführen, verwenden Sie den Befehl docker-compose up mit dem Flag -d:

      Sie sehen eine ähnliche Ausgabe, die bestätigt, dass Ihre Dienste erstellt wurden:

      Output

      ... Creating mysql ... done Creating drupal ... done Creating webserver ... done Creating certbot ... done

      Überprüfen Sie den Status der Dienste mit dem Befehl docker-compose ps:

      Wir sehen die Dienste mysql, drupal und webserver mit einem State von Up, während certbot mit einer Statusmeldung von 0 beendet wird:

      Output

      Name Command State Ports -------------------------------------------------------------------------- certbot certbot certonly --webroot ... Exit 0 drupal docker-php-entrypoint php-fpm Up 9000/tcp mysql docker-entrypoint.sh --def ... Up 3306/tcp, 33060/tcp webserver nginx -g daemon off; Up 0.0.0.0:80->80/tcp

      Wenn Sie in der Spalte State für die Dienste mysql, drupal oder webserver etwas anderes als Up sehen, oder für den certbot-Container einen anderen Exit-Status als 0, überprüfen Sie die Dienstprotokolle mit dem Befehl docker-compose logs:

      • docker-compose logs service_name

      Wir können nun mit dem Befehl docker-compose exec überprüfen, dass unsere Zertifikate auf dem webserver bereitgestellt wurden:

      • docker-compose exec webserver ls -la /etc/letsencrypt/live

      Dadurch erhalten Sie folgende Ausgabe:

      Output

      total 16 drwx------ 3 root root 4096 Oct 5 09:15 . drwxr-xr-x 9 root root 4096 Oct 5 09:15 .. -rw-r--r-- 1 root root 740 Oct 5 09:15 README drwxr-xr-x 2 root root 4096 Oct 5 09:15 your_domain

      Nachdem nun alles erfolgreich ausgeführt wird, können wir unsere certbot-Dienstdefinition bearbeiten, um das Flag --staging zu entfernen.

      Öffnen Sie die Datei docker-compose.yml, gehen Sie zur certbot-Dienstdefinition und ersetzen Sie das Flag --staging in der Befehlsoption mit dem Flag --force-renewal, das Certbot mitteilt, dass Sie ein neues Zertifikat mit denselben Domänen wie ein vorhandenes Zertifikat anfordern möchten. Die aktualisierte Definition von certbot sieht wie folgt aus:

      ~/drupal/docker-compose.yml

      ...
        certbot:
          depends_on:
            - webserver
          image: certbot/certbot
          container_name: certbot
          volumes:
            - certbot-etc:/etc/letsencrypt
            - drupal-data:/var/www/html
          command: certonly --webroot --webroot-path=/var/www/html --email sammy@your_domain --agree-tos --no-eff-email --force-renewal -d your_domain -d www.your_domain
      ...
      

      Wir müssen docker-compose erneut ausführen, um den certbot-Container neu zu erstellen. Wir schließen auch die Option --no-deps ein, um Compose mitzuteilen, dass das Starten des webserver-Dienstes übersprungen werden kann, da dieser bereits ausgeführt wird:

      • docker-compose up --force-recreate --no-deps certbot

      In der Ausgabe sehen wir, dass unsere Zertifikatsanforderung erfolgreich war:

      Output

      Recreating certbot ... done Attaching to certbot certbot | Saving debug log to /var/log/letsencrypt/letsencrypt.log certbot | Plugins selected: Authenticator webroot, Installer None certbot | Renewing an existing certificate certbot | Performing the following challenges: certbot | http-01 challenge for your_domain certbot | http-01 challenge for www.your_domain certbot | Using the webroot path /var/www/html for all unmatched domains. certbot | Waiting for verification... certbot | Cleaning up challenges certbot | IMPORTANT NOTES: certbot | - Congratulations! Your certificate and chain have been saved at: certbot | /etc/letsencrypt/live/your_domain/fullchain.pem certbot | Your key file has been saved at: certbot | /etc/letsencrypt/live/your_domain/privkey.pem certbot | Your cert will expire on 2020-01-03. To obtain a new or tweaked certbot | version of this certificate in the future, simply run certbot certbot | again. To non-interactively renew *all* of your certificates, run certbot | "certbot renew" certbot | - Your account credentials have been saved in your Certbot certbot | configuration directory at /etc/letsencrypt. You should make a certbot | secure backup of this folder now. This configuration directory will certbot | also contain certificates and private keys obtained by Certbot so certbot | making regular backups of this folder is ideal. certbot | - If you like Certbot, please consider supporting our work by: certbot | certbot | Donating to ISRG / Let's Encrypt: https://letsencrypt.org/donate certbot | Donating to EFF: https://eff.org/donate-le certbot | certbot exited with code 0

      Nachdem wir unsere Zertifikate erfolgreich generiert haben, können wir unsere Nginx-Konfiguration aktualisieren, um SSL einzuschließen.

      Schritt 5 — Ändern der Webserver-Konfiguration und Dienstdefinition

      Nach der Installation von SSL-Zertifikaten in Nginx müssen wir alle HTTP-Anfragen an HTTPS umleiten. Außerdem müssen wir unser SSL-Zertifikat und unsere Schlüsselpositionen angeben und Sicherheitsparameter sowie Header hinzufügen.

      Da Sie den webserver-Dienst neu erstellen, um diese Ergänzungen einzuschließen, können Sie diesen jetzt stoppen:

      • docker-compose stop webserver

      Dadurch erhalten Sie folgende Ausgabe:

      Output

      Stopping webserver ... done

      Als Nächstes entfernen wir die zuvor erstellte Nginx-Konfigurationsdatei:

      Öffnen Sie eine andere Version der Datei:

      • nano nginx-conf/nginx.conf

      Fügen Sie der Datei den folgenden Code hinzu, um HTTP an HTTPS umzuleiten und SSL-Zugangsdaten, Protokolle und Sicherheitsheader hinzuzufügen. Denken Sie daran, your_domain durch Ihre eigene Domäne zu ersetzen:

      ~/drupal/nginx-conf/nginx.conf

      server {
          listen 80;
          listen [::]:80;
      
          server_name your_domain www.your_domain;
      
          location ~ /.well-known/acme-challenge {
              allow all;
              root /var/www/html;
          }
      
          location / {
              rewrite ^ https://$host$request_uri? permanent;
          }
      }
      server {
          listen 443 ssl;
          listen [::]:443 ssl;
          server_name your_domain www.your_domain;
      
          index index.php index.html index.htm;
      
          root /var/www/html;
      
          server_tokens off;
      
          ssl_certificate /etc/letsencrypt/live/your_domain/fullchain.pem;
          ssl_certificate_key /etc/letsencrypt/live/your_domain/privkey.pem;
      
          add_header X-Frame-Options "SAMEORIGIN" always;
          add_header X-XSS-Protection "1; mode=block" always;
          add_header X-Content-Type-Options "nosniff" always;
          add_header Referrer-Policy "no-referrer-when-downgrade" always;
          add_header Content-Security-Policy "default-src * data: 'unsafe-eval' 'unsafe-inline'" always;
      
          location / {
              try_files $uri $uri/ /index.php$is_args$args;
          }
      
          rewrite ^/core/authorize.php/core/authorize.php(.*)$ /core/authorize.php$1;
      
          location ~ .php$ {
              try_files $uri =404;
              fastcgi_split_path_info ^(.+.php)(/.+)$;
              fastcgi_pass drupal:9000;
              fastcgi_index index.php;
              include fastcgi_params;
              fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
              fastcgi_param PATH_INFO $fastcgi_path_info;
          }
      
          location ~ /.ht {
              deny all;
          }
      
          location = /favicon.ico {
              log_not_found off; access_log off;
          }
          location = /robots.txt {
              log_not_found off; access_log off; allow all;
          }
          location ~* .(css|gif|ico|jpeg|jpg|js|png)$ {
              expires max;
              log_not_found off;
          }
      }
      

      Der HTTP-Serverblock gibt das Webroot-Plugin für Certbot-Erneuerungsanfragen an das Verzeichnis .well-known/acme-challenge an. Er enthält auch eine rewrite-Anweisung, die HTTP-Anfragen an das root-Verzeichnis an HTTPS leitet.

      Der HTTPS-Serverblock aktiviert ssl und http2. Weitere Informationen dazu, wie HTTP/2 über HTTP-Protokolle iteriert und welche Vorteile es für die Website-Leistung haben kann, lesen Sie bitte in der Einführung Einrichten von Nginx mit HTTP/2-Support unter Ubuntu 18.04.

      Diese Blocks aktivieren SSL, da wir unser SSL-Zertifikat und die Schlüsselpositionen zusammen mit den empfohlenen Headern eingefügt haben. Diese Header ermöglichen uns eine A-Bewertung auf den Server-Testseiten SSL-Labs und Security Headers.

      Unsere Anweisungen root und index befinden sich ebenfalls in diesem Block, ebenso wie die restlichen Drupal-spezifischen Location-Blocks, die in Schritt 1 behandelt wurden.

      Speichern und schließen Sie die aktualisierte Nginx-Konfigurationsdatei.

      Bevor wir den webserver-Container neu erstellen, müssen wir unserem webserver-Dienst ein 443-Port-Mapping hinzufügen, da wir SSL-Zertifikate aktiviert haben.

      Öffnen Sie die Datei docker-compose.yml:

      Führen Sie die folgenden Änderungen in der webserver-Dienstdefinition aus:

      ~/drupal/docker-compose.yml

      ...
        webserver:
          image: nginx:1.17.4-alpine
          container_name: webserver
          depends_on:
            - drupal
          restart: unless-stopped
          ports:
            - 80:80
            - 443:443
          volumes:
            - drupal-data:/var/www/html
            - ./nginx-conf:/etc/nginx/conf.d
            - certbot-etc:/etc/letsencrypt
          networks:
            - external
      ...
      

      Nach dem Aktivieren der SSL-Zertifikate sieht unsere docker-compose.yml wie folgt aus:

      ~/drupal/docker-compose.yml

      version: "3"
      
      services:
        mysql:
          image: mysql:8.0
          container_name: mysql
          command: --default-authentication-plugin=mysql_native_password
          restart: unless-stopped
          env_file: .env
          volumes:
            - db-data:/var/lib/mysql
          networks:
            - internal
      
        drupal:
          image: drupal:8.7.8-fpm-alpine
          container_name: drupal
          depends_on:
            - mysql
          restart: unless-stopped
          networks:
            - internal
            - external
          volumes:
            - drupal-data:/var/www/html
      
        webserver:
          image: nginx:1.17.4-alpine
          container_name: webserver
          depends_on:
            - drupal
          restart: unless-stopped
          ports:
            - 80:80
            - 443:443
          volumes:
            - drupal-data:/var/www/html
            - ./nginx-conf:/etc/nginx/conf.d
            - certbot-etc:/etc/letsencrypt
          networks:
            - external
      
        certbot:
          depends_on:
            - webserver
          image: certbot/certbot
          container_name: certbot
          volumes:
            - certbot-etc:/etc/letsencrypt
            - drupal-data:/var/www/html
          command: certonly --webroot --webroot-path=/var/www/html --email sammy@your_domain --agree-tos --no-eff-email --force-renewal -d your_domain -d www.your_domain
      
      networks:
        external:
          driver: bridge
        internal:
          driver: bridge
      
      volumes:
        drupal-data:
        db-data:
        certbot-etc:
      

      Speichern und schließen Sie die Datei. Wir erstellen den webserver-Dienst mit unserer aktualisierten Konfiguration nun neu:

      • docker-compose up -d --force-recreate --no-deps webserver

      Dadurch erhalten Sie folgende Ausgabe:

      Output

      Recreating webserver ... done

      Überprüfen Sie die Dienste mit docker-compose ps:

      Wir sehen die Dienste mysql, drupal und webserver als Up, während certbot mit der Statusmeldung 0 beendet wird:

      Output

      Name Command State Ports -------------------------------------------------------------------------- certbot certbot certonly --webroot ... Exit 0 drupal docker-php-entrypoint php-fpm Up 9000/tcp mysql docker-entrypoint.sh --def ... Up 3306/tcp, 33060/tcp webserver nginx -g daemon off; Up 0.0.0.0:443->443/tcp, 0.0.0.0:80->80/tcp

      Jetzt werden alle unsere Dienste ausgeführt und wir können mit der Installation von Drupal über die Web-Oberfläche fortfahren.

      Schritt 6 – Abschließen der Installation über die Weboberfläche

      Beenden wir die Installation über die Weboberfläche von Drupal.

      Navigieren Sie in einem Webbrowser zur Domäne des Servers. Denken Sie daran, your_domain hier mit Ihrem eigenen Domänennamen zu ersetzen:

      https://your_domain
      

      Wählen Sie die Sprache aus, die Sie verwenden möchten:

      Sprachauswahlseite auf der Drupal-Weboberfläche

      Klicken Sie auf Speichern und fortfahren. Wir werden zur Seite der Installationsprofile geleitet. Drupal bietet verschiedene Profile. Wählen Sie das Profil Standard und klicken Sie auf Speichern und fortfahren.

      Profilauswahlseite auf der Drupal-Weboberfläche

      Nach Auswahl des Profils gehen wir weiter zur Seite der Datenbankkonfiguration. Wählen Sie als Datenbanktyp MySQL, MariaDB, Percona Server oder äquivalent aus. Geben Sie die Werte für Datenbankname, Benutzername und Passwort entsprechend der Werte von MYSQL_DATABASE, MYSQL_USER und MYSQL_PASSWORD ein, die jeweils in der .env-Datei in Schritt 2 definiert wurden. Klicken Sie auf Erweiterte Optionen und setzen Sie den Wert für Host auf den Namen des mysql-Dienstcontainers. Klicken Sie auf Speichern und fortfahren.

      Datenbankeinrichtungsseite auf der Drupal-Weboberfläche

      Nach Konfiguration der Datenbank beginnt die Installation der Standardmodule und Themen von Drupal:

      Installationsseite der Website auf der Drupal-Weboberfläche

      Nachdem die Website installiert ist, werden wir auf die Einrichtungsseite der Drupal-Website geleitet, um den Namen der Website, die E-Mail-Adresse, den Benutzernamen, das Passwort und die Ländereinstellungen zu konfigurieren. Geben Sie die Informationen an und klicken Sie auf Speichern und fortfahren:

      Konfigurationsseite der Website auf der Drupal-Weboberfläche

      Nachdem wir auf Speichern und fortfahren geklickt haben, sehen wir die Seite Willkommen bei Drupal. Diese zeigt uns, dass unsere Drupal-Website eingerichtet ist und erfolgreich ausgeführt wird.

      Seite Willkommen bei Drupal auf der Drupal-Weboberfläche

      Nachdem die Installation von Drupal nun abgeschlossen ist, müssen wir sicherstellen, dass unsere SSL-Zertifikate automatisch erneuert werden.

      Schritt 7 — Erneuern der Zertifikate

      Let’s-Encrypt-Zertifikate sind 90 Tage gültig. Daher müssen wir einen automatisierten Erneuerungsprozess einrichten, um sicherzustellen, dass sie nicht ablaufen. Eine Möglichkeit hierzu ist das Erstellen eines Jobs mit dem Planungsprogramm cron. In diesem Fall erstellen wir einen cron-Job, der in regelmäßigen Abständen ein Skript ausführt, das unsere Zertifikate erneuert und die Nginx-Konfiguration neu lädt.

      Wir erstellen die Datei ssl_renew.sh, um unsere Zertifikate zu erneuern:

      Fügen Sie folgenden Code hinzu. Denken Sie daran, den Verzeichnisnamen durch Ihren eigenen non-root user zu ersetzen:

      ~/drupal/ssl_renew.sh

      
      #!/bin/bash
      
      cd /home/sammy/drupal/
      /usr/local/bin/docker-compose -f docker-compose.yml run certbot renew --dry-run && 
      /usr/local/bin/docker-compose -f docker-compose.yml kill -s SIGHUP webserver
      

      Das Skript wechselt zum ~/drupal-Projektverzeichnis und führt die folgenden docker-compose-Befehle aus.

      • docker-compose run: Hiermit wird ein certbot-Container gestartet und der in unserer certbot-Dienstdefinition verfügbare command überschrieben. Anstatt des Unterbefehls certonly verwenden wir hier den Unterbefehl renew, mit dem Zertifikate, die kurz vor Ablauf stehen, erneuert werden. Wir haben hier die Option --dry-run zum Testen unseres Skripts hinzugefügt.

      • docker-compose kill: Hiermit wird ein SIGHUP-Signal an den webserver-Container gesendet, um die Nginx-Konfiguration neu zu laden.

      Schließen Sie die Datei und machen Sie sie mit folgendem Befehl ausführbar:

      • sudo chmod +x ssl_renew.sh

      Öffnen Sie als Nächstes die Datei root crontab, um das Erneuerungsskript in einem angegebenen Intervall auszuführen:

      Wenn Sie die Datei zum ersten Mal bearbeiten, werden Sie dazu aufgefordert, einen Texteditor zum Öffnen der Datei zu wählen:

      Output

      no crontab for root - using an empty one Select an editor. To change later, run 'select-editor'. 1. /bin/nano 2. /usr/bin/vim.basic 3. /usr/bin/vim.tiny 4. /bin/ed Choose 1-4 [1]: ...

      Fügen Sie am Ende der Datei die folgende Zeile hinzu und ersetzen Sie sammy mit Ihrem Benutzernamen:

      crontab

      ...
      */5 * * * * /home/sammy/drupal/ssl_renew.sh >> /var/log/cron.log 2>&1
      

      Hiermit wird das Job-Intervall auf alle fünf Minuten festgelegt, sodass wir testen können, ob unsere Erneuerungsanfrage wie beabsichtigt funktioniert hat oder nicht. Außerdem haben wir eine Protokolldatei, cron.log, zum Aufzeichnen der relevanten Ausgabe erstellt.

      Verwenden Sie nach fünf Minuten den Befehl tail, um cron.log zu prüfen und zu sehen, ob die Erneuerungsanfrage erfolgreich war oder nicht:

      • tail -f /var/log/cron.log

      Sie sehen eine Ausgabe, die eine erfolgreiche Erneuerung bestätigt:

      Output

      ** DRY RUN: simulating 'certbot renew' close to cert expiry ** (The test certificates below have not been saved.) Congratulations, all renewals succeeded. The following certs have been renewed: /etc/letsencrypt/live/your_domain/fullchain.pem (success) ** DRY RUN: simulating 'certbot renew' close to cert expiry ** (The test certificates above have not been saved.) - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

      Drücken Sie STRG+C, um den tail-Prozess zu beenden.

      Wir können jetzt die Datei crontab ändern, um das Skript jeden zweiten Tag der Woche um 02:00 Uhr auszuführen. Ändern Sie die letzte Zeile der crontab wie folgt:

      crontab

      ...
      * 2 * * 2 /home/sammy/drupal/ssl_renew.sh >> /var/log/cron.log 2>&1
      

      Speichern und schließen Sie die Datei.

      Nun entfernen wir die Option --dry-run aus dem Skript ssl_renew.sh. Öffnen Sie es zunächst:

      Ändern Sie dann den Inhalt wie folgt:

      ~/drupal/ssl_renew.sh

      #!/bin/bash
      
      cd /home/sammy/drupal/
      /usr/local/bin/docker-compose -f docker-compose.yml run certbot renew && 
      /usr/local/bin/docker-compose -f docker-compose.yml kill -s SIGHUP webserver
      

      Unser cron-Job kümmert sich nun um den Ablauf unserer SSL-Zertifikate, indem er sie erneuert, wenn sie hierfür infrage kommen.

      Zusammenfassung

      In diesem Tutorial haben wir Docker Compose verwendet, um eine Drupal-Installation mit einem Nginx-Webserver zu erstellen. Als Teil des Workflows haben wir TLS/SSL-Zertifikate für die Domäne erlangt, mit der wir unsere Drupal-Website verknüpfen wollten, und einen cron-Job erstellt, um diese Zertifikate bei Bedarf zu erneuern.

      Wenn Sie mehr über Docker erfahren möchten, besuchen Sie unsere Docker-Themenseite.



      Source link

      Überwachen von BGP-Ankündigungen und -Routen mit BGPalerter unter Ubuntu 18.04


      Der Autor hat den COVID-19 Relief Fund dazu ausgewählt, eine Spende im Rahmen des Programms Write for DOnations zu erhalten.

      Einführung

      BGP (Border Gateway Protocol) ist eines der Kernprotokolle, die für das Weiterleiten von Paketen über das Internet verantwortlich sind. Wenn es also schief geht, können erhebliche Ausfälle auftreten. Beispielsweise hat ein kleiner ISP im Jahr 2019 eine BGP-Fehlkonfiguration vorgenommen, die sich leider im Upstream verbreitet und große Teile von Cloudflare und AWS über eine Stunde lang offline geschaltet hat. Ein Jahr zuvor fand außerdem ein BGP-Hijack statt, um den Datenverkehr zu einem bekannten Kryptowährungs-Wallet-Anbieter abzufangen und die Gelder ahnungsloser Kunden zu stehlen.

      BGPalerter ist ein Open-Source-Tool zur Überwachung des BGP-Netzwerks, das Echtzeit-Warnungen zu BGP-Aktivitäten, einschließlich Routensichtbarkeit und Ankündigungen neuer Routen, sowie potenziell schädliche Aktivitäten wie Routen-Hijacking oder Routenlecks bereitstellen kann. BGPalerter nimmt automatisch öffentlich verfügbare Netzwerkroutinginformationen auf, was bedeutet, dass es keinen privilegierten Zugriff oder keine Integration in die Netzwerke haben muss, die Sie überwachen möchten.

      Hinweis: BGPalerter nimmt automatisch öffentlich verfügbare Netzwerkroutinginformationen auf, was bedeutet, dass es keinen privilegierten Zugriff oder keine Integration in die Netzwerke haben muss, die Sie überwachen möchten. Alle Überwachungen entsprechen vollständig dem Gesetz über Computermissbrauch, dem Gesetz über Computerbetrug und -missbrauch und anderen ähnlichen Gesetzen. Es wird jedoch empfohlen, relevante Ergebnisse dem betroffenen Netzwerkbetreiber verantwortungsbewusst mitzuteilen.

      In diesem Tutorial installieren und konfigurieren Sie BGPalerter, um Ihre wichtigen Netzwerke auf potenziell verdächtige Aktivitäten zu überwachen.

      Voraussetzungen

      Um diesem Tutorial zu folgen, benötigen Sie:

      • Einen Ubuntu 18.04-Server, der gemäß der Ersteinrichtung eines Servers unter Ubuntu 18.04 eingerichtet wurde, einschließlich eines sudo non-root users.

      • Ein oder mehrere Netzwerke oder Geräte, die Sie überwachen möchten, zum Beispiel:

        • Einen Server, den Sie verwalten
        • Ihr Firmennetzwerk
        • Ihre lokale ISP

      Für jedes Gerät oder Netzwerk müssen Sie entweder die individuelle IP-Adresse, den IP-Adressbereich oder die Nummer des autonomen Systems angeben, zu der es gehört. Dies ist in Schritt 1 abgedeckt.

      Sobald Sie diese zur Verfügung haben, melden Sie sich zunächst als non-root user auf Ihrem Server an.

      Schritt 1 – Identifizieren der zu überwachenden Netzwerke

      In diesem Schritt sehen Sie die relevanten Details der Netzwerke, die Sie überwachen möchten.

      BGPalerter kann anhand einzelner IP-Adressen oder Netzwerkpräfixe überwachen. Es kann auch ganze Netzwerke anhand ihrer AS-Nummer (Autonomous System) überwachen. Dies ist eine global eindeutige Kennung für ein Netzwerk, das einer bestimmten Verwaltungseinheit gehört.

      Um diese Informationen zu finden, können Sie den Suchdienst IP-to-ASN WHOIS verwenden, der vom Bedrohungsnachrichtendienst Team Cymru bereitgestellt wird. Dies ist ein benutzerdefinierter WHOIS-Server, mit dem IP-Adressen und Netzwerkroutinginformationen abgerufen werden können.

      Wenn Sie whois noch nicht installiert haben, können Sie es mit den folgenden Befehlen installieren:

      • sudo apt update
      • sudo apt install whois

      Sobald Sie die Installation von whois bestätigt haben, wird nun die IP-Adresse Ihres eigenen Servers anhand des Arguments -h angezeigt, um einen benutzerdefinierten Server anzugeben:

      • whois -h whois.cymru.com your-ip-address

      Dies gibt ein Ergebnis ähnlich dem folgenden aus, das den AS-Namen und die AS-Nummer anzeigt, zu der Ihr Server gehört. Dies ist normalerweise der AS Ihres Server-Hosting-Anbieters, z. B. DigitalOcean.

      Output

      AS | IP | AS Name 14061 | your-ip-address | DIGITALOCEAN-ASN, US

      Als Nächstes können Sie eine Suche durchführen, um das Netzwerkpräfix/den Netzwerkbereich zu ermitteln, zu dem Ihr Server gehört. Dazu fügen Sie Ihrer Anfrage das Argument -p hinzu:

      • whois -h whois.cymru.com " -p your-ip-address"

      Die Ausgabe ist dem vorherigen Befehl sehr ähnlich, zeigt jedoch jetzt das IP-Adresspräfix an, zu dem die IP-Adresse Ihres Servers gehört:

      Output

      AS | IP | BGP Prefix | AS Name 14061 | your-ip-address | 157.230.80.0/20 | DIGITALOCEAN-ASN, US

      Schließlich können Sie weitere Details des AS nachschlagen, zu dem Ihr Server gehört, einschließlich der geografischen Region und des Zuordnungsdatums.

      Ersetzen Sie die AS-Nummer, die Sie mit den vorherigen Befehlen identifiziert haben. Mit dem Argument -v aktivieren Sie die ausführliche Ausgabe, um sicherzustellen, dass alle relevanten Details angezeigt werden:

      • whois -h whois.cymru.com " -v as14061"

      Die Ausgabe zeigt weitere Informationen zur AS:

      Output

      AS | CC | Registry | Allocated | AS Name 14061 | US | arin | 2012-09-25 | DIGITALOCEAN-ASN, US

      Sie haben wichtige Details zu den Netzwerken identifiziert, die Sie überwachen möchten. Notieren Sie sich diese Details irgendwo, da Sie sie später benötigen. Als Nächstes beginnen Sie mit der Einrichtung von BGPalerter.

      Schritt 2 – Erstellen eines nicht privilegierten Benutzers für BGPalerter

      In diesem Schritt erstellen Sie ein neues nicht privilegiertes Benutzerkonto für BGPalerter, da das Programm nicht mit sudo-/root-Berechtigungen ausgeführt werden muss.

      Erstellen Sie zunächst einen neuen Benutzer mit einem deaktivierten Passwort:

      • sudo adduser --disabled-password bgpalerter

      Sie müssen weder ein Passwort noch SSH-Schlüssel einrichten, da Sie diesen Benutzer nur als Dienstkonto zum Ausführen/Verwalten von BGPalerter verwenden.

      Melden Sie sich mit su beim neuen Benutzer an:

      Sie werden jetzt als neuer Benutzer angemeldet:

      bgpalerter@droplet:/home/user$
      

      Verwenden Sie den Befehl cd, um in das Ausgangsverzeichnis Ihres neuen Benutzers zu wechseln:

      bgpalerter@droplet:/home/user$ cd
      bgpalerter@droplet:~$
      

      Sie haben einen neuen nicht privilegierten Benutzer für BGPalerter erstellt. Als Nächstes installieren und konfigurieren Sie BGPalerter auf Ihrem System.

      Schritt 3 — Installieren und Konfigurieren von BGPalerter

      In diesem Schritt installieren und konfigurieren Sie BGPalerter. Stellen Sie sicher, dass Sie als Ihr neuer nicht privilegierter Benutzer noch angemeldet sind.

      Zuerst müssen Sie die neueste Version von BGPalerter identifizieren, um sicherzustellen, dass Sie die aktuellste Version herunterladen. Navigieren Sie zur Seite BGPalerter Releases und kopieren Sie den Download-Link für die neueste Linux x64-Version.

      Sie können jetzt eine Kopie von BGPalerter mit wget herunterladen und dabei sicherstellen, dass Sie den richtigen Download-Link verwenden:

      • wget https://github.com/nttgin/BGPalerter/releases/download/v1.24.0/bgpalerter-linux-x64

      Markieren Sie die heruntergeladene Datei als ausführbar:

      • chmod +x bgpalerter-linux-x64

      Überprüfen Sie als Nächstes, ob BGPalerter erfolgreich heruntergeladen und installiert wurde, indem Sie die Versionsnummer überprüfen:

      • ./bgpalerter-linux-x64 --version

      Dadurch wird die aktuelle Versionsnummer ausgegeben:

      Output

      1.24.0

      Bevor Sie BGPalerter ordnungsgemäß ausführen können, müssen Sie die Netzwerke, die Sie überwachen möchten, in einer Konfigurationsdatei definieren. Erstellen und öffnen Sie die Datei prefixes.yml in Ihrem bevorzugten Texteditor:

      In dieser Konfigurationsdatei geben Sie jede der einzelnen IP-Adressen, IP-Adressbereiche und AS-Nummern an, die Sie überwachen möchten.

      Fügen Sie das folgende Beispiel hinzu und passen Sie die Konfigurationswerte mithilfe der in Schritt 1 angegebenen Netzwerkinformationen nach Bedarf an:

      ~/prefixes.yml

      your-ip-address/32:
        description: My Server
        asn:
          - 14061
        ignoreMorespecifics: false
      
      157.230.80.0/20:
        description: IP range for my Server
        asn:
          - 14061
        ignoreMorespecifics: false
      
      options:
        monitorASns:
          '14061':
            group: default
      

      Sie können beliebig viele IP-Adressbereiche oder AS-Nummern überwachen. Um einzelne IP-Adressen zu überwachen, stellen Sie sie mit /32 für IPv4 und /128 für IPv6 dar.

      Der Wert ignoreMorespecifics wird verwendet, um zu steuern, ob BGPalerter Aktivitäten für Routen ignorieren soll, die spezifischer (kleiner) sind als die, die Sie überwachen. Wenn Sie beispielsweise eine /20 überwachen und eine Routingänderung für eine /24 darin festgestellt wird, wird dies als spezifischer angesehen. In den meisten Fällen möchten Sie diese nicht ignorieren. Wenn Sie jedoch ein großes Netzwerk mit mehreren delegierten Kundenpräfixen überwachen, kann dies dazu beitragen, Hintergrundgeräusche zu reduzieren.

      Sie können BGPalerter jetzt zum ersten Mal ausführen, um mit der Überwachung Ihrer Netzwerke zu beginnen:

      Wenn BGPalerter erfolgreich gestartet wird, wird eine Ausgabe ähnlich der folgenden angezeigt. Beachten Sie, dass es manchmal einige Minuten dauern kann, um die Überwachung zu beginnen:

      Output

      Impossible to load config.yml. A default configuration file has been generated. BGPalerter, version: 1.24.0 environment: production Loaded config: /home/bgpalerter/config.yml Monitoring 157.230.80.0/20 Monitoring your-ip-address/32 Monitoring AS 14061

      BGPalerter wird so lange ausgeführt, bis Sie es mit Strg + C stoppen.

      Im nächsten Schritt interpretieren Sie einige der Warnungen, die BGPalerter generieren kann.

      Schritt 4 – Interpretieren von BGPalerter-Warnungen

      In diesem Schritt werden einige beispielhafte BGPalerter-Warnungen überprüft. BGPalerter gibt Warnungen an den Hauptausgabe-Feed und optional an zusätzliche Berichtsendpunkte aus, die in config.yml konfiguriert werden können, wie in der BGPalerter-Dokumentation beschrieben.

      Standardmäßig überwacht und alarmiert BGPalerter Folgendes:

      • Routen-Hijacks: treten auf, wenn eine AS ein Präfix ankündigt, das nicht zulässig ist, wodurch der Datenverkehr fälschlicherweise weitergeleitet wird. Dies kann entweder ein absichtlicher Angriff oder ein versehentlicher Konfigurationsfehler sein.

      • Verlust der Routensichtbarkeit: Eine Route wird als sichtbar angesehen, wenn die meisten BGP-Router im Internet zuverlässig darauf routen können. Ein Verlust der Sichtbarkeit bezieht sich darauf, dass Ihr Netzwerk möglicherweise nicht verfügbar ist, z. B. wenn Ihr BGP-Peering nicht mehr funktioniert.

      • Neue Unterpräfixankündigungen: Wenn eine AS beginnt, ein Präfix anzukündigen, das kleiner ist als erwartet. Dies kann auf eine beabsichtigte Konfigurationsänderung, eine versehentliche Fehlkonfiguration oder in einigen Fällen auf einen Angriff hinweisen.

      • Aktivität innerhalb Ihrer AS: bezieht sich normalerweise auf neue Routenankündigungen. Eine Route wird als „neu“ angesehen, wenn BGPalerter noch nichts von ihr weiß.

      Im Folgenden finden Sie einige Beispielwarnungen sowie eine kurze Beschreibung ihrer Bedeutung:

      Alert #1

      The prefix 203.0.113.0/24 is announced by AS64496 instead of AS65540
      

      Diese Warnung zeigt Hinweise auf einen Routen-Hijack, bei dem AS64496 203.0.113.0/24 angekündigt hat, wenn erwartet wird, dass diese Route von AS65540 angekündigt wird. Dies ist ein starker Indikator für eine Fehlkonfiguration, die zu einem Routenleck oder zu absichtlichem Hijacking durch einen Angreifer führt.

      Alert #2

      The prefix 203.0.113.0/24 has been withdrawn. It is no longer visible from 6 peers
      

      Diese Warnung zeigt an, dass das Netzwerk 203.0.113.0/24 nicht mehr sichtbar ist. Dies kann an einem Upstream-Routing-Problem liegen oder an einem Stromausfall eines Routers.

      Alert #3

      A new prefix 203.0.113.0/25 is announced by AS64496. It should be instead 203.0.113.0/24 announced by AS64496
      

      Diese Warnung zeigt an, dass ein spezifischeres Präfix angekündigt wurde, wenn es nicht erwartet wird, z. B. indem eine /25 angekündigt wird, wenn nur eine /24 erwartet wird. Dies ist höchstwahrscheinlich eine Fehlkonfiguration, kann jedoch in einigen Fällen ein Hinweis auf einen Routen-Hijack sein.

      Alert #4

      AS64496 is announcing 192.0.2.0/24 but this prefix is not in the configured list of announced prefixes
      

      Schließlich zeigt diese Warnung, dass AS64496 ein Präfix angekündigt hat, über das BGPalerter noch nichts weiß. Dies kann daran liegen, dass Sie zu Recht ein neues Präfix ankündigen, oder an einer Fehlkonfiguration, die dazu führt, dass Sie versehentlich ein Präfix ankündigen, das einer anderen Person gehört.

      In diesem Schritt haben Sie einige Beispiel-BGPalerter-Warnungen überprüft. Als Nächstes konfigurieren Sie BGPalerter so, dass es beim Booten automatisch ausgeführt wird.

      Schritt 5 — Starten von BGPalerter beim Booten

      In diesem letzten Schritt konfigurieren Sie BGPalerter so, dass es beim Booten ausgeführt wird.

      Stellen Sie sicher, dass Sie weiterhin als Ihr neuer nicht privilegierter Benutzer angemeldet sind, und öffnen Sie dann den crontab-Editor:

      Fügen Sie als Nächstes den folgenden Eintrag am Ende der crontab-Datei hinzu:

      crontab

      @reboot sleep 10; screen -dmS bgpalerter "./bgpalerter-linux-x64"
      

      Bei jedem Systemstart wird eine getrennte Bildschirmsitzung mit dem Namen ‘bgpalerter’ erstellt und BGPalerter darin gestartet.

      Speichern und schließen Sie den crontab-Editor. Vielleicht möchten Sie Ihr System jetzt neu starten, um sicherzustellen, dass BGPalerter beim Booten richtig startet.

      Sie müssen sich zuerst von Ihrem BGPalerter-Benutzer abmelden:

      Fahren Sie dann mit einem normalen Systemneustart fort:

      Melden Sie sich nach dem Neustart Ihres Systems erneut bei Ihrem Server an und verwenden Sie su, um erneut auf Ihren BGPalerter-Benutzer zuzugreifen:

      Sie können dann jederzeit eine Verbindung zur Sitzung herstellen, um die Ausgabe von BGPalerter anzuzeigen:

      In diesem letzten Schritt konfigurieren Sie BGPalerter so, dass es beim Booten ausgeführt wird.

      Zusammenfassung

      In diesem Artikel haben Sie BGPalerter eingerichtet und damit Netzwerke auf Änderungen des BGP-Routings überwacht.

      Wenn Sie BGPalerter benutzerfreundlicher gestalten möchten, können Sie es so konfigurieren, dass Warnungen über einen Webhook an einen Slack-Kanal gesendet werden:

      Wenn Sie mehr über BGP selbst erfahren möchten, aber keinen Zugriff auf eine Produktions-BGP-Umgebung haben, können Sie DN42 verwenden, um mit BGP in einer sicheren, isolierten Umgebung zu experimentieren:



      Source link

      So sichern Sie Apache mit Let’s Encrypt unter Ubuntu 20.04


      Einführung

      Let’s Encrypt ist eine Zertifizierungsstelle (Certificate Authority, CA), die das Abrufen und Installieren von kostenlosen TLS-/SSL-Zertifikaten erleichtert und so verschlüsseltes HTTPS auf Webservern ermöglicht. Es vereinfacht den Prozess, indem ein Software-Client, Certbot, bereitgestellt wird, der versucht, die meisten (wenn nicht alle) der erforderlichen Schritte zu automatisieren. Derzeit ist der gesamte Prozess zum Abrufen und Installieren eines Zertifikats sowohl auf Apache als auch auf Nginx vollständig automatisiert.

      In diesem Leitfaden verwenden wir Certbot, um ein kostenloses SSL-Zertifikat für Apache unter Ubuntu 20.04 zu erhalten, und stellen sicher, dass dieses Zertifikat so eingerichtet ist, dass es automatisch erneuert wird.

      In diesem Tutorial wird anstelle der Standardkonfigurationsdatei von Apache eine separate virtuelle Hostdatei zum Einrichten der Website verwendet, die von Let’s Encrypt gesichert wird. Wir empfehlen, neue virtuelle Apache-Hostdateien für jede auf einem Server gehostete Domäne zu erstellen, da dies dazu beiträgt, häufige Fehler zu vermeiden und die Standardkonfigurationsdateien als Fallback-Setup beizubehalten.

      Voraussetzungen

      Um dieser Anleitung zu folgen, benötigen Sie:

      • Einen Ubuntu 20.04-Server, der gemäß dem Tutorial Ersteinrichtung des Servers für Ubuntu 20.04 eingerichtet wurde, einschließlich eines sudo non-root users und einer Firewall.

      • Einen vollständig registrierten Domänennamen. In diesem Tutorial wird your_domain durchgehend als Beispiel verwendet. Sie können einen Domänennamen unter Namecheap günstig erwerben oder einen kostenlosen von Freenom herunterladen,. oder einfach die Domänenregistrierngsstelle Ihrer Wahl verwenden.

      • Die beiden folgenden DNS-Einträge wurden für Ihren Server eingerichtet. Sie finden in dieser Einführung in DigitalOcean DNS Details dazu, wie Sie sie hinzufügen können.

        • Einen A-Datensatz mit your-domain, der auf die öffentliche IP-Adresse Ihres Servers verweist.
        • Einen A-Datensatz mit your-domain, der auf die öffentliche IP-Adresse Ihres Servers verweist.
      • Apache gemäß Installieren von Apache unter Ubuntu 20.04 installiert. Stellen Sie sicher, dass Sie eine virtuelle Hostdatei für Ihre Domäne haben. In diesem Tutorial wird /etc/apache2/sites-available/your_domain.conf als Beispiel verwendet.

      Schritt 1 — Installieren von Certbot

      Um ein SSL-Zertifikat mit Let’s Encrypt zu erhalten, müssen wir zuerst die Certbot-Software auf Ihrem Server installieren. Wir werden dafür die Standard-Ubuntu-Paket-Repositorys verwenden.

      Wir benötigen zwei Pakete: certbot und python3-certbot-apache. Letzteres ist ein Plugin, das Certbot in Apache integriert und ermöglicht, das Abrufen eines Zertifikats und das Konfigurieren von HTTPS auf Ihrem Webserver mit einem einzigen Befehl zu automatisieren.

      • sudo apt install certbot python3-certbot-apache

      Außerdem werden Sie zur Bestätigung der Installation aufgefordert, indem Sie Y und dann ENTER drücken.

      Certbot ist jetzt auf Ihrem Server installiert. Im nächsten Schritt verifizieren wir die Konfiguration von Apache, um sicherzustellen, dass Ihr virtueller Host angemessen festgelegt ist. Dadurch wird sichergestellt, dass das Certbot-Client-Skript Ihre Domänen erkennen und Ihren Webserver so konfigurieren kann, dass Ihr neu generiertes SSL-Zertifikat automatisch verwendet wird.

      Schritt 2 — Überprüfen Ihrer Apache Virtual Host-Konfiguration

      Um SSL für Ihren Webserver automatisch abrufen und konfigurieren zu können, muss Certbot den richtigen virtuellen Host in Ihren Apache-Konfigurationsdateien finden. Ihre Serverdomänennamen werden aus den Anweisungen ServerName und ServerAlias abgerufen, die in Ihrem VirtualHost-Konfigurationsblock definiert sind.

      Wenn Sie den Schritt zum Einrichten des virtuellen Hosts im Tutorial zur Apache-Installation ausgeführt haben, sollten Sie einen VirtualHost-Block für Ihre Domäne unter /etc/apache2/sites-available/your_domain.conf mit dem ServerName und auch den ServerAlias-Anweisungen, die bereits entsprechend festgelegt wurden, einrichten.

      Um dies zu überprüfen, öffnen Sie die virtuelle Hostdatei für Ihre Domäne mit nano oder Ihrem bevorzugten Texteditor:

      • sudo nano /etc/apache2/sites-available/your_domain.conf

      Suchen Sie die bestehenden Zeilen ServerName und ServerAlias. Sie sollten wie folgt aussehen:

      /etc/apache2/sites-available/your_domain.conf

      ...
      ServerName your_domain
      ServerAlias www.your_domain
      ...
      

      Wenn Sie Ihren ServerName und Ihre ServerAlias bereits so eingerichtet haben, können Sie Ihren Texteditor beenden und mit dem nächsten Schritt fortfahren. Wenn Sie nano verwenden, können Sie zum Beenden STRG+X drücken, dann Y und ENTER, um zu bestätigen.

      Wenn Ihre aktuelle virtuelle Hostkonfiguration nicht dem Beispiel entspricht, aktualisieren Sie sie entsprechend. Wenn Sie fertig sind, speichern Sie die Datei und beenden Sie den Editor. Führen Sie dann den folgenden Befehl aus, um Ihre Änderungen zu validieren:

      • sudo apache2ctl configtest

      Sie sollten eine Syntax OK als Antwort erhalten. Wenn Sie einen Fehler erhalten, öffnen Sie die virtuelle Hostdatei und überprüfen Sie sie auf Schreibfehler oder fehlende Zeichen. Sobald die Syntax Ihrer Konfigurationsdatei korrekt ist, laden Sie Apache neu, sodass die Änderungen wirksam werden:

      • sudo systemctl reload apache2

      Mit diesen Änderungen kann Certbot den richtigen VirtualHost-Block finden und ihn aktualisieren.

      Als Nächstes aktualisieren wir die Firewall, um den HTTPS-Datenverkehr zu ermöglichen.

      Schritt 3 — Zulassen von HTTPS durch die Firewall

      Wenn Sie die UFW-Firewall aktiviert haben, wie in den erforderlichen Anleitungen empfohlen, müssen Sie die Einstellungen anpassen, um den HTTPS-Datenverkehr zuzulassen. Bei der Installation registriert Apache einige verschiedene UFW-Anwendungsprofile. Wir können das Profil Apache Full nutzen, um sowohl HTTP- als auch HTTPS-Datenverkehr auf Ihrem Server zuzulassen.

      Um zu verifizieren, welche Art von Datenverkehr derzeit auf Ihrem Server erlaubt ist, können Sie Folgendes verwenden:

      Wenn Sie einem unserer Apache-Installationsleitfäden gefolgt sind, sollte Ihre Ausgabe ungefähr so aussehen, was bedeutet, dass derzeit nur HTTP-Datenverkehr auf Port 80 zulässig ist:

      Output

      Status: active To Action From -- ------ ---- OpenSSH ALLOW Anywhere Apache ALLOW Anywhere OpenSSH (v6) ALLOW Anywhere (v6) Apache (v6) ALLOW Anywhere (v6)

      Um zusätzlich den HTTPS-Datenverkehr einzulassen, lassen Sie das Profil „Apache Full“ zu und löschen Sie das redundante Profil „Apache“:

      • sudo ufw allow 'Apache Full'
      • sudo ufw delete allow 'Apache'

      Ihr Status sieht nun wie folgt aus:

      Output

      Status: active To Action From -- ------ ---- OpenSSH ALLOW Anywhere Apache Full ALLOW Anywhere OpenSSH (v6) ALLOW Anywhere (v6) Apache Full (v6) ALLOW Anywhere (v6)

      Sie können nun Certbot ausführen und Ihre Zertifikate abrufen.

      Schritt 4 — Abrufen eines SSL-Zertifikats

      Certbot bietet eine Vielzahl von Möglichkeiten, um SSL-Zertifikate über Plugins zu erhalten. Das Apache-Plugin kümmert sich um die Neukonfiguration von Apache und das Neuladen der Konfiguration bei Bedarf. Geben Sie Folgendes ein, um dieses Plugin zu verwenden:

      In diesem Skript müssen Sie eine Reihe von Fragen beantworten, um Ihr SSL-Zertifikat zu konfigurieren. Zunächst werden Sie nach einer gültigen E-Mail-Adresse gefragt. Diese E-Mail wird für Erneuerungsbenachrichtigungen und Sicherheitshinweise verwendet:

      Output

      Saving debug log to /var/log/letsencrypt/letsencrypt.log Plugins selected: Authenticator apache, Installer apache Enter email address (used for urgent renewal and security notices) (Enter 'c' to cancel): you@your_domain

      Nach dem Bereitstellen einer gültigen E-Mail-Adresse drücken Sie ENTER, um mit dem nächsten Schritt fortzufahren. Sie werden dann aufgefordert, zu bestätigen, ob Sie den Nutzungsbedingungen von Let’s Encrypt zustimmen. Sie können dies bestätigen, indem Sie A drücken und dann ENTER:

      - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
      Please read the Terms of Service at
      https://letsencrypt.org/documents/LE-SA-v1.2-November-15-2017.pdf. You must
      agree in order to register with the ACME server at
      https://acme-v02.api.letsencrypt.org/directory
      - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
      (A)gree/(C)ancel: A
      

      Als Nächstes werden Sie gefragt, ob Sie Ihre E-Mail mit der Electronic Frontier Foundation teilen möchten, um Nachrichten und andere Informationen zu erhalten. Wenn Sie ihren Inhalt nicht abonnieren möchten, geben Sie N ein. Andernfalls geben Sie Y ein. Drücken Sie anschließend ENTER, um mit dem nächsten Schritt fortzufahren.

      - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
      Would you be willing to share your email address with the Electronic Frontier
      Foundation, a founding partner of the Let's Encrypt project and the non-profit
      organization that develops Certbot? We'd like to send you email about our work
      encrypting the web, EFF news, campaigns, and ways to support digital freedom.
      - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
      (Y)es/(N)o: N
      

      Im nächsten Schritt werden Sie aufgefordert, Certbot darüber zu informieren, für welche Domänen Sie HTTPS aktivieren möchten. Die aufgelisteten Domänennamen werden automatisch aus Ihrer Konfiguration des virtuellen Apache-Hosts abgerufen. Aus diesem Grund müssen Sie sicherstellen, dass auf Ihrem virtuellen Host die richtigen Einstellungen für ServerName und ServerAlias konfiguriert sind. Wenn Sie HTTPS für alle aufgelisteten Domänennamen aktivieren möchten (empfohlen), können Sie die Eingabeaufforderung leer lassen und ENTER drücken, um fortzufahren. Wählen Sie andernfalls die Domänen aus, für die Sie HTTPS aktivieren möchten, indem Sie die entsprechende Nummer durch Kommas und/oder Leerzeichen getrennt auflisten und dann ENTER drücken.

      Which names would you like to activate HTTPS for?
      - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
      1: your_domain
      2: www.your_domain
      - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
      Select the appropriate numbers separated by commas and/or spaces, or leave input
      blank to select all options shown (Enter 'c' to cancel):
      

      Die Ausgabe sieht dann so aus:

      Obtaining a new certificate
      Performing the following challenges:
      http-01 challenge for your_domain
      http-01 challenge for www.your_domain
      Enabled Apache rewrite module
      Waiting for verification...
      Cleaning up challenges
      Created an SSL vhost at /etc/apache2/sites-available/your_domain-le-ssl.conf
      Enabled Apache socache_shmcb module
      Enabled Apache ssl module
      Deploying Certificate to VirtualHost /etc/apache2/sites-available/your_domain-le-ssl.conf
      Enabling available site: /etc/apache2/sites-available/your_domain-le-ssl.conf
      Deploying Certificate to VirtualHost /etc/apache2/sites-available/your_domain-le-ssl.conf
      

      Als Nächstes werden Sie aufgefordert, auszuwählen, ob der HTTP-Datenverkehr an HTTPS umgeleitet werden soll. In der Praxis bedeutet dies, dass jemand, der Ihre Website über unverschlüsselte Kanäle (HTTP) besucht, automatisch an die HTTPS-Adresse Ihrer Website umgeleitet wird. Wählen Sie 2, um die Umleitung zu aktivieren, oder 1, wenn Sie sowohl HTTP als auch HTTPS als separate Methoden für den Zugriff auf Ihre Website beibehalten möchten.

      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
      
      

      Nach diesem Schritt ist die Konfiguration von Certbot abgeschlossen, und Sie erhalten die letzten Anmerkungen zu Ihrem neuen Zertifikat, wo sich die generierten Dateien befinden und wie Sie Ihre Konfiguration mit einem externen Tool testen können, das die Authentizität Ihres Zertifikats analysiert:

      - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
      Congratulations! You have successfully enabled https://your_domain and
      https://www.your_domain
      
      You should test your configuration at:
      https://www.ssllabs.com/ssltest/analyze.html?d=your_domain
      https://www.ssllabs.com/ssltest/analyze.html?d=www.your_domain
      - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
      
      IMPORTANT NOTES:
       - Congratulations! Your certificate and chain have been saved at:
         /etc/letsencrypt/live/your_domain/fullchain.pem
         Your key file has been saved at:
         /etc/letsencrypt/live/your_domain/privkey.pem
         Your cert will expire on 2020-07-27. 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
      
      

      Ihr Zertifikat ist nun installiert und in die Konfiguration von Apache geladen. Versuchen Sie, Ihre Website mit https:// neu zu laden und beachten Sie den Sicherheitsindikator Ihres Browsers. Er sollte darauf hinweisen, dass Ihre Website ordnungsgemäß gesichert ist, normalerweise durch Einfügen eines Schlosssymbols in die Adressleiste.

      Mit dem SSL Labs Server-Test können Sie die Note Ihres Zertifikats überprüfen und detaillierte Informationen dazu aus der Sicht eines externen Dienstes abrufen.

      Im nächsten und letzten Schritt testen wir die automatische Erneuerungsfunktion von Certbot, die garantiert, dass Ihr Zertifikat vor dem Ablaufdatum automatisch erneuert wird.

      Schritt 5 – Überprüfen der automatischen Erneuerung von Certbot

      Zertifikate von Let’s Encrypt sind nur neunzig Tage gültig. Dies soll Benutzer dazu ermutigen, ihren Prozess zur Erneuerung von Zertifikaten zu automatisieren und sicherzustellen, dass missbrauchte Zertifikate oder gestohlene Schlüssel eher früher als später ablaufen.

      Das von uns installierte certbot-Paket kümmert sich um Erneuerungen, indem es ein Erneuerungsskript in /etc/cron.d einfügt, das von einem systemctl-Dienst namens certbot.timer verwaltet wird. Dieses Skript wird zweimal pro Tag ausgeführt und erneuert automatisch alle Zertifikate, die innerhalb von dreißig Tagen ablaufen.

      Um den Status dieses Dienstes zu überprüfen und sicherzustellen, dass er aktiv ist und ausgeführt wird, können Sie Folgendes verwenden:

      • sudo systemctl status certbot.timer

      Sie sehen eine Ausgabe, die dieser ähnelt:

      Output

      ● certbot.timer - Run certbot twice daily Loaded: loaded (/lib/systemd/system/certbot.timer; enabled; vendor preset: enabled) Active: active (waiting) since Tue 2020-04-28 17:57:48 UTC; 17h ago Trigger: Wed 2020-04-29 23:50:31 UTC; 12h left Triggers: ● certbot.service Apr 28 17:57:48 fine-turtle systemd[1]: Started Run certbot twice daily.

      Um den Erneuerungsprozess zu testen, können Sie mit certbot einen Probelauf durchführen:

      • sudo certbot renew --dry-run

      Wenn Sie keine Fehler sehen, sind Sie fertig. Bei Bedarf erneuert Certbot Ihre Zertifikate und lädt Apache neu, um die Änderungen zu übernehmen. Wenn der automatische Erneuerungsprozess jemals fehlschlägt, sendet Let’s Encrypt eine Nachricht an die von Ihnen angegebene E-Mail und warnt Sie, wenn Ihr Zertifikat bald abläuft.

      Zusammenfassung

      In diesem Lernprogramm haben Sie den Let’s Encrypt-Client Certbot installiert, ein SSL-Zertifikat für Ihre Domäne konfiguriert und installiert und bestätigt, dass der automatische Erneuerungsdienst von Certbot in systemctl aktiv ist. Wenn Sie weitere Fragen zur Verwendung von Certbot haben, ist die Dokumentation ein guter Ausgangspunkt.



      Source link