suEXEC-Unterstützung

Die Funktion suEXEC bietet Benutzern des Apache HTTP Servers die Möglichkeit, CGI- und SSI-Programme unter anderen Benutzerkennungen als der Benutzerkennung des aufrufenden Webservers auszuführen.

Normalerweise wird ein CGI- oder SSI-Programm unter demselben Benutzer ausgeführt, unter dem auch der Webserver läuft.

Richtig eingesetzt, kann diese Funktion die Sicherheitsrisiken erheblich verringern, die damit verbunden sind, dass Benutzer private CGI- oder SSI-Programme entwickeln und ausführen können.

Wenn suEXEC jedoch nicht richtig konfiguriert ist, kann es eine Reihe von Problemen verursachen und möglicherweise neue Sicherheitslücken auf Ihrem Computer schaffen.
Wenn Sie mit der Verwaltung von Setuid-Root-Programmen und den damit verbundenen Sicherheitsproblemen nicht vertraut sind, empfehlen wir Ihnen dringend, die Verwendung von suEXEC nicht in Betracht zu ziehen.

Bevorbemerkungen

Bevor Sie sich kopfüber in dieses Dokument stürzen, sollten Sie sich darüber im Klaren sein, dass bestimmte Annahmen über Sie und die Umgebung, in der Sie suexec verwenden werden, getroffen werden.

Zunächst wird davon ausgegangen, dass Sie ein von UNIX abgeleitetes Betriebssystem verwenden, das setuid- und setgid-Operationen unterstützt.

Alle Befehlsbeispiele sind in diesem Zusammenhang angegeben.
Andere Plattformen, sofern sie suEXEC unterstützen, können sich in ihrer Konfiguration unterscheiden.

Zweitens wird vorausgesetzt, dass Sie mit einigen grundlegenden Konzepten der Sicherheit Ihres Computers und seiner Verwaltung vertraut sind.

Dazu gehört ein Verständnis der setuid/setgid-Operationen und der verschiedenen Auswirkungen, die sie auf Ihr System und dessen Sicherheitsniveau haben können.

Drittens wird davon ausgegangen, dass Sie eine unveränderte Version des suEXEC-Codes verwenden.

Der gesamte Code von suEXEC wurde von den Entwicklern und zahlreichen Beta-Testern sorgfältig geprüft und getestet.
Es wurden alle Vorkehrungen getroffen, um eine einfache, aber sichere Codebasis zu gewährleisten. Änderungen an diesem Code können zu unerwarteten Problemen und neuen Sicherheitsrisiken führen.
Es wird dringend empfohlen, den suEXEC-Code nicht zu verändern, es sei denn, Sie kennen sich mit den Besonderheiten der Sicherheitsprogrammierung aus und sind bereit, Ihre Arbeit dem Apache HTTP Server-Entwicklungsteam zur Prüfung vorzulegen.

Viertens und letztens hat das Entwicklungsteam des Apache HTTP Servers beschlossen, suEXEC NICHT in die Standardinstallation des Apache httpd aufzunehmen.

Aus diesem Grund erfordert die Konfiguration von suEXEC vom Administrator eine sorgfältige Beachtung der Details.
Nachdem die verschiedenen Einstellungen für suEXEC gebührend berücksichtigt wurden, kann der Administrator suEXEC durch normale Installationsmethoden installieren.
Die Werte für diese Einstellungen müssen vom Administrator sorgfältig festgelegt und spezifiziert werden, um die Systemsicherheit während der Nutzung der suEXEC-Funktionalität zu gewährleisten.
Durch diesen detaillierten Prozess hoffen wir, die Installation von suEXEC auf diejenigen zu beschränken, die sorgfältig und entschlossen genug sind, es zu benutzen.

Sind Sie noch bei uns? Ja? Dann ist ja gut.

Machen wir weiter!

suEXEC-Sicherheitsmodell

