NGINX Training Dezember 2019

• nur GET

# nc nginx.defaultroutes.de 80
get /

• RFC 1945
• HEAD und POST Anfragen
• HTTP Versionsnummer in der Anfrage
• HTTP Header
• Mime-Types für Dateiformate
• Response-Codes

  # nc nginx.defaultroutes.de 80
  GET / HTTP/1.0
  Accept: text/html,application/xhtml+xml,image/jxr/,*/*
  
  

• RFC 2068
• Host Header verpflichtend
• HTTP Proxies
• Header für Keep-Alive
• Pipelining
• PUT, OPTIONS, CONNECT, TRACE, und DELETE verben
• Cache-Control Header
• Basic Authentication
• Trailing headers (Trailer) https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Trailer

# nc nginx.defaultroutes.de 80
GET / HTTP/1.1
Host: nginx.deafultroutes.de
Accept: text/html,application/xhtml+xml,image/jxr/,*/*

• RFC 7540
• basierend auf SPDY von Google
• binäres Protokoll
• asynchrone Streams
• nur mit TLS implementiert, Protokollauswahl im TLS Handshake
• Server Push und Server Hint
• Header Compression (HPACK)

• Neues HTTP Protokoll, ursprünglich HTTP-over-QUIC
• UDP basiert
• TLS Transportverschlüsselung (TLS 1.3+) eingebaut
• wird schon bei Google eingesetzt (google.com und youtube.com)
• Chrome und Firefox unterstützen h3
• Internet Draft: https://quicwg.org/base-drafts/draft-ietf-quic-http.html

• Nach einer Änderung der NGINX Konfiguration muss diese Konfiguration neu geladen werden
• vor dem neu Laden des Konfiguration sollte immer geprüft werden, ob die Konfiguration vom NGINX geladen werden kann
• der Aufruf nginx -t testet die Konfigurationsdatei. Mit dem optionalen Parameter -c <datei> kann eine Konfigurationsdatei angegeben werden

# nginx -t -c /etc/nginx/nginx.conf
nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful

• war der Test der Konfiguration erfolgreich, kann die neue Konfiguration mit nginx -s reload in den NGINX Webserver geladen werden. Ein stoppen und neu starten des NGINX Dienstes ist nicht erforderlich.

• NGINX skaliert sehr gut über die bestehenden Hardware-Ressourcen
• die Direktive worker_connections innerhalb eines events Block beschränkt die Anzahl der gleichzeitigen Netzwerk-Verbindungen zum NGINX-Server.
• bei einem Server mit sehr vielen Anfragen sollte dieser Wert für die Hardware in einem Test ermittelt werden
• die wirkliche Anzahl von Verbindungen kann über den stub_status (Kapitel Monitoring) überwacht werden. Wenn die von stub_status gemeldete Anzahl gleicher Verbindungen die in diesem Parameter eingestellten Wert erreicht, so sollte der Wert erhöht werden. Dabei sollte die Systemlast und die Antwortgeschwindigkeit des Servers überwacht werden
• Der Standard-Wert ist 512, für moderne Hardware ist 1024 ein guter Startwert

events {
    worker_connections  1024;
}

• MIME = Multipurpose Internet Mail Extensions
• seit HTTP/1.0 sendet ein Webserver zu jedem Dokument ein Content-Type Header, welcher dem Web-Browser eine Information gibt, wie die Daten darzustellen sind
• eine ggf. vorhandene Datei-Endung wird von Browsers nicht beachtet
• NGINX muss jedoch wissen, welcher MIME-Type für Dokumente ausgeliefert werden soll. Diese Zuordnung auf der Seite des Webservers geschied durch die Datei-Endungen
• Beispiel einer MIME-Type Definition für NGINX

types {
    text/html                                        html htm shtml;
    text/css                                         css;
    text/xml                                         xml;
    image/gif                                        gif;
    image/jpeg                                       jpeg jpg;
    application/javascript                           js;
    application/atom+xml                             atom;
    application/rss+xml                              rss;
}

• NGINX unter CentOS bringt eine Konfigurationsdatei mit den gängigen MIME-Typen mit. Diese Konfigurationsdatei mit dem Namen mime.types kann im http Block per include in die NGINX-Konfiguration aufgenommen werden

include             /etc/nginx/mime.types;

• die Direktive default_type definiert den MIME-Type, welcher von NGINX gesetzt wird, wenn keine Zuordnung zu einer Datei-Endung gefunden wurde

default_type        application/octet-stream;

• IANA List der MIME-Types https://www.iana.org/assignments/media-types/media-types.xhtml
• MDN Basics of HTTP - Mime-Types: https://developer.mozilla.org/en-US/docs/Web/HTTP/Basics_of_HTTP/MIME_types

