NGINX Unit is a dynamic application server, capable of running beside NGINX Plus and NGINX Open Source or standalone. Unit supports a RESTful JSON API, deploys configuration changes without service disruptions, and runs apps built with multiple languages and frameworks. Designed from scratch around the needs of your distributed applications, it lays the foundation for your service mesh.

Install nginx unit

CentOS
Unit repository:

[unit]
name=unit repo
baseurl=https://packages.nginx.org/unit/centos/$releasever/$basearch/
gpgcheck=0
enabled=1

Install (complete)

Viele Webserver und deren Webapplikation laufen ohne tiefgreifendere Konfigurationen. Dabei verpasst man die Chance sich und seine Besucher besser vor Angriffen zu schützen. Nur wenige Einstellungen erwarten eine wirklich tief gehende Kenntnis über deren Funktion und ermöglicht somit allen Admins recht einfach eine ordentlich robusten Webserver zu betreiben.

Header

In der Grundeinstellung posaunt der Nginx stets seine Versionsnummer raus. Das ist für Angreifer die einfachste Einladung und muss abgestellt werden. Mit der Option “server_tokens”, kann die Ausgabe gesteuert werden. Stellt daher den Servertoken auf “off”, damit wird der Header des Dienstes auf die Ausgabe “Nginx” reduziert. Die Version des Nginx kann man dennoch über Tools ermitteln, es erschwert nur die Erkennung und reduziert “DriveBy”-Angriffe.

Nichts scheint ominöser zu sein als der Umgang mit Zertifikaten. Ich erlebe im täglichen Umgang mit Zertifikaten, dass zu viele Administratoren daran verzweifeln, dabei sind Zertifikate sehr einfach aufgebaut und folgen einer simplen Struktur.

Ich möchte in dem Artikel nicht auf jedes Detail eingehen, es gibt auch Ecken an denen man berechtigterweise Verzweifelt. Den Bereich möchte ich mir und euch in diesem Beitrag ersparen. Der folgende Rundumschlag sollte aber jedem den Umgang mit X.509 Zertifikaten verdeutlichen und ein zwei Tipps mit auf den Weg geben, die den Umgang erleichtern und die Implementierung etwas sicherer gestalten können.

PHP hat in den letzten Jahren eine deutliche Wandlung vollzogen, um den Anforderungen an eine moderne Infrastrukturen mit gehen zu können. Früher lief PHP vornehmlich als Apache Modul und war damit an die Leistungsfähigkeit des Apaches gebunden. PHP ist nun, seit einigen Jahren, durch FPM stark skalierbar und lässt sich völlig unabhängig von einem bestimmten Webserver einsetzen.

Ich stelle euch in diesem Artikel den Aufbau des FPM 7.0 vor. Ich habe für den Umstieg vom Apache-PHP Modul auf php-fpm viele Artikel gelesen, keiner der von mir gefundenen Artikel war so rund, das ich schnell und eindeutig verstanden hatte, wie der Aufbau und die Funktion war. Daher war es mir wichtig diesen Artikel zu schreiben, damit für euch der Ein/Umstieg schnell, einfach und nachvollziehbar ist.

Viele Webserver und deren Webapplikation laufen ohne tiefgreifendere Konfigurationen. Dabei verpasst man die Chance sich und seine Besucher besser vor Angriffen zu schützen. Nur wenige Einstellungen erwarten eine wirklich tief gehende Kenntnis über deren Funktion und ermöglicht somit den meisten Admins recht einfach eine ordentlich robusten Webserver zu betreiben.

Die Konfigurationen sind in den Distributionen leider alle unterschiedlich strukturiert d.h. man sollte seinen Apache schon etwas kennen gelernt haben. Letztlich hat man eine Apache-Konfiguration, die z.B. bei Debian/Ubuntu unter /etc/apache2/apache2.conf liegt und unter RedHat/CentOS unter /etc/httpd/conf.d/httpd.conf. Dort sollten nur Apache relevante Einstellungen erfolgen, keine Modulkonfigurationen! Die Modulkonfigurationen wie z.B. TLS, Caching, FCGI usw. erfolgen in der Regel in den eigenen Konfigurationen. Doch nicht alle nötigen Einstellungen sind zwingen in diesen Dateien zu erfolgen, sondern können auch in einer VirtualHost speziell für eine (Sub)Domain hinterlegt werden. Wie ihr seht müsst ihr etwas flexibel sein und die jeweilige Konfiguration in eurem System suchen bzw. explizit dort setzen wo ihr sie benötigt.