Bevor wir mit der Konfiguration und Installation von suEXEC beginnen, werden wir zunächst das Sicherheitsmodell besprechen, das Sie implementieren wollen.

Auf diese Weise können Sie besser verstehen, was genau in suEXEC vor sich geht und welche Vorkehrungen getroffen werden, um die Sicherheit Ihres Systems zu gewährleisten.

suEXEC basiert auf einem Setuid-"Wrapper"-Programm, das vom Apache-HTTP-Hauptserver aufgerufen wird.

Dieser Wrapper wird aufgerufen, wenn eine HTTP-Anfrage für ein CGI- oder SSI-Programm gestellt wird, das der Administrator zur Ausführung unter einer anderen Benutzerkennung als der des Hauptservers bestimmt hat.
Bei einer solchen Anfrage übergibt der Apache httpd dem suEXEC-Wrapper den Namen des Programms sowie die Benutzer- und Gruppen-IDs, unter denen das Programm ausgeführt werden soll.

Der Wrapper wendet dann den folgenden Prozess an, um Erfolg oder Misserfolg festzustellen - wenn eine dieser Bedingungen fehlschlägt, protokolliert das Programm den Fehler und beendet sich mit einer Fehlermeldung, andernfalls wird es fortgesetzt:

Ist der Benutzer, der diesen Wrapper ausführt, ein gültiger Benutzer dieses Systems?
- Damit soll sichergestellt werden, dass der Benutzer, der den Wrapper ausführt, auch wirklich ein Benutzer des Systems ist.
Wurde der Wrapper mit der richtigen Anzahl von Argumenten aufgerufen?
- Der Wrapper wird nur ausgeführt, wenn er die richtige Anzahl von Argumenten erhält.
- Das richtige Argumentenformat ist dem Apache HTTP Server bekannt.
- Wenn der Wrapper nicht die richtige Anzahl von Argumenten erhält, wurde er entweder gehackt, oder es stimmt etwas mit dem suEXEC-Teil Ihrer Apache httpd-Binärdatei nicht.
Ist dieser gültige Benutzer berechtigt, den Wrapper auszuführen?
- Ist dieser Benutzer der Benutzer, der diesen Wrapper ausführen darf?
- Nur ein Benutzer (der Apache-Benutzer) ist berechtigt, dieses Programm auszuführen.
Hat das Ziel-CGI- oder SSI-Programm eine unsichere hierarchische Referenz?
- Enthält der Pfad des Ziel-CGI- oder SSI-Programms ein führendes '/' oder einen '..'-Rückverweis?
- Diese sind nicht erlaubt; das Ziel-CGI/SSI-Programm muss sich innerhalb der Dokumenten-Root von suEXEC befinden (siehe --with-suexec-docroot=DIRunten).
Ist der Zielbenutzername gültig? Existiert der Zielbenutzer?
Ist der Zielgruppenname gültig? Gibt es die Zielgruppe?
Ist der Zielbenutzer KEIN Superuser? suEXEC erlaubt es rootnicht, CGI/SSI-Programme auszuführen.
Liegt die Ziel-Benutzerkennung ÜBER der Mindest-ID-Nummer? Die minimale Benutzer-ID-Nummer wird während der Konfiguration angegeben.
- Damit können Sie die niedrigstmögliche Benutzerkennung festlegen, die für die Ausführung von CGI/SSI-Programmen zugelassen ist.
- Dies ist nützlich, um "System"-Konten zu sperren.
Ist die Zielgruppe NICHT die Superuser-Gruppe? Zur Zeit erlaubt suEXEC der Root-Gruppenicht, CGI/SSI-Programme auszuführen.
Liegt die Zielgruppen-ID ÜBER der Mindest-ID-Nummer? Die minimale Gruppen-ID-Nummer wird bei der Konfiguration angegeben.
- Damit können Sie die niedrigste mögliche Gruppennummer festlegen, die für die Ausführung von CGI/SSI-Programmen zugelassen ist.
- Dies ist nützlich, um "System"-Gruppen auszusperren.
Kann der Wrapper erfolgreich zum Zielbenutzer und zur Zielgruppe werden?
- Hier wird das Programm über setuid- und setgid-Aufrufe zum Zielbenutzer und zur Zielgruppe.
Die Gruppenzugriffsliste wird ebenfalls mit allen Gruppen initialisiert, in denen der Benutzer Mitglied ist.
Können wir in das Verzeichnis wechseln, in dem sich das Ziel-CGI/SSI-Programm befindet? Wenn er nicht existiert, kann er auch keine Dateien enthalten.
- Wenn wir das Verzeichnis nicht wechseln können, kann es genauso gut nicht existieren.
Befindet sich das Verzeichnis innerhalb des httpd-Webspace?
- Wenn sich die Anfrage auf einen regulären Teil des Servers bezieht, befindet sich das angeforderte Verzeichnis im Dokumentenstamm von suEXEC?
- Handelt es sich bei der Anfrage um ein UserDir, befindet sich das angeforderte Verzeichnis innerhalb des Verzeichnisses, das als Userdir von suEXEC konfiguriert ist (siehe Konfigurationsoptionen von suEXEC)?
Ist das Verzeichnis für andere Personen NICHT beschreibbar?
- Wir wollen das Verzeichnis nicht für andere zugänglich machen; nur der Eigentümer kann den Inhalt des Verzeichnisses ändern.
Existiert das Ziel-CGI/SSI-Programm? Wenn es sie nicht gibt, kann sie auch nicht ausgeführt werden.
Ist das Ziel-CGI/SSI-Programm NICHT für andere Personen schreibbar?
- Wir wollen niemandem außer dem Eigentümer die Möglichkeit geben, das CGI/SSI-Programm zu ändern.
Ist das Ziel-CGI/SSI-Programm NICHT setuid oder setgid? Wir wollen keine Programme ausführen, die dann wieder unsere UID/GID ändern.
Ist der Zielbenutzer/die Zielgruppe derselbe/dieselbe wie der Benutzer/die Gruppe des Programms?
- Ist der Benutzer der Eigentümer der Datei?
Können wir die Prozessumgebung erfolgreich reinigen, um einen sicheren Betrieb zu gewährleisten?
- suEXEC bereinigt die Umgebung des Prozesses, indem es einen sicheren Ausführungspfad (definiert während der Konfiguration) einrichtet und nur die Variablen durchlässt, deren Namen in der Liste der sicheren Umgebung (ebenfalls während der Konfiguration erstellt) aufgeführt sind.
Können wir erfolgreich das Ziel-CGI/SSI-Programm werden und ausführen? Hier endet suEXEC und das Ziel-CGI/SSI-Programm beginnt.