• um nicht für jede neue Datei den SELinux Sicherheitskontext neu setzten zu müssel kann der Kontext in der SELinux Policy verankert werden. Alle neue Dateien welche unter /srv/nginx erstellt werden, bekommen damit den SELinux-Type httpd_sys_content_t:

  semanage fcontext -a -t httpd_sys_content_t --ftype f "/srv/nginx(/.*)?"
  semanage fcontext -a -t httpd_sys_content_t --ftype d "/srv/nginx(/.*)?"
  

• NGINX unterstützt das Konzept von virtuellen Webservern (virtual web-hosting). Bei virtuellen Webservern können auf einem Server mit einer IP-Adresse mehere Webseiten mit verschiendenen Domain-Namen ausgeliefert werden. Ein Web-Browser muss diesen Web-Server per Domain-Namen (nicht per IP-Adresse) und per HTTP/1.1 Protokoll (oder neuer) ansprechen.
• der NGINX Webserver sucht in der Konfiguration nach dem vom Web-Browser übermittelten DNS-Servernamen. Wird dieser gefunden, so wird die entsprechende Konfiguration des dazugehörigen Server-Blocks benutzt.
• Die Direktive server_name kann auch das Platzhalter-Zeichen "*" am Anfang oder Ende des Server-Namens beinhalten, z.B. *.example.com oder example.*. Platzhalter zeichen können nicht in der Mitte des Namens auftauchen.
• Startet der Server-Name mit dem Tilde-Zeichen ~, so wird der Name als Perl oder Python Regulärer-Ausdruck interpretiert: server_name "~^(?<name>\w\d{1,3}+)\.example\.net$";
• ein leerer Server-Name wird mit dem Hostnamen des NGINX-Servers gefüllt: server_name "";
• der spezielle Server-Name _ ist ein "Catch-All" für alle Namen
• Wird der angefragte DNS-Name nicht gefunden, oder wird der Server per IP-Adresse angesprochen, so wird die "default"-Konfiguration aktiv. Die Default-Konfiguration ist die Konfiguration mit dem Schlüsselwort default_server in der listen Konfigurationdirektive. Ist kein server Block als default_server markiert, so wird die erste Server-Konfiguration in der Konfigurationsdatei aktiv.
• Beispiel einer virtuellen Webserver-Konfiguration mit zwei Web-Auftritten:

http {
  server {
    listen       80;
    server_name  example.de www.example.de www.example.com;
    root  "/srv/nginx/example.de/html";
    [...]
  }
  server {
    listen       80 default_server;
    server_name  beispiel.de www.beispiel.de;
    root  "/srv/nginx/beispiel.de/html";
    [...]
  }
}

• mit einem location Block kann die Konfiguration von NGINX für einen bestimmten Pfad, oder für bestimmte Datei-Namen, geändert werden
• Pfad- und Dateinamen für den location Block können als absoluter Name, oder als regulärer Ausdruck angegeben werden (reguläre Ausdrücke sind CPU intensiv und können die Auslieferung von Webseiten verlangsamen)
• Beispiel absoluter Pfad:

server {
  listen 80;
  server_name www.example.com;
  root /srv/nginx/;
  location /site1 {
    root /srv/nginx/site1;
  }
}

• Beispiel regulärer Ausdruck (Bild-Dateien dürfen für 14 Tage gecached werden)

server {
  listen 80;
  server_name www.example.com;
  root /srv/nginx/;
  location ~* \.(png|jpg|jpeg)$ {
    expires 14d;
  }
}

• die Definition eines Location-Block kann über sg. location modifier angepasst werden:

  Modifier	Wirkung
  ~*	bei regulärem Ausdruck Gross-/Kleinschreibung nicht beachten (case insensitive)
  ~	bei regulärem Ausdruck Gross-/Kleinschreibung beachten
  ^~	nicht auf reguläre Ausdrücke prüfen
  =	Datei-/Pfadangabe exakt benutzen (nicht nach regulären Ausdrücken suchen)

• wichtige Dokument der Webseite sollten aus Geschwindigkeitsgründen mit dem Location-Modifier "=" markiert werden

• für Software-Download-Seiten ist es praktisch, wenn der Webserver automatisch eine Webseite mit einem Verzeichnis aller Dateien auf dem Webserver ausgibt.
• ein Directory Listing kann pro location Block angeschaltet werden

server {
  listen 80;
  server_name www.example.com;
  root /srv/nginx/;
  location /downloads {
    root /srv/nginx/software;
    autoindex on;
    autoindex_exact_size off;
    autoindex_localtime on;
  }
}

• Die Direktive autoindex_localtime schaltet die Anzeige des Zeitstempels der Dateien an- bzw. aus.
• Die Direktive autoindex_exact_size konfiguriert, ob die Dateigrösse exakt (in Byte) oder in für Menschen einfach lesbarer Form (in Kilobyte, Megabyte oder Gigabyte) ausgegeben werden sollen.

• nach einem Redesign eines Webauftritts sind viele Dateien der Webseite nicht mehr unter den vorher bekannten URLs erreichbar. Viele externe Webseiten (und auch Suchmaschinen) haben jedoch die alten URLs noch gespeichert, und es ist unrealistisch, diese zu ändern. Mit der Direktive rewrite (oder einem Redirect) kann eine Anfrage umgeschrieben oder umgelenkt werden. Damit können Anfragen von den alten URLs auf die neuen Pfade umgeschrieben oder umgelenkt werden
• Informationen zu Rewrite und Redirect in NGINX: https://www.nginx.com/blog/creating-nginx-rewrite-rules/

• mit dem Schlüsselwort expires wird der “Cache-Control” Response-Header der HTTP-Antwort, und damit das Caching-Verhalten auf der Client-Seite beeinflusst.
• Ohne expires Direktive ist das Caching nicht aktiv
• ein expires max setzt die Caching-Zeit auf den maximalen Wert (derzeit bis zum 31. Dezember 2037, NGINX hat ein Jahr 2038 Problem). Vorsicht mit diesem Parameter!
• mit expires off kann das Caching explizit ausgeschaltet werden (wenn z.B. Caching von einem übergeordnetem Block geerbt wurde)
• mit expires @zeitpunkt kann die Cache-Zeit für die Dokumente auf einen fixed Zeitpunkt gesetzt werden. Beispiel: expires @15h30m;
• wird ein positiver Wert als Parameter zu expires angegeben, so ist dieses die Zeitdauer, über welche die ausgelieferten Dateien beim Client gecached werden dürfen: expires 24h; (Caching für 24 Stunden)
• Beispiel:

location / {
  try_files $uri index.html =404;
  expires 10d;
}

• für bestimmte Verzeichnisse unterhalb des Web-Roots kann der Zugriff verweigert werden. Dies kann per HTTP-Status via return oder mit dem Schlüsselwort deny geschehen:

server {
  listen 80;
  server_name www.example.com;
  root /srv/nginx/;
  location /secret {
    deny all;
  }
}

• hier wird explizit der Status 403 "Forbidden" zurückgegeben:

server {
  listen 80;
  server_name www.example.com;
  root /srv/nginx/;
  location /secret {
    return 403; #Forbidden
  }
}

• mit den Schlüsselwörtern deny und allow kann der Zugriff von bestimmten IP-Adressen oder Netzwerken erlaubt oder unterbunden werden. Die deny und allow Konfigurationen werden in der Reihenfolge der Konfiguration abgearbeitet und mit der IP-Adresse des Web-Clients verglichen:

server {
  listen 80;
  server_name www.example.com;
  root /srv/nginx/;
  location /secret {
    deny 192.0.2.100;
    allow 192.0.2.0/25;
    allow 203.0.113.0/24;
    allow 198.51.100.0/24;
    deny all;
  }
}

• Ein Webserver meldet auf die Anfrage eines Clients einen Status-Code
• die Status-Codes sind in Gruppen eingeteilt
  • 100-199 Information - die Anfrage wird weiter bearbeitet
  • 200-299 Erfolg - die Anfrage war erfolgreich
  • 300-399 Umleitung - die Anfrage wird auf ein neues Ziel umgeleitet
  • 400-499 Fehler bei der Client Anfrage - die Anfrage war fehlerhaft und konnte nicht beantwortet werden
  • 500-599 Fehler auf Server-Seite - der Server konnte eine korrekte Anfrage nicht beantworten
  • 900-999 (inofiziell) herstellerspezifische Fehlermeldungen
• IANA HTTP Status Code Registry https://www.iana.org/assignments/http-status-codes/http-status-codes.xhtml
• NGINX kommt mit eingebauten Fehlerseiten fuer 4xx und 5xx Fehler
  • diese Seiten können in der Konfiguration ersetzt werden
  • sowohl statische als auch dynamische (PHP, Python, Lua etc) Fehlerseiten sind möglich

error_page  404              /error_pages/404.html;
location = /error_pages/404.html {
    internal;
}

error_page  500 502 503 504  /error_pages/50x.html;
location = /error_pages/50x.html {
    internal;
}

• binde das Image-Filter Modul ngx_http_image_filter_module in die NGINX Konfiguration ein
• lese die Dokumentation des Moduls unter https://nginx.org/en/docs/http/ngx_http_image_filter_module.html
• richte den Image-Filter so ein, das alle Bilder auf der Webseite um 90 Grad gedreht werden

load_module "/usr/lib64/nginx/modules/ngx_http_image_filter_module.so";
http {
  server {
        [...]
        location ~* \.(jpg|png) {
                image_filter rotate 90;
        }
     }
}

• die DNS-Einträge für Webseite in "produktion" sollten DNS TTL Werte zwischen einer Stunde (1h) und einem Tag (1d) aufweisen
• Ausnahmen sind Webseiten auf CDN Systemen (Content-Delivery-Networks), dort werden die TTL Werte vom CDN-Betreiber vorgegeben
• Vor einer Änderung an der Infrastruktur (neue IP-Adressen, Umzug in ein neues Rechenzentrum, neuer Hoster) sollten die TTLs der Webseite eine Woche vor dem Umzug herabgesetzt werden (5-10 Minuten)
• Kurz vor dem Umzug können die TTLs dann nochmals verringert werden (1 Minute)
• Nach dem Umzug sollten die TTLS erst auf 5-10 Minuten (um, wenn notwendig, schnell auf die alte Infrastruktur schwenken zu können) und nach einigen Tagen wieder auf die hohen TTLs (1h - 24h) gesetzt werden
• Link: "Stop using ridiculously low DNS TTLs" https://00f.net/2019/11/03/stop-using-low-dns-ttls/

• oft soll eine Webseite sowohl unter dem Service-Namen www, als auch unter der Domain direkt erreichbar sein. Beispiel: www.example.de und example.de
• auf der DNS-Seite kann dies über einen CNAME (Alias) oder über mehrere Adress-Records realisiert werden

• lange Zeit war es möglich, mit mehreren Adress-Records im DNS eine einfache Lastverteilung über mehrere Web-Server zu konfigurieren
• Beispiel:

example.de.    24h IN SOA  ns01.hosting.example.  ...
example.de.    24h IN NS   ns01.hosting.example.
www.example.de. 2h IN A    192.0.2.80
www.example.de. 2h IN A    203.0.113.80
www.example.de. 2h IN A    198.51.100.80

• Bei der Abfrage des DNS-Namens www.example.de liefert das DNS alle drei IP Adressen an das Betriebssystem. Die Adressen werden in beliebiger Reihenfolge, oder in zufälliger Reihenfolge, an das Betriebsystem gegeben (abhängig von der Konfiguration des DNS-Resolvers des Clients, außerhalb der Kontrolle des Domain-Besitzers). Die Anwendungen (Browser) nutzen den ersten Eintrag, hier durch werden die Anfragen auf die drei Web-Server verteilt.
• Diese Lastverteilung funktioniert nur bei Betriebssystemen, die ausschließlich IPv4 können. Bei modernen Betriebssystemen, die IPv6 können (aber nicht unbedingt aktiv konfiguriert haben), sortiert das Betriebssystem die Adressen alphanumerisch, bevor diese an die Anwendung gegeben werden. Es wird daher von der Anwendung immer die erste Adresse in der Liste benutzt, die anderen Webserver bekommen keine Anfragen mehr.
• Links:
  • https://de.wikipedia.org/wiki/Lastverteilung_per_DNS
  • DNS Round Robin and Destination IP address selection https://web.archive.org/web/20150316185202/http://blogs.technet.com/b/networking/archive/2009/04/17/dns-round-robin-and-destination-ip-address-selection.aspx
  • RFC 6724 "Default Address Selection for Internet Protocol Version 6 (IPv6)" https://tools.ietf.org/html/rfc6724

• Die Auswahl einer Top-Level-Domain für eine Webseite bedarf einiger Überlegung
  • bietet die TLD DNSSEC Sicherheit?
  • bietet die TLD DNS-Server für die TLD mit IPv6 Adressen (wenn nicht, kann die Domain nicht von "IPv6-Only" Clients erreicht werden)?
  • gibt es Preis-Erhöhungs-Grenzen auf dem Domain-Preis?
  • wie stabil ist die Domain (wichtig bei einigen ccTLDs wie .io oder .ly oder neuen TLDs [nTLD])

• die Sicherheitserweiterung DNSSEC sichert DNS gegen gefälschte DNS Pakete ab. DNSSEC hat zwei Bestandteile
  • DNS Zonen, welche mit DNSSEC Signaturen abgesichert sind
  • DNS-Resolver, welche die DNS Antworten mit Signaturen für die DNS-Clients prüfen (validieren) können
• werden auf einer Webseite sensible Daten verarbeitet (Kreditkarteninformationen, datenschutzrelevante Informationen), so sollten die DNS-Namen der Webseite per DNSSEC abgesichert werden
• macht der NGINX Server eigene DNS-Anfragen, z.B. als Reverse-Proxy oder Load-Balancer, so sollte das Betriebssystem, auf dem NGINX läuft, für eine DNS-Auflösung über einen DNSSEC validierenden Resolver konfiguriert sein