Der perfekte Rootserver (Nginx, SSL, Mailserver, Roundcube, phpMyAdmin, Firewall)

Zypr · 02/24/2013, 03:10

Der perfekte Rootserver

Version 0.3.8

Was kann das Skript?:

Das Skript ist ein Allrounder und bietet eine Oneclick-Installation, die zahlreiche Systeme und Funktionen mit sich bringt. Es ist dafür gedacht einen frisch aufgesetzten Debian Jessie minimal Server in einen perfekten Rootserver zu verwandeln. Besonders für unerfahrene User ist das Skript bestens dafür geeignet, per "oneclick" eine sichere, perfomante und optimale Umgebung für seine Projekte zu schaffen. Die im Skript enthaltene Software beschränkt sich ausschließlich auf OpenSource-Software, die frei verwendet werden darf.

Inhalt::

Software, die unter Anderem installiert wird:

Nginx, MariaDB, Arno-Iptables-Firewall, Fail2Ban, Dovecot, Postfix, Roundcube, Z-Push, Mailcow, Spamassassin, Fuglu, ClamAV

Automation:

Das Bash-Skript übernimmt 99% aller Installationsschritte und hilft dabei, das System innerhalb weniger Minuten zum perfekten Rootserver umzufunktionieren. Die Installation ist "unantended", sprich sind alle Voraussetzungen erfüllt und die Config entsprechend angepasst, läuft die Konfiguration und Einrichtung ohne das Zutun des Benutzers. Anders als in der alten Version werden die Installationsschritte jetzt kommentiert, aber nicht ausführlich Schritt für Schritt in der Console ausgegeben. Um Benutzerfehler vorzubeugen, gibt es vor der eigentlichen Installation einige Abfragen, um sicherzustellen, dass alle Mindestkriterien erfüllt sind und die Funktionalität der jeweiligen Systeme gewährleistet ist.

Verschlüsselung und Sicherheit:

Das Setup sieht es vor, dass am Ende jegliche Verbindung zum Server verschlüsselt wird. Selbst, wenn man eine unverschlüsselte Verbindung erzwingen möchte, wird es nicht klappen (HSTS, TLS only). Es wird stets die aktuelle Version von OpenSSL und OpenSSH installiert, sodass etwaige Sicherheitslücken nach Erscheinen eines neuen Patches sofort geschlossen werden. Dank des Let's Encrypt Projekts stellt das Skript ein gültiges Zertifikat bereit, das für den Web- und Mailserver eingesetzt wird. Jedes System wird nach Möglichkeit anhand der aktuellen Sicherheitsstandards konfiguriert und abgesichert. Das Augenmerkmal liegt bei den eingesetzten Ciphers und dem Cryptosystem. Der Web- und Mailserver beinhalten eine umfangreiche Konfiguration, die nicht nur die Performance steigert, sondern auch enorm zur Sicherheit beiträgt.

Webserver:

Bei dem Webserver handelt sich um Nginx. Nginx hat sich in den letzten Jahren sehr etabliert und ist mittlerweile der beliebteste Webserver, wenn es um Performance und Stabilität geht.

Folgendes erwartet euch:

Aktuelle Nginx mainline version
NPN (HTTP/2)
PageSpeed
Naxsi (Nginx Anti XSS & SQL Injection)
HSTS, HPKP, OCSP, PFS
Keine TLS compression, keine session tickets
Caching (OpCode, Memcache, Igbinary)
Gültiges RSA 4096 bits Zertifkat, authorisiert von Let's Encrypt
Umfangreiches Tuning rund um Nginx. Mit der von dem Skript bereitgestellten Konfiguration, erreicht man bei ssllabs die Note A+
Verschleierung des Strings, indem dieser aus dem Header und den automatisch generierten Fehlerseiten entfernt wird
Allgemeines Systemtuning

Nun was bedeuten die ganzen Funktionen und Module? Hier eine kurze Aufklärung:

HTTP/2 (Hypertext Transfer Protocol 2):