Dies ist die Standardoperation des Sicherheitsmodells des suEXEC-Wrappers.

Es ist etwas streng und kann neue Einschränkungen und Richtlinien für das CGI/SSI-Design mit sich bringen, aber es wurde sorgfältig Schritt für Schritt unter Berücksichtigung der Sicherheit entwickelt.

Weitere Informationen darüber, wie dieses Sicherheitsmodell Ihre Möglichkeiten in Bezug auf die Serverkonfiguration einschränken kann und welche Sicherheitsrisiken mit einer korrekten suEXEC-Einrichtung vermieden werden können, finden Sie im Abschnitt "Vorsicht vor dem Jabberwock" in diesem Dokument.

Konfigurieren und Installieren von suEXEC

Hier beginnt der Spaß.

suEXEC-Konfigurationsoptionen

--enable-suexec: Diese Option aktiviert die suEXEC-Funktion, die standardmäßig nie installiert oder aktiviert ist.

Mindestens eine Option --with-suexec-xxxxx muss zusammen mit der Option --enable-suexec angegeben werden, damit APACI Ihre Anfrage zur Verwendung des suEXEC-Features akzeptiert.

--mit-suexec-bin=PATH: Der Pfad zum Suexec-Binary muss aus Sicherheitsgründen im Server fest codiert sein.

