In diesem Abschnitt wird die Konfiguration des Apache-Webservers beschrieben. kivitendo wird mittels FastCGI/FCGI ausgeführt.
Es ist empfehlenswert, SSL einzusetzen, um die Daten per HTTPS
verschlüsselt zwischen Browser und Webserver über das Netzwerk zu
übertragen. Eine Möglichkeit dazu ist das Erstellen eines self-signed
SSL Zertifikates, was unter Debian/Ubuntu durch Installieren des Pakets
ssl-cert geschehen kann.
Der Zugriff auf den Installationspfad von kivitendo im Dateisystem
muss in der Apache Webserverkonfigurationsdatei eingestellt werden,
welche beim Starten des Webservers eingelesen wird. Wird SSL/HTTPS
eingesetzt, so ist dies die Datei default-ssl.conf,
für unverschlüsseltes HTTP ist es die Datei
000-default.conf.
Bitte konsultieren Sie die Dokumentation des Apache-Webservers und Ihres Betriebssystems. Es kann erforderlich sein, das SSL-Modul und die Webserverkonfigurationsdatei zu aktivieren:
a2enmod ssl a2ensite default-ssl
Unter Fedora und openSUSE müssen weiterhin in der Firewall die Ports 80 (HTTP) bzw. 443 (HTTPS) geöffnet werden.
Mit FastCGI wird der kivitendo-Programmcode beim Start des Webservers einmal geladen und danach wird nur die eigentliche Programmlogik ausgeführt.
Zuerst muss das FastCGI-Modul aktiviert werden. Dies kann unter Debian/Ubuntu z.B. mit folgendem Befehl geschehen:
a2enmod fcgid
Die Konfiguration für die Verwendung von kivitendo mit FastCGI
erfolgt durch Einfügen von Alias-
und Directory-Direktiven. Dabei wird zwischen
dem Installationspfad von kivitendo im Dateisystem
("/path/to/kivitendo-erp") und der URL
unterschieden, unter der kivitendo im Webbrowser erreichbar ist
("/url/for/kivitendo-erp").
Folgender Konfigurationsschnipsel funktioniert mit mod_fcgid:
AliasMatch ^/url/for/kivitendo-erp/[^/]+\.pl /path/to/kivitendo-erp/dispatcher.fcgi Alias /url/for/kivitendo-erp/ /path/to/kivitendo-erp/ FcgidMaxRequestLen 10485760 <Directory /path/to/kivitendo-erp> AllowOverride All Options ExecCGI Includes FollowSymlinks Require all granted </Directory> <DirectoryMatch /path/to/kivitendo-erp/users> Require all denied </DirectoryMatch>
Hierdurch wird nur ein zentraler Dispatcher gestartet. Alle Zugriffe auf die einzelnen Scripte werden auf diesen umgeleitet. Dadurch, dass zur Laufzeit öfter mal Scripte neu geladen werden, gibt es hier kleine Performance-Einbußen.
Seit mod_fcgid-Version 2.3.6 gelten sehr kleine Grenzen für die maximale Größe eines Requests. Mit folgender Zeile wird diese Grenze hochgesetzt:
FcgidMaxRequestLen 10485760
Aufgrund von aktuellen (Mitte 2020) Sicherheitswarnungen für git basierte Webanwendungen ist die mitausgelieferte .htaccess restriktiver geworden und verhindert somit das Auslesen von git basierten Daten. Für debian/ubuntu muss das Modul mod_rewrite einmalig so aktiviert werden:
a2enmod rewrite
Alternativ und für Installationen ohne Apache ist folgender Artikel interessant: git-lücke. Anstelle des dort beschriebenen DirectoryMatch für Apache2 würden wir etwas weitergehend auch noch das Verzeichnis config miteinbeziehen sowie ferner auch die Möglichkeit nicht ausschließen, dass es in Unterverzeichnissen auch noch .git Repositories geben kann. Die Empfehlung für Apache 2.4 wäre damit:
<DirectoryMatch "/(\.git|config)/">
Require all denied
</DirectoryMatch>
Für einen deutlichen Sicherheitsmehrwert sorgt die Ausführung von kivitendo nur über https-verschlüsselten Verbindungen, sowie weiteren Zusatzmassnahmen, wie beispielsweise Basic Authentication. Die Konfigurationsmöglichkeiten sprengen allerdings den Rahmen dieser Anleitung, hier ein Hinweis auf einen entsprechenden Foreneintrag (Stand Sept. 2015) und einen aktuellen (Stand Mai 2017) SSL-Konfigurations-Generator.
Aufgrund des OpenSource Charakters ist kivitendo nicht "out of the box" sicher. Organisatorisch empfehlen wir hier die enge Zusammenarbeit mit einem kivitendo Partner der auch in der Lage ist weiterführende Fragen in Bezug auf Datenschutz und Datensicherheit zu beantworten. Unabhängig davon empfehlen wir im Webserver Bereich die Aktivierung und Konfiguration des Moduls modsecurity für den Apache2, damit XSS und SQL-Injections verhindert werden.
Als Idee hierfür sei dieser Blog-Eintrag genannt: Test Apache2 modsecurity for SQL Injection.