HTTP/2 ist der "neue" HTTP-Standard und ist im Vergleich zu der alten Version 1.1 um ein VIELFACHES schneller. Die wohl wichtigste Funktion ist das parallele Laden der Inhalte über eine einzige TCP-Verbindung.

Wie schnell HTTP/2 wirklich ist, kann man anhand dieser Seite hier wunderbar sehen:

Für den Test ist ein relativ moderner Prozessor/Browser vorausgesetzt. Opera kann das Resultat verfälschen, wenn man im Turbomodus unterwegs ist. Dabei werden fast alle Inhalte komprimiert und durch einen Proxy geschleust. Aus diesem Grund kann es sein, dass Opera mit HTTP schneller unterwegs ist als mit HTTPS und somit HTTP/2. Beste Resultate erzielt man, wenn der Inhalt komplett unkomprimiert übertragen wird, so wie das eigentlich sein sollte.

Mehr Infos:

Googles PageSpeed:

PageSpeed dient dazu die Latenz und den Traffic des Servers zu verringern, indem anhand von bestimmten Filtern der Kontent so verändert wird, dass dieser schneller verarbeitet werden kann. So werden z. Bsp. CSS-, JavaScript- oder Bild-Dateien optimiert, ohne dass der Benutzer es mitbekommt. Als Beispiel werden Metadaten von Bildern entfernt, um die Größe zu verringern. Grundsätzlich arbeitet PageSpeed mit jeder Art von Inhalt und ist so konzipiert, die Ladezeiten drastisch zu verringern. Außerdem kann Pagespeed den Inhalt im Speicher zwischenladen, um so schneller Zugriffszeiten zu gewährleisten.

Mehr Infos:

Naxsi:

Was mod_security für Apache ist, ist Naxsi für Nginx - eine Web Application Firewall. Vor eine Website geschaltet, lässt naxsi nur Requests durch, die eine Art Whitelist für zulässig befindet - Deny by Default soz. Die Default Rules filtern schon eine große Anzahl von bekannten Angriffsmustern heraus. Am Besten lässt man naxis schon mal eine Weile im Lernmodus in der Dev- und/oder Stage-Phase laufen, dann hat man für das Produktivsystem schon mal eine sehr gute Ausgangsbasis für eine Whitelist.

Text von:

HSTS, HPKP, OCSP, PFS:

HSTS:
HSTS (HTTP Strict Transport Security) ist ein zusätzliche Maßnahme gegen Man-in-the-middle-Angriffe. Der Webserver sendet hierbei einen HTTP response header namens "Strict-Transport-Security" und erzwingt eine verschlüsselte Verbindung seitens des Clienten zu den in den im Zertifikat enthaltenen Domains und Subdomains.

So sieht der Header aus:

Code:

Strict-Transport-Security: max-age=63072000; includeSubdomains; preload

Was bringt HSTS denn nun? Als Beispiel: Gehen wir von der Onlinebanking-Seite einer Bank aus. Bei jeder Verbindung zu der Seite übergibt der Webserver ein von einer gültigen Zertifizierungsstelle signiertes Zertifikat, zusätzlich nutzt der Webserver den HSTS-Zusatz und übermittelt diese Regel bei der ersten Verbindung im Header. Gleichzeitig wird in der Datenbank des Browsers ein "Supercookie" gespeichert, der unter anderem auch die Gültigkeit und die Art beinhaltet, wie HSTS die jeweilige Seite zu behandeln hat. Nun kommt ein böser Superhacker daher, komprimitiert das Netzwerk und schafft es mit Hilfe einer MITM-Attacke das Zertifikat gegen ein anderes auszutauschen. Nun passiert bei dem Besuch der Seite der Bank aber folgendes:

Spoiler

Moderne Browser lassen es an dieser Stelle nicht mehr zu, dass eine Verbindung zu dem Server aufgebaut werden kann. Da es sich hierbei um einen sogenannten "Supercookie" handelt, kann man diesen auch nicht einfach durch Löschen der normalen Cookies oder des Caches rückgängig machen (Zumindest bei Firefox). Hierzu benötigt man Addons oder Tools, die man im Internet finden kann.