Verwenden Sie diese Option, um den Standardpfad außer Kraft zu setzen.
z .B. --with-suexec-bin=/usr/sbin/suexec

--with-suexec-caller=UID: Der Benutzername, unter dem httpd normalerweise läuft.

Dies ist der einzige Benutzer, der den suEXEC-Wrapper ausführen darf.

--with-suexec-userdir=DIR: Definieren Sie das Unterverzeichnis unter den Home-Verzeichnissen der Benutzer, auf das suEXEC Zugriff haben soll.

Alle ausführbaren Dateien in diesem Verzeichnis können von suEXEC als Benutzer ausgeführt werden und sollten daher "sichere" Programme sein.
Wenn Sie eine "einfache" UserDir-Direktive(d.h.
eine ohne "*") verwenden, sollte diese auf den gleichen Wert gesetzt werden.
suEXEC wird nicht richtig funktionieren, wenn die UserDir-Direktive auf einen Ort zeigt, der nicht mit dem Home-Verzeichnis des Benutzers übereinstimmt, auf das in der passwd-Datei verwiesen wird.
Der Standardwert ist "public_html".
Wenn Sie virtuelle Hosts haben, für die jeweils ein anderes UserDir gilt, müssen Sie diese so definieren, dass sie sich alle in einem übergeordneten Verzeichnis befinden; benennen Sie dieses übergeordnete Verzeichnis dann hier. Wenn dies nicht richtig definiert ist, werden "~userdir"-cgi-Anfragen nicht funktionieren!

--with-suexec-docroot=DIR: als DocumentRoot-Satz für httpd definieren.

Dies ist die einzige Hierarchie (abgesehen von UserDirs), die für das suEXEC-Verhalten verwendet werden kann.
Das Standardverzeichnis ist der --datadir-Wert mit dem Suffix"/htdocs", d . h.
wenn Sie mit"--datadir=/home/apache" konfigurieren, wird das Verzeichnis"/home/apache/htdocs" als DocumentRoot für den suEXEC-Wrapper verwendet.

--mit-suexec-uidmin=UID: Definieren Sie dies als die niedrigste UID, die ein Zielbenutzer für suEXEC sein darf.

Für die meisten Systeme ist 500 oder 100 üblich.
Der Standardwert ist 100.

--mit-suexec-gidmin=GID: Definieren Sie dies als die niedrigste GID, die eine Zielgruppe für suEXEC sein darf.

Für die meisten Systeme ist 100 üblich und wird daher als Standardwert verwendet.

--with-suexec-logfile=FILE: Dies definiert den Dateinamen, in dem alle suEXEC-Transaktionen und Fehler protokolliert werden (nützlich für Auditing- und Debugging-Zwecke).

Standardmäßig heißt die Logdatei"suexec_log" und befindet sich in Ihrem Standard-Logfile-Verzeichnis(--logfiledir).

--mit-suexec-sicherheitspfad=PATH: Definieren Sie eine sichere PATH-Umgebung, die an die ausführbaren CGI-Programme übergeben wird.

Der Standardwert ist "/usr/local/bin:/usr/bin:/bin".

Kompilieren und Installieren des suEXEC-Wrappers

Wenn Sie die suEXEC-Funktion mit der Option --enable-suexec aktiviert haben, wird das suexec-Binary (zusammen mit httpd selbst) automatisch erstellt, wenn Sie den Befehl make ausführen.

Nachdem alle Komponenten erstellt worden sind, können Sie den Befehl make install ausführen, um sie zu installieren.

Das Binärabbild suexec wird in dem Verzeichnis installiert, das mit der Option --sbindir festgelegt wurde.
Das Standardverzeichnis ist "/usr/local/apache2/bin/suexec".

Bitte beachten Sie, dass Sie für den Installationsschritt root-Rechte benötigen.

Damit der Wrapper die Benutzer-ID setzen kann, muss er als Eigentümer root installiert sein und das Ausführungsbit setuserid für Dateimodi gesetzt haben.

Paranoide Berechtigungen festlegen

Obwohl der suEXEC-Wrapper prüft, ob sein Aufrufer der richtige Benutzer ist, wie mit der Konfigurationsoption --with-suexec-caller angegeben, besteht immer die Möglichkeit, dass ein System- oder Bibliotheksaufruf, den suEXEC vor dieser Prüfung verwendet, auf Ihrem System ausgenutzt werden kann.

Um dem entgegenzuwirken, und weil es generell die beste Vorgehensweise ist, sollten Sie die Dateisystemberechtigungen verwenden, um sicherzustellen, dass nur die Gruppe, unter der httpd läuft, suEXEC ausführen darf.

Wenn Ihr Webserver zum Beispiel so konfiguriert ist, dass er als:

Benutzer wwwGruppe webgroup

und suexec unter "/usr/local/apache2/bin/suexec" installiert ist, sollten Sie folgendes ausführen:

chgrp webgroup /usr/local/apache2/bin/suexec

chmod 4750 /usr/local/apache2/bin/suexec

Damit wird sichergestellt, dass nur die Gruppe, unter der httpd läuft, auch den suEXEC-Wrapper ausführen kann.

Aktivieren und Deaktivieren von suEXEC

Beim Start von httpd sucht er nach der Datei suexec in dem durch die Option --sbindir definierten Verzeichnis (Standard ist "/usr/local/apache/sbin/suexec").

Wenn httpd einen ordnungsgemäß konfigurierten suEXEC-Wrapper findet, gibt er die folgende Meldung in das Fehlerprotokoll ein:

[notice] suEXEC-Mechanismus aktiviert (Wrapper: /path/to/suexec)

Wenn Sie diese Meldung beim Start des Servers nicht sehen, findet der Server das Wrapper-Programm höchstwahrscheinlich nicht dort, wo er es erwartet, oder die ausführbare Datei ist nicht als setuid root installiert.

Wenn Sie den suEXEC-Mechanismus zum ersten Mal aktivieren wollen und bereits ein Apache HTTP Server läuft, müssen Sie httpd beenden und neu starten.

Ein Neustart mit einem einfachen HUP- oder USR1-Signal reicht nicht aus.

Wenn Sie suEXEC deaktivieren wollen, sollten Sie httpd beenden und neu starten, nachdem Sie die suexec-Datei entfernt haben.

Verwendung von suEXEC

Anfragen für CGI-Programme rufen den suEXEC-Wrapper nur auf, wenn sie für einen virtuellen Host bestimmt sind, der eine SuexecUserGroup-Direktive enthält, oder wenn sie von mod_userdir verarbeitet werden.

Virtuelle Hosts:

Eine Möglichkeit, den suEXEC-Wrapper zu verwenden, ist die Direktive SuexecUserGroup in den VirtualHost-Definitionen. Wenn diese Direktive auf Werte gesetzt wird, die sich von der Benutzer-ID des Hauptservers unterscheiden, werden alle Anfragen für CGI-Ressourcen als der für diesen <VirtualHost> definierte Benutzer und die Gruppe ausgeführt . Wenn diese Direktive für einen <VirtualHost> nicht angegeben wird, wird die Benutzer-ID des Hauptservers angenommen.

Benutzerverzeichnisse:

Anfragen, die von mod_userdir verarbeitet werden, rufen den suEXEC-Wrapper auf, um CGI-Programme unter der Benutzerkennung des angeforderten Benutzerverzeichnisses auszuführen. Die einzige Voraussetzung für diese Funktion ist, dass die CGI-Ausführung für den Benutzer aktiviert ist und dass das Skript die oben genannten Sicherheitsüberprüfungen erfüllt. Siehe auch die Option --with-suexec-userdir zur Kompilierzeit.

Fehlersuche bei suEXEC

Der suEXEC-Wrapper schreibt die Log-Informationen in die Datei, die mit der Option --with-suexec-logfilewie oben angegeben definiert wurde.

Wenn Sie der Meinung sind, dass Sie den Wrapper richtig konfiguriert und installiert haben, sehen Sie sich dieses Protokoll und das error_log des Servers an, um festzustellen, wo Sie möglicherweise in die Irre gegangen sind.

Vorsicht vor dem Jabberwock: Warnungen und Beispiele

HINWEIS: Dieser Abschnitt ist möglicherweise nicht vollständig.

Es gibt ein paar interessante Punkte bezüglich des Wrappers, die zu Einschränkungen bei der Servereinrichtung führen können.

Bitte überprüfen Sie diese, bevor Sie "Bugs" in Bezug auf suEXEC einreichen.

suEXEC Punkte von Interesse

Einschränkungen der Hierarchie Aus Sicherheits- und Effizienzgründen müssen alle suEXEC-Anfragen entweder innerhalb eines Dokumentstammes der obersten Ebene für VirtualHost-Anfragen oder eines persönlichen Dokumentstammes der obersten Ebene für Userdir-Anfragen bleiben.
Wenn Sie z.B.
vier VirtualHosts konfiguriert haben, müssen Sie die Dokument-Roots all Ihrer VHosts von einer Haupt-Httpd-Dokumentenhierarchie aus strukturieren, um die Vorteile von suEXEC für VirtualHosts zu nutzen. (Beispiel in Kürze).
die Umgebungsvariable PATH von suEXEC Es kann gefährlich sein, diese Variable zu ändern.
Stellen Sie sicher, dass jeder Pfad, den Sie hier angeben, ein vertrauenswürdiges Verzeichnis ist.
Sie wollen nicht, dass jemand aus der ganzen Welt einen Trojaner auf sie loslässt.
Ändern des suEXEC-Codes Auch hier kann es zu großen Problemen kommen, wenn Sie dies versuchen, ohne zu wissen, was Sie tun.
Halten Sie sich davon fern, wenn es irgend möglich ist.

Apache2, PHP-FPM, Suexec

Nach dem Wechsel auf Ubuntu 16.04 LTS sollte eine weitere Sicherheitsfunktion genutzt werden.

Jede PHP-Webseite soll als eigenständiger Benutzer ausgeführt werden, damit ein Einbruch nicht die übrigen Webseiten betrifft.

Ziele

Folgende Ziele werden umgesetzt

Jede Webseite nutzt einen PHP-Prozess mit eigener Benutzerkennung.
Jede Webseite nutzt einen eigenen Benutzer für die Dateien.

Erforderliche Pakete

Folgende Pakete werden benötigt

libapache2-mod-fastcgi
php-fpm
apache2-suexec-custom

Diese Pakete werden nicht mehr benötigt

libapache2-mod-php
libapache2-mod-fcgid

Umsetzung

Benutzer hinzufügen

Für den virtuellen Host wird eine neue Gruppe und ein neuer Benutzer erzeugt:

	addgroup --system www-drupal8 adduser --system --home /home/www-drupal8 www-drupal8

FPM-Pool konfigurieren

PHP-FPM (FastCGI Process Manager) sorgt für den Start und die Überwachung der PHP-Prozesse, die der Apache über die Fast-CGI-Schnittstelle anspricht.

Im Verzeichnis pool.d wird festgelegt, unter welcher Benutzerkennung der Prozess läuft.
Eine zusätzliche Datei /etc/php/7.1/fpm/pool.d/drupal8.conf stellt den weiteren Pool bereit.

/etc/php/7.1/fpm/pool.d/drupal8.conf
	[drupal8] user = www-drupal8 group = www-drupal8 listen = /run/php/php7.1-fpm-drupal8.sock listen.owner = www-data listen.group = www-data pm = dynamic pm.max_children = 5 pm.start_servers = 2 pm.min_spare_servers = 1 pm.max_spare_servers = 3

Apache konfigurieren

Etwas umständlich ist der Webserver zu konfigurieren. Über eine neue Datei /etc/apache2/conf-available/php7-fcgi.conf wird die Zuordnung der PHP-CGI-Prozesse gesteuert.

/etc/apache2/conf-available/php7-fcgi.conf
	<IfModule mod_fastcgi.c> # Common Action php7-fcgi /php7-fcgi Alias /php7-fcgi /usr/lib/cgi-bin/php7-fcgi FastCgiExternalServer /usr/lib/cgi-bin/php7-fcgi -socket /var/run/php/php7.1-fpm.sock -pass-header Authorization <Location /php7-fcgi> Require all granted </Location> # Drupal 8 Action php7-drupal8 /php7-drupal8 Alias /php7-drupal8 /usr/lib/cgi-bin/php7-drupal8 FastCgiExternalServer /usr/lib/cgi-bin/php7-drupal8 -socket /run/php/php7.1-fpm-drupal8.sock -pass-header Authorization <Location /php7-drupal8> Require all granted </Location> </IfModule>

Anschließend wird der virtuellen Host in der Datei /etc/apache2/sites-available/100-drupal8.conf eingestellt.

Wichtig sind die Anweisungen SuexecUserGroup zum Wechsel des Benutzers des Apaches und AddHandler zur Zuweisung des richtigen PHP-Prozesses.

/etc/apache2/sites-available/100-drupal8.conf
	<VirtualHost *:443> DocumentRoot /srv/www/vhosts/drupal8 ServerName drupal8 SuexecUserGroup www-drupal8 www-drupal8 AddHandler php7-drupal8 .php Include /etc/apache2/includes/ssl ServerAdmin webmaster@qwirl.eu CustomLog /var/log/apache2/drupal8-access_log combined ErrorLog /var/log/apache2/drupal8-error_log <Directory /srv/www/vhosts/drupal8> AllowOverride All Options FollowSymLinks Require all granted </Directory> </VirtualHost>

Damit Suexec das richtige DocumentRoot-Verzeichnis kennt, wird es in der Datei /etc/apache2/suexec/www-drupal8 konfiguriert.

/etc/apache2/suexec/www-drupal8
	/srv/www/vhost/drupal8 public_html/cgi-bin The first two lines contain the suexec document root and the suexec userdir suffix. If one of them is disabled by prepending a # character, suexec will refuse the corresponding type of request. This config file is only used by the apache2-suexec-custom package. See the suexec man page included in the package for more details.

Dienste konfigurieren und starten

	a2enconf php7-fcgi a2ensite 100-drupal8 systemctl enable php7.1-fpm systemctl start php7.1-fpm systemctl restart apache2

Zusand überwachen

# systemctl status php7.1-fpm

● php7.1-fpm.service - The PHP 7.1 FastCGI Process Manager
  Loaded: loaded (/lib/systemd/system/php7.1-fpm.service; enabled; vendor preset: enabled)
  Active: active (running) since Sa 2017-01-21 08:46:08 CET; 2h 17min ago
    Docs: man:php-fpm7.1(8)
 Process: 18645 ExecReload=/bin/kill -USR2 $MAINPID (code=exited, status=0/SUCCESS)
Main PID: 11765 (php-fpm7.1)
  Status: "Processes active: 0, idle: 11, Requests: 3247, slow: 0, Traffic: 0.5req/sec"
  CGroup: /system.slice/php7.1-fpm.service
          ├─11765 php-fpm: master process (/etc/php/7.1/fpm/php-fpm.conf)
          ├─18648 php-fpm: pool drupal8
          ├─18649 php-fpm: pool drupal8
          ├─18907 php-fpm: pool www
          ├─19236 php-fpm: pool drupal8
          ├─20705 php-fpm: pool www
          └─30262 php-fpm: pool www