Artikel mit Tag webserver

NGINX - Webserver, Load Balancer und Proxy

NGINX ist neben Apache einer der bekanntesten Webserver. Allerdings kann das Tool mehr als nur ein schlichter Webserver sein. Reverse Proxy, Load Balancer, Mail Proxy oder HTTP cache Server sind ein paar wenige Funktionen die Nginx beherrscht.

Ich möchte euch heute ein paar Beispiele zu einzelnen Funktionen zeigen. Den Anfang macht logischerweise die Installation. Als System verwende ich einen Ubuntu 20.04 LTS Server.

 

Nginx

 

Installation Nginx unter Ubuntu/Debian

Die Installation der frei verfügbaren Version (Die kommerzielle Variante nennt sich Nginx Plus) erfolgt über das Nginx Repository.

sudo wget https://nginx.org/keys/nginx_signing.key

sudo apt-key add nginx_signing.key

sudo nano /etc/apt/sources.list.d/nginx.list

  deb https://nginx.org/packages/mainline/ubuntu/ focal nginx
  deb-src https://nginx.org/packages/mainline/ubuntu/ focal nginx
              
sudo apt install nginx

sudo systemctl is-enabled nginx.service

sudo systemctl enable nginx

Nach der Installation erfolgt eine schnelle Kontrolle.

ss -ltn
ubuntu:~$ curl -I http://127.0.0.2

HTTP/1.1 200 OK
Server: nginx/1.19.6
Date: Thu, 17 Dec 2020 22:20:49 GMT
Content-Type: text/html
Content-Length: 612

Nginx selbst kompilieren

Es besteht auch die Möglichkeit, das Nginx Paket selbst zu kompilieren. Dies wird dann nötig, wenn Pakete benötigt werden, die in der Standardvariante nicht enthalten sind. Die war zum Beispiel bei der Verwendung von GeoIP oder LibreSSL mal bzw. ist noch so.

Mit dem folgenden Befehl können die installierten Module eingesehen werden.

Nginx –V

In der Standardinstallation sollte hier das Modul --add-dynamic-module=/build/nginx-5J5hor/nginx-1.18.0/debian/modules/http-geoip2 angezeigt werden. D.h. das eingangs erwähnte Geo IP Modul wird hier bereits geladen.

Einen eigenen Nginx Server unter Debian/Ubuntu einrichten

Nach einer erfolgreichen Installation zeigt Nginx eine Standardseite an. Diese kann gelöscht oder zusätzlich eine eigene virtuelle Seite angelegt werden. Auf einer IP können so mehrere Webseiten gehostet werden.

Folgende Struktur bietet sich unter Ubuntu an:

Konfiguration der einzelnen virtuellen Server.

/etc/nginx/sites-available/xyz

Momentan aktive Server wobei es sich hier um einen Symlink handelt.

/etc/nginx/sites-enabled/xyz

Schritt für Schritt heißt dies für einen Server welche auf Port 80 lauscht:

#config anlegen
touch /etc/nginx/sites-available/itrig

#config schreiben
nano /etc/nginx/sites-available/itrig

server {

        listen 80 default_server;    

        # Make site accessible from http://localhost/

        server_name localhost;
        location / {
            root /usr/share/nginx/html;
            index index.html index.htm;
        }
}

#aktiv setzen
ln -s /etc/nginx/sites-available/itrig /etc/nginx/sites-enabled/itrig

Konfiguration überprüfen

nginx –t

Neustart der Konfiguration mit

#lädt nur die neue Konfiguration
nginx –s reload

oder

sudo systemctl reload nginx


Nginx als Loadbalancer verwenden

Neben der reinen Webserverfunktion bietet NGINX die Möglichkeit den Server, als Loadbalancer zu betreiben. Da heißt der Server sorgt für Ausfallsicherheit bzw. Leistung von Webanwendungen, in dem er die Last verteilt. Vorstellen kann man sich dies wie einen Haupthändler, welcher Daten unter verteilt.

LoadbalancerNginx bietet mehrere Varianten an, wie diese Verteilung geschehen kann.

Round Robin

Das bekannteste dürfte das Round Robin Verfahren sein. Es wird eine Liste von Servern durchgearbeitet und die Last nach und nach verteilt. Ist die Liste zu Ende, fängt der Server wieder am Anfang an.

Im unteren Beispiel werden 3 Server in der Gruppe "itrigloadbalancer" zusammengefasst und der Webserver geht diese Liste nach und nach durch. Unterstützt werden die Protokolle HTTP, HTTPS, FastCGI, uwsgi, SCGI, memcached, und gRPC.