HPKP:
HPKP (HTTP Public Key Pinning) ist eine weitere Maßnahme gehen Man-in-the-middle-Angriffe. Der Webserver sendet wie bei HSTS auch einen HTTP response header namens "Public-Key-Pins" und speichert diesen als "Supercookie". Der Vorteil gegenüber HSTS ist allerdings, dass diese Maßnahme auch gefälschte aber gültige Zertifikate ausschließt. Ohne den HPKP-Zusatz würde HSTS nichts ausrichten, denn wenn der Browser das Zertifkat als gültig anerkennt, also wenn eine Zertifizierungsstele bestätigt, dass das Zertifikat tatsächlich für die Domain ausgestellt worden ist, dann passiert nichts und das Opfer kriegt nichts mit. Der HPKP-Header übermittelt hierfür einen "Pin", der aus dem gültigen Zertifikat oder privaten Schlüssel "extrahiert/generiert" wird. Dieser Pin ist einzigartig und kann auch nicht einfach so gefälscht werden. Deshalb kann dieser auch mit nur einem ganz bestimmten Zertifikat und Schlüssel verwendet werden. Wenn also jemand das Zertifikat austauscht, stimmt der Pin nicht mehr mit dem Zertifikat oder dem privaten Schlüssel und somit auch nicht mit dem von dem Webserver übermittelten Pin überein. Das Resultat ist am Ende das gleiche wie bei einem komprimitierten und unsicheren Zertifikat bei HSTS - der Webserver lässt die Verbindung zu dem Server nicht mehr zu.

So sieht der Header aus:

Code:

Public-Key-Pins: pin-sha256="u+tkeXnIk5+bpGXLjvb08q8ijH8aIQlHIqQNKCfxcpk="; pin-sha256="kNPgJ65kzLsbEawiVZ619XQnHruivMwG+E/bla8K4DE="; max-age=5184000; includeSubDomains

Perfect Forward Secrecy:

Auszug aus Wikipedia:
Perfect Forward Secrecy (PFS), auf deutsch etwa perfekte vorwärts gerichtete Geheimhaltung, ist in der Kryptographie eine Eigenschaft bestimmter Schlüsselaustauschprotokolle. Schlüsselaustauschprotokolle verwenden zuvor ausgetauschte Langzeitschlüssel, um für jede zu verschlüsselnde Sitzung einen neuen geheimen Sitzungsschlüssel zu vereinbaren. Ein Protokoll hat Perfect Forward Secrecy, wenn die verwendeten Sitzungsschlüssel nach der Beendigung der Sitzung nicht mehr aus den geheimen Langzeitschlüsseln rekonstruiert werden können. Damit kann eine aufgezeichnete verschlüsselte Kommunikation auch bei Kenntnis des Langzeitschlüssels nicht nachträglich entschlüsselt werden.[1] Gelegentlich wird diese Eigenschaft auch unter dem Schlagwort Folgenlosigkeit behandelt, da ein späteres Aufdecken des Langzeitschlüssels folgenlos für die Sicherheit aller früheren Sitzungen bleibt. Diese Eigenschaft betont auch die alternative englische Bezeichnung break-backward protection.

Mehr Infos:
https://de.wikipedia.org/wiki/Perfect_Forward_Secrecy

OCSP stapling:

Das Online Certificate Status Protocol ist ein Netzwerkprotokoll, das Clients ermöglicht, den Status von X.509-Zertifikaten bei einem Validierungsdienst abzufragen. Bei der Verbindung zu einer Webseite, die ein Zertifikat übermittelt, verbindet sich der Browser zusätzlich per OCSP zum Aussteller, damit die Echtheit verifiziert werden kann. Ist der Server des CAs allerdings gerade überlastet, weil diesen zu viele Anfragen gleichzeitig erreichen, erhöht sich die Ladezeit entsprechend. Hier kommt OCSP stapling ins Spiel: Anstatt des Servers der Zertifizierungsstelle übernimmt der eigene Webserver selbst diese Funktion, dazu muss Nginx ein "bundle" aus den Root-Zertifikaten des Ausstellers mitgeteilt werden, das vorab validiert und im DER-Format kodiert werden muss. Die Validierung findet alle 5 Tage statt, sodass der Client nicht immer wieder bei der Zertifizierungsstelle nachfragen muss. Wenn die Kette der Zertikate korrekt eingehalten und bereitgestellt wird, braucht man keine zusätzliche Datei für das ocsp stapling generieren.

Hier ein Beispielheader:

Spoiler

Wer sich trotz Let's Encrypt ein eigenes Zertifikat zulegen möchte, findet hier eine Anleitung anhand eines COMODO PositiveSSL Zertifikats, wie man überhaupt an ein Zertifikat kommt und OCSP zu Laufen bringt:

Spoiler

Zuerst muss ein privater Schlüssel erstellt werden:

Code:

openssl ecparam -out perfectrootserver.net.key -name secp384r1 -genkey

Anschließend der CSR:

Code:

openssl req -new -sha256 -key perfectrootserver.net.key -nodes -out perfectrootserver.net.csr

Die Fragen sollten wie folgt beantwortet werden, dabei kann man alle Felder außer FQDN ausgelassen. Wichtig ist, dass kein Passwort vergeben wird!

Spoiler

Im folgenden Beispiel habe ich mir ein SSL-Zertifikat für die Domain perfectrootserver.net gekauft und möchte dieses nun aktivieren. Nachdem der CSR erstellt worden ist, wählt man den korrekten Webserver aus, in dem Fall ist es ganz wichtig, dass man "Apache OpenSSL" auswählt! Nun kopiert den Inhalt von "perfectrootserver.net.csr" in das entsprechende Feld.

Im nächsten Schritt wird eine Verifizierung durchgeführt, damit auch der tatsächliche Inhaber dieser Domain das Zertifikat erhält. Das geschieht bei einer einfachen Domain Validation per E-Mail an eine vorgegebene Adresse, zur Auswahl stehen meistens root, webmaster oder admin. Nachdem die Legitimation erfolgreich durchgeführt wurde, erhält man die Zertifikate mit folgendem Inhalt per E-Mail:

Code:

AddTrustExternalCARoot.crt
COMODOECCAddTrustCA.crt
COMODOECCDomainValidationSecureServerCA.crt
perfectrootserver_net.crt

Nun müssen die Zertifikate kombiniert werden (Die Reihenfolge ist wichtig!):

Code:

cat perfectrootserver_net.crt COMODOECCDomainValidationSecureServerCA.crt > perfectrootserver.net.bundle.crt

Und das trustedbundle:

Code:

cat COMODOECCDomainValidationSecureServerCA.crt COMODOECCAddTrustCA.crt > trustedbundle.crt

Jetzt nur noch die stapling file:

Code:

openssl ocsp -text -no_nonce -issuer  COMODOECCDomainValidationSecureServerCA.crt -CAfile  perfectrootserver.net.bundle.crt -cert perfectrootserver_net.crt -VAfile  COMODOECCDomainValidationSecureServerCA.crt -url  http://ocsp.comodoca.com -respout /etc/nginx/ssl/ocsp_staple

So sieht dann die VHost-Config aus:

Spoiler

Achtung! Windows XP unterstützt ECDSA nicht! Wer auch Windows XP Nutzer mit IE6/7/8 auf seine Seite lassen möchte, muss zu RSA wecheln. Wie erstellt man ein RSA Zertifikat? Dazu braucht man den Key und den entsprechenden CSR:

Code:

openssl req -nodes -sha256 -newkey rsa:4096 -keyout domain.com.key -out domain.com.csr

Der Rest verläuft genau so wie mit ECDSA beschrieben, nur dass an Stelle von ECC eben RSA in den Dateinnahmen der Zertifikate steht (zwecks Unterscheidung).

Caching:

Durch zahlreiche Einstellungen ist der Webserver für hohe Besucherspitzen bestens gerüstet. Natürlich kann der Server nur so gut sein, wie die entsprechend zur Verfügung gestellten Ressourcen. Ein wesentlicher Bestandteil dabei ist der OpCode Cache (APCu), denn dadurch wird die Verarbeitung von PHP-Codes enorm verbessert. Folgendes Bild verdeutlicht die Funktion von APCu auf einen Blick:

Spoiler

Mailserver:

Der Mailserver ist neben dem Nginx Webserver ein wichtiger Bestandteil eines erfolgreichen Projekts. Administratoren haben nach einiger Zeit stark mit Spam, Viren und Bots zu kämpfen, so muss man dafür sorgen, dass auch dieses System optimal funktioniert.

Wie auch oben erwähnt, wird jegliche Verbindung zu dem Mailserver verschlüsselt. ClamAV, SpamAssassin und Fuglu bieten soliden Schutz gegen den Schmutz aus dem Netz. Die Authentifizierung findet über MySQL statt und wird durch eine kryptische Authentifizierung mittels DKIM an dem DNS-Server, der die Einträge der Domain verwaltet, ergänzt. Zusätzlich erschwert SPF das Fälschen einer Absenderadresse. Schickt also jemand von einem anderen Server eine E-Mail mit dem Absender des eigenen Servers, prüft der Emfänger, ob der Absender überhaupt berechtigt ist. Hierzu werden die Felder "MAIL FROM" und "HELO" in der SMTP-Verbindung mit den der SPF Regel des DNS-Servers verglichen. Stimmt also z. Bsp. die IP-Adresse des Absenders nicht, wird die E-Mail verworfen oder als Spam gekennzeichnet. Damit die E-Mail Postfächer nicht alle per Hand gepflegt werden müssen, dient Mailcow als administratorische Hilfe. Mailcow bringt eine Weboberfläche mit sich, sieht cool aus und ist auch noch sehr sicher.

Mehr informationen zu den Funktionen des Mailservers und der dazugehörigen findet man hier:

An dieser Stelle auch noch mal ein großes Dankeschön an André, der viel Zeit und Energie in das Mailcow-Projekt steckt.

System:

Wie auch in der Version zuvor wird das System mit Hilfe einer Software-Firewall (Arno-Iptables-Firewall), Fail2Ban und der Anpassung des Kernels abgehärtet. Fail2Ban scant außerdem die Logs und reagiert entsprechend mit einem Ban, wenn verdächtige Aktivitäten wie z. Bsp. mehrmals hintereinander fehlgeschlagene Loginversuche. Außerdem läuft ein Cronjob, der täglich eine Liste mit aktuellen IP-Adressen aus zahlreichen Quellen erstellt und diese in die iptables Schreibt.

Folgende Quellen werden genutzt:

Code:

http://www.projecthoneypot.org/list_of_ips.php?t=d&rss=1
http://check.torproject.org/cgi-bin/TorBulkExitList.py?ip=1.1.1.1
http://www.maxmind.com/en/anonymous_proxies
http://danger.rulez.sk/projects/bruteforceblocker/blist.php
http://rules.emergingthreats.net/blockrules/compromised-ips.txt
http://www.spamhaus.org/drop/drop.lasso
http://cinsscore.com/list/ci-badguys.txt
http://www.openbl.org/lists/base.txt
http://www.autoshun.org/files/shunlist.csv
http://lists.blocklist.de/lists/all.txt

Wie installiere ich das ganze Zeug nun endlich?!

Wichtig!!!!

Quote:

Vorab möchte ich deutlich darauf hinweisen, dass das Skript nicht mit einem VPS kompatibel ist! ()

Das Problem dabei ist, dass es sich bei einem VPS um keine vollwertige Virualisierung handelt, deshalb kann der Kernel des Gastsystems auch nicht modifizieren werden. Aus diesem Grund ist die Verwendung von wichtigen Kernelfunktionen nicht möglich und führt so zu zahlreichen Problemen während der Installation und/oder des Betriebs.

Bevor es los geht, hier noch einmal die Voraussetzungen, um das Script benutzen zu können:

vServer / Root Server
Debian 8 (Jessie) minimal (frisch installiert!)
Mindestens 1 GB RAM, empfohlen 2 GB!
Mindestens 1 CPU Core, empfohlen 2!
Eine TLD! -> Top-Level-Domain ? Wikipedia
Die Möglichkeit, die DNS Records dieser Domain verändern zu können. Dienste wie CloudFlare werden teilweise unterstützt.
Die Möglichkeit, den Reverse DNS zu verändern (Keine Pflicht)

Eine Domain und die Möglichkeit, DNS Records dieser Domain zu verändern, ist eine Pflichtvoraussetzung. TLDs gibt es auch kostenlos (Stichwort .tk Domain ->

). Dank Let's Encrypt gibt es ein gültiges SSL-Zertifikat auch kostenlos!

Installation:

Das Skript findet man auf GitHub:

Erste Schritte:

Damit das Skript direkt bei dem ersten Start ohne Probleme durchläuft und ein gültiges Zertifikat erstellt werden kann, müssen folgende Domains und Subdomains zu der IP-Adresse des Servers auflösen:

Wenn der Mailserver nicht genutzt wird:

Code:

deinedomain.tld
www.deinedomain.tld

Wenn der Mailserver genutzt wird:

Code:

deinedomain.tld
www.deinedomain.tld
mail.deinedomain.tld
dav.deinedomain.tld
autodiscover.deinedomain.tld
autoconfig.deinedomain.tld

Auf die restlichen DNS-Einträge wird am Ende der Installation ein Assistent eingehen und bei der Einrichtung helfen.

Sind alle Voraussetzungen gegeben, kann das Skript wie folgt installiert werden:

1. Aktuelle Versionsnummer herausfinden ->

2. Herunterladen:

Code:

wget -O ~/perfectrootserver.tar.gz https://github.com/zypr/perfectrootserver/archive/v0.x.x.tar.gz

3. Extrahieren

Code:

tar -xzf ~/perfectrootserver.tar.gz -C ~/ --strip-components=1

4. Config anpassen

Code:

nano ~/userconfig.cfg

5. Installation starten

Code:

bash ~/install.sh

Update:

Aktuell gibt es noch keine Möglichkeit, ältere Versionen des Skripts automatisch zu updaten. Der User Mxiiii hat sich die Mühe gemacht, ein quick & dirty Skript zu schreiben, dass diese Funktion übernimmt. Hier der Link zu seinem GitHub-Profil:

Danke nochmal!

Wichtige Ordner und Dateien:

Wenn der Server installiert ist, findet man wichtige Datein und Ordner an folgenden Stellen:

Pfad zum öffentlichen html docs Ordner:

Code:

/etc/nginx/html

Nginx-Konfiguration:

Code:

/etc/nginx/nginx.conf

Vhosts-Konfiguration:

Code:

/etc/nginx/sites-available
bzw als symbolischer Link in:
/etc/nginx/sites-enabled

Nginx-SSL-Zertifikate:

Code:

/etc/nginx/ssl/

Firewall Konfiguration:

Code:

/etc/arno-iptables-firewall/firewall.conf

Grundsätzlich kann die Firewall erneut konfiguriert werden, indem man z. Bsp. mehr Ports hinzufügen möchte. Entweder man macht es per Hand direkt in der firewall.conf (Zeilen 1164 und 1165) oder nutzt das mitgelieferte Skript. Folgende relevante Datein findet man wie folgt:

Firewall Configure Skript:

Code:

~/sources/aif/configure.sh

Firewall Uninstall Skript:

Code:

~/sources/aif/uninstall.sh

Firewall Install Skript:

Code:

~/sources/aif/install.sh

SSL Zertifikat:

Das Zertifikat von Let's Encrypt ist aktuell nur 3 Monate gültig, deshalb muss es ca. alle 80 Tage neu validiert werden. Let's Encrypt ansich findet man hier:

Code:

/root/sources/letsencrypt

So erstellt/erneutert man sein Zertifikat:

In den Ordner navigieren:

Code:

cd ~/sources/letsencrypt

Jetzt kann man ein neues Zertifikat erstellen. Let's Encrypt bietet zwar keine Wildcard Zertifikate an, unterstützt aber meines Wissens nach beliebig viele Subdomains.

Code:

Wenn der Mailserver genutzt wird:
./letsencrypt-auto --agree-tos --renew-by-default --email  --rsa-key-size 4096 -d deinedomain.tld -d www.deinedomain.tld -d mail.deinedomain.tld -d autodiscover.deinedomain.tld -d autoconfig.deinedomain.tld -d dav.deinedomain.tld certonly

Wenn der Mailserver nicht genutzt wird:
./letsencrypt-auto --agree-tos --renew-by-default --email  --rsa-key-size 4096 -d deinedomain.tld -d www.deinedomain.tld certonly

Die E-Mail ist wichtig, damit man bei Verlust seine Daten wiederbekommt.

Tipps und Tricks:

HPKP:

Wer sein Projekt fertig geplant hat und weiß, welche Domains und Subdomains über den Webserver laufen sollen, kann seine Zertifikate zusätzlich noch mit HPKP (HTTP Public Key Pinning) absichern. Erklärung weiter oben im Thread!

Sobald das Zertifikat erstellt ist, kann man den Pin aus dem Zertifikat, dem privaten Schlüssel oder dem CSR generieren. Mit dem folgenden Befehl wird der Pin anhand des Zertifikats generiert:

Code:

openssl x509 -pubkey < /etc/letsencrypt/live/domain.tld/fullchain.pem | openssl pkey -pubin -outform der | openssl dgst -sha256 -binary | base64

Anschließend muss die Nginx Config für die entsprechende Domain überarbeitet werden. Wenn man nach der Installation nichts verändert hat, befindet sich die Config für die jewielige Domain hier:

Code:

/etc/nginx/sites-available/domain.tld.conf

Der Pin kommt dann in das erste 'pin-sha256=' Feld ein, also so:

Code:

add_header Public-Key-Pins 'pin-sha256="HIERDENPINEREIN"; pin-sha256="--"; max-age=5184000; includeSubDomains';

Es funktioniert auch mit einem Pin, man kann für den zweiten aber auch einfach einen Pseudopin generieren oder sich ein zweites Zertifikat zulegen (unbedingt bei einer anderen Zertifizierungsstelle, bei ein und der selben funktioniert das nicht).

Code:

openssl rand -base64 32

Der Pin kommt dann einfach in das zweite Feld.

Über Anregungen und Verbesserungsvorschläge freue ich mich jeder Zeit!

Viele Grüße
Zypr

Zypr · 03/07/2013, 14:31

Hier findet man die alte Version:

Spoiler

Zypr · 03/27/2013, 14:38

.

Zypr · 08/04/2013, 20:56

.

tidust · 08/05/2013, 19:32

das gleiche gibt es hier auch

Zypr · 08/05/2013, 21:19

Gut erkannt 007, das bin auch ich.

Grüße

leonor · 10/28/2013, 22:53

Moin, ein sehr schönes tutorial!

Eine sache würde ich aber anders machen, SSH login via schlüssel paare und dann login via User + PW ausschalten.

Zypr · 10/28/2013, 23:55

Hey, danke für dein Feedback! Kann man natürlich auch machen, aber egal mit welcher Methode - in diesem Leben kommt da niemand durch, wenn man es mit fail2ban absichert.

Gruß

Zypr · 11/24/2013, 19:38

Großes Update auf Debian 7 Wheezy! Der perfekte Server mit allem was dazugehört!

Schaut euch den ersten Post einfach mal an :-)

Grüße

マリブ · 11/25/2013, 17:13

Quote:

Originally Posted by .interp

Großes Update auf Debian 7 Wheezy! Der perfekte Server mit allem was dazugehört!

Schaut euch den ersten Post einfach mal an :-)

Grüße

Was soll man dazu groß sagen, einfach ein Perfektes Tutorial, für neueinsteiger in Linux.

Greez iMalibu.

~~kenshin52~~ · 11/26/2013, 14:33

Super update

Daumen hoch für ein ausführliches Tutorial, was auch noch mit der Zeit gepflegt wird.

4bedah · 12/29/2013, 20:14

Super Tutorial ... hat soweit auch alles gefunzt wäre da nicht das froxlor-update gewesen!

beim Punkt: PHP-FPM für Froxlor aktivieren und konfigurieren
ist noch eine neue Option hinzu gekommen: FastCGI IPC Verzeichnis : /var/run/nginx/ (default)
hier muss noch das Verzeichniss angelegt werden: mkdir -p /var/run/nginx

DANKE nochmal für den freundlichen Support!

TommyLikesInvasion · 12/29/2013, 22:41

Quote:

Originally Posted by 4bedah

Super Tutorial ... hat soweit auch alles gefunzt wäre da nicht das froxlor-update gewesen!

beim Punkt: PHP-FPM für Froxlor aktivieren und konfigurieren
ist noch eine neue Option hinzu gekommen: FastCGI IPC Verzeichnis : /var/run/nginx/ (default)
hier muss noch das Verzeichniss angelegt werden: mkdir -p /var/run/nginx

DANKE nochmal für den freundlichen Support!

Danke, da wollte ich auch nochmal nachhaken! Ich kann leider seit einem System-Restart (und nach erstellen deines o.g. Verzeichnisses) nicht auf das Froxlor-CP zugreifen: "502 Bad Gateway".

Wer ne Idee?

//EDIT:
Ich könnte natürlich auch Hilfestellung leisten. Errorlog seht ihr unten, schlau werde ich daraus aber trotzdem nciht ganz:

Code:

2013/12/29 22:42:29 [crit] 3520#0: *9 connect() to unix:/var/run/nginx/froxlor.panel-SUB.DOM.AIN-php-fpm.socket failed (2: No such file or directory) while connecting to upstream, client: 85.XX.XX.XX, server: SUB.DOM.AIN, request: "GET /froxlor/ HTTP/1.1", upstream: "fastcgi://unix:/var/run/nginx/froxlor.panel-SUB.DOM.AIN-php-fpm.socket:", host: "SUB.DOM.AIN"

Domain und meine IP hab ich aus Gründen der Privatssphäre entfernt.

Zypr · 12/30/2013, 00:56

Ich überarbeite das mal die Tage, das neue Froxlor Update scheint das wohl alles zerschossen zu haben.

Quote:
Originally Posted by TommyLikesInvasion
Danke, da wollte ich auch nochmal nachhaken! Ich kann leider seit einem System-Restart (und nach erstellen deines o.g. Verzeichnisses) nicht auf das Froxlor-CP zugreifen: "502 Bad Gateway".

Wer ne Idee?

//EDIT:
Ich könnte natürlich auch Hilfestellung leisten. Errorlog seht ihr unten, schlau werde ich daraus aber trotzdem nciht ganz:
Code:
2013/12/29 22:42:29 [crit] 3520#0: *9 connect() to unix:/var/run/nginx/froxlor.panel-SUB.DOM.AIN-php-fpm.socket failed (2: No such file or directory) while connecting to upstream, client: 85.XX.XX.XX, server: SUB.DOM.AIN, request: "GET /froxlor/ HTTP/1.1", upstream: "fastcgi://unix:/var/run/nginx/froxlor.panel-SUB.DOM.AIN-php-fpm.socket:", host: "SUB.DOM.AIN"
Domain und meine IP hab ich aus Gründen der Privatssphäre entfernt.

Nachdem der Ordner angelegt ist den Cronjob erneut per Hand ausführen und anschließend den Dient neustarten:

Code:

/usr/bin/php5 -q /var/www/htdocs/froxlor/scripts/froxlor_master_cronjob.php --force

Code:

service php5-fpm restart

Grüße

TommyLikesInvasion · 12/30/2013, 02:25

Quote:
Originally Posted by .interp
Nachdem der Ordner angelegt ist den Cronjob erneut per Hand ausführen und anschließend den Dient neustarten:
Code:
/usr/bin/php5 -q /var/www/htdocs/froxlor/scripts/froxlor_master_cronjob.php --force
Code:
service php5-fpm restart
Grüße

Hmm, danke - klingt nachvollziehbar. Allerdings spielt jetzt php5-fpm rum und ich kann es mir nicht erklären...

Code:

[FAIL] Restarting PHP5 FastCGI Process Manager: php5-fpm failed!