http {
    upstream itrigloadbalancer {
        server srv1.example.com;
        server srv2.example.com;
        server srv3.example.com;
    }

    server {
        listen 80;

        location / {
            proxy_pass http://itrig.de;
        }
    }
}

Least Connected

Eine weitere Lastverteilung ist das Least-Connected-Verfahren. Hier wird auf die aktiven Verbindungen der einzelnen Server geschaut. Der Server, welcher die geringste Anzahl an aktiven Verbindungen hat, bekommt die Anfrage zugeschanzt.

upstream intrigleastload {
        least_conn;
        server srv1.example.com;
        server srv2.example.com;
        server srv3.example.com;
    }

Session-Persistenz - IP Hash

Die dritte Möglichkeit Last zu verteilen, stellt das IP-Hash-Verfahren dar. Hier werden von den zugreifenden Client IPs Hash Werte erstellt. Anhand dieser Werte wird einem Client immer ein bestimmter Server zugewiesen. Damit erhält der Nutzer eine Session Persistenz, da Anfragen immer vom gleichen Server beantwortet werden.

Beim Round-Robin- oder Least-Connected-Load-Balancing kann jede nachfolgende Anfrage eines Clients potenziell auf einem anderen Servern ankommen.

upstream itrighash {
    ip_hash;
    server srv1.example.com;
    server srv2.example.com;
    server srv3.example.com;
}

Weighted load balancing

Alle Varianten lassen sich zusätzlich gewichten. So kann es vorkommen, dass ein Server eine bessere Hardware verbaut hat, als ein anderer. Mit Weighted load balancing lässt sich einzelnen Geräten mehr Last zuschieben.

upstream itrigmitgewicht {
        server srv1.example.com;
        server srv2.example.com weight=3;
        server srv3.example.com;
    }
upstream itrig {
    ip_hash;
    server srv1.example.com weight=2;
    server srv2.example.com;
    server srv3.example.com;
}

Mehr zu der Thematik unter load_balancing.


Nginx als Reverse Proxy verwenden

Den aufmerksamen Lesern dürfte aufgefallen sein, dass in einem Code Beispiel weiter oben eine Zeile mit "proxy_pass" vorhanden ist. Diese Zeile deutet darauf hin, dass NGINX als Reverse Proxy eingesetzt wird und ein Aufruf nicht direkt auf dem Server landet, sondern weitergeleitet wird.

location /webshop {
proxy_pass http://opencart.itrig.local;
}

location /landkarte {
proxy_pass http://192.168.100.99;
}

Es gibt verschiedene "Vorteile" für so eine Weiterleitung.

So kann der Nginx als HTTPS Endpunkt dienen und die Struktur dahinter kann unverschlüsselt agieren. Auch bietet NGINX die Möglichkeit als Reverse Proxy und als Load Balancer gleichzeitig zu arbeiten, die Details sind weiter oben zu lesen.

Weiter erlaubt der vorgeschaltete Server eine Caching Funktion, was zum schnelleren Ausliefern von Webseiten beitragen kann.

Hier ein Beispiel mit gesplittetem Cache aus der offiziellen NGINX Cache Dokumentation.

proxy_cache_path /path/to/hdd1 levels=1:2 keys_zone=my_cache_hdd1:10m
                 max_size=10g inactive=60m use_temp_path=off;
proxy_cache_path /path/to/hdd2 levels=1:2 keys_zone=my_cache_hdd2:10m
                 max_size=10g inactive=60m use_temp_path=off;

split_clients $request_uri $my_cache {
              50%          “my_cache_hdd1”;
              50%          “my_cache_hdd2”;
}

server {
    # ...
    location / {
        proxy_cache $my_cache;
        proxy_pass http://my_upstream;
    }
}

Das Thema Sicherheit spielt ebenso eine Rolle, da durch den vorgeschalteten Server, die Angriffsfläche kleiner gehalten wird.


NGINX mit Regex

Richtig interessant wird es, sobald die aufgerufene URL verschiedene Eigenschaften besitzt bzw. ein besonderes Verhalten zeigen sollte.

Diese Eigenschaften werden mit regulären Ausdrücken umgesetzt.

Hier sind ein paar Beispiele von regulären Ausdrücken für NGINX :

# Die URL ist durch * case insensitive
 location ~* /itrig/ {
    #...
    #...
    }

# Die URL ist case sensitive das ^ sorgt dafür das nur z.B. /itrig/logo.jpg gültig ist und nach dem ersten Match gestoppt wird.
 location ^~ /itrig/ {
    #...
    #...
    }

# Bilder anhand der Endung umleiten
 location ~ \.(gif|jpg|png)$ {
    root /data/images;
    }

# Unnötige Endungen aussperren (case insensitive)
 location ~* "\.(old|orig|original|php#|php~|php_bak|save|swo|aspx?|tpl|sh|bash|bak?|cfg|cgi|dll|exe|git|hg|ini|jsp|log|mdb|out|sql|svn|swp|tar|rdf)$" {
    deny all;
    }

# Einen Alias setzen
 location /_/static {
        alias /path/to/glory;
    }

# Rewrite einer URL,  "pfad" wird entfernt
    location /pfad {
        rewrite ^/pfad(.*)$ $1 break;
        proxy_pass http://splunk-api:8080;
    }

Es bietet sich immer an, eigene Befehle zu testen, bevor sie produktiv eingesetzt werden, denn neben Einschränkungen auf URLs kann ebenso Haus und Hof geöffnet werden.

Ein Regex Test sollte daher immer gemacht werden. Hier findet sich so ein Tool online regex.datahoarder.dev.

Das Tool kann jederzeit auf der eigenen Umgebung gehostet werden und ist auf Github zu finden.

Nginx_Regular_Expression_Tester

 

Webserver HTTP Header auf Sicherheit überprüfen

Der Header zählt zu den interessanteren Informationen eines Webservers, bleibt dem Otto-Normal-Surfer aber meist verborgen.

Über ihn lassen sich nicht nur Informationen über den laufenden Server erfahren, mit Hilfe des Headers können auch zusätzliche Sicherheitsmechanismen aktiviert werden, sogenannte "Security-related HTTP Headers". Sie werden im Feld "Content-Security-Policy" übermittelt.

Diese Funktionen dienen unter anderem dem Schutz vor Cross Site Scripting (XSS), aber auch der erhöhten Sicherheit, wie beispielsweise HTTP Strict Transport Security (HSTS).

Das Open Web Application Security Project listet die wichtigsten davon auf .

securityheaders.io

Die Webseite securityheaders.io überprüft genau diese Sicherheitseinstellungen auf Aktivität. Sie vergibt dabei Bewertungen, je nach Einsatz, von A+ (sehr gut) bis F (sehr schlecht).

Der Aufbau erinnert an den bekannten TLS-Online-Server-Test von SSLLabs, denn sogar das Feld "Hide Results" (Ergebnisse des Scans verstecken) wurde übernommen. Hier darf der Haken gerne gesetzt werden.

Eine weiteres Ergebnis außerhalb des Scorings ist R. Dies bedeutet, dass die untersuchte Webseite weitergeleitet wird.

securityheaders.io-redirect

Fazit

Als Ergänzung zum Online-Test von SSLLabs oder vergleichbaren Tools wie SSLyze bietet securityheaders.io eine zusätzliche Möglichkeit Webserver auf ihre Sicherheitseinstellungen zu überprüfen.

Anleitung - Ubuntu 14.04 LTS Server - Tomcat 7 mit Apache Server in 15 Minuten installieren und konfigurieren

Damit mal wieder etwas Leben in die Bude kommt hier eine kurze Anleitung, wie man innerhalb von 10-15 Minuten einen Tomcat Server in Verbindung mit Apache auf einem Ubuntu Server System (14.04) installiert und konfiguriert.

Zunächst müssen die benötigten Pakete installiert werden. Neben Apache 2 und Tomcat 7 wird zusätzlich Java benötigt.

Für den richtigen Betrieb ist ebenfalls mod-jk von Nöten, diese Modul leitet Anfragen an den Apache mit Hilfe des Protokolls AJP an Tomcat weiter.

Installation

sudo apt-get update

sudo apt-get install apache2

sudo apt-get install tomcat7

sudo apt-get install openjdk-7-jre-headless

sudo apt-get install libapache2-mod-jk

Nachdem alle Pakete installiert sind, müssen einige Dateien konfiguriert werden:

Tomcat Konfiguration

Das Arbeitsverzeichnis und den Worker Prozess für Tomcat festlegen:

nano /etc/apache2/workers.properties

workers.tomcat_home=/var/lib/tomcat7
workers.java_home=/usr/lib/jvm/java-7-openjdk-amd64
ps=/
worker.list=worker1
worker.worker1.port=8009
worker.worker1.host=localhost
worker.worker1.type=ajp13
worker.worker1.lbfactor=1

Dem Mod-JK Modul mitteilen wo diese Datei zu finden ist und Wo Fehler und Co gelogt werden sollen:

nano /etc/apache2/mods-enabled/jk.conf

JkWorkersFile /etc/apache2/workers.properties

JkLogFile /var/log/apache2/mod_jk.log

Dem Tomcat Server mitteilen, dass der AJP Prozess verwendet werden soll, dazu muss folgender String aktiviert werden:

nano /etc/tomcat7/server.xml

<Connector port="8009" protocol="AJP/1.3" redirectPort="8443" />

Apache Server konfigurieren

Zunächst erfolgt die Konfiguration für die zukünftige Seite an sich. Natürlich mit SSL. Hierzu werden bereits Schlüsselpfade hinterlegt, welche im nächsten Schritt noch erstellt werden müssen. Wichtig ist das Einbinden von JKMount, damit Tomcat und Apache zusammen arbeiten. FYI: Es wird der Bereich innerhalb von "VirtualHost _default_:443" angepasst.

sudo nano /etc/apache2/sites-available/default-ssl.conf

ServerAdmin
webmaster@localhost
ServerName tomcatsrv:443
DocumentRoot /var/lib/tomcat7/webapps/ROOT/
SSLEngine on
SSLCertificateFile /etc/apache2/crypt/tomcatsrv.crt
SSLCertificateKeyFile /etc/apache2/crypt/tomcatsrv.key
JKMount /ROOT* worker1

Verschlüsselung aktivieren

Damit der Server gleich eine sichere Verbindung verwendet, wird http erst gar nicht konfiguriert, sondern gleich https aktiviert. 

sudo a2enmod ssl

sudo mkdir /etc/apache2/crypt

sudo openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout /etc/apache2/crypt/tomcatsrv.key -out /etc/apache2/crypt/tomcatsrv.crt

Den richtigen CN in unserem Fall "tomcatsrv" vergeben.

Am Ende sollten alle Dienste neu gestartet werden

Neustart der Dienste

sudo service apache2 restart

sudo service tomcat7 restart

Sollte es zu Fehlern bei der Konfiguration gekommen sein, werdet ihr das beim Neustarten der Dienste bemerken. Alternativ kann ein Blick ins Log nie schaden.

Sollte unverhofft alles glatt gehen, müsstet ihr unter https://tomcatserv:443 die Tomcat Startseite finden ("ROOT"). Viel Erfolg. 

Better Crypto - Applied Crypto Hardening Handbuch - Codeschnipsel für sicheres Netzwerken

Auf dem 30. Chaos Communication Congress wurde dieses Jahr das Applied Crypto Hardening Handbuch vorgestellt. Zunächst noch als PDF zum Download, eine Online Version in HTML soll folgen. Die Macher (BetterCrypto) möchten damit eine Anleitung für Netzwerker und Systemadministratoren bereitstellen, welche die wichtigsten Crypto Einstellungen für bekannte Systeme behandelt.

BetterCrypto

Ziel ist es, Codeschnipsel bereitzustellen, welche der Anwender direkt per Copy und Paste in die jeweilige Konfiguration übernehmen kann. So muss nicht lange in den Einstellungen nach den richtigen Anweisung für eine sichere Verschlüsselung gesucht werden. Der Einsatz ist somit denkbar einfach, siehe folgende Codezeilen für einen Mailserver:

Crypto unter Postfix

smtpd_tls_cert_file = /etc/ postfix / server .pem

smtpd_tls_key_file = /etc/ postfix / server . key

# use 0 for Postfix >= 2.9 , and 1 for earlier versions

smtpd_tls_loglevel = 0

# enable opportunistic TLS support in the SMTP server and client

smtpd_tls_security_level = may

smtp_tls_security_level = may

# if you have authentication enabled , only offer it after STARTTLS

smtpd_tls_auth_only = yes

tls_ssl_options = NO_COMPRESSION

An diesem Beispiel ist gut zu erkennen, dass dieser Code zwar für Grundverschlüsselung sorgt, jedoch auf das eigene System durchaus noch angepasst werden kann. So kann bei vielen Mailservern die Verschlüsselung zwischen den jeweiligen Providern durchaus erzwungen werden, also "smtp_tls_security_level = encrypt". Der Code kann also ohne Hintergrundwissen übernommen werden, Lesen schadet aber bekanntlich ja auch nicht.

Crypto Codeschnipsel 

Neben Postfix stellt die Codesammlung Einstellungen für folgende Systeme bereit:

  • Webserver
    • Apache, lighttpd, nginx, ms iis
  • SSH
    • Open SSH, Cisco ASA, Cisco IOS
  • Mailserver
    • Postfix, Dovecot, Cyrus, SMTP, Exim
  • VPN
    • IPSec, OpenVPN, PPTP, Cisco ASA
  • PGP
  • Instant Messaging
    • XMPP, Jabber, IRC, SILC
  • Datenbanken
    • Oracle, MySQL, PostgreSQL, DB2
  • Proxylösungen

Code ist nicht alles, so werden auf den 80 Seiten durchaus auch Theorie und Praxis beschrieben. Für Anwender und Admins sicherlich eine Pflichtlektüre.

Download  Better Crypto - Applied Crypto Hardening Handbuch