Beiträge von x1lor

  • Eigener Mailserver

    Zitat von ichhalt033

    Welches Produkt benötige ich, die das können?

    Wenn du definitiv deinen eigenen Mailserver hosten willst, brauchst du einen VPS oder Root-Server.


    Nur würde ich mich davor erstmal ausführlich mit der Materie beschäftigen. Sprich - lernen einen Server abzusichern, usw.


    Falls das zeitlich nicht drin ist, würde ich einfach bei einem Webhosting Produkt bleiben und mich einfach auf den damit verbundenen Mailserver verlassen.

  • Backbone / Routing Q&A

    Ebenfalls Probleme.


    Meines Wissens nach gibt es momentan auch keine Störung am DE-CIX.

    Dann wäre davon nämlich nicht nur Anexia betroffen.


    Jedoch ist genau das der Fall.

    Selbst mit meiner geschäftlich genutzten Leitung erreiche ich konstant und sauber 10Gbits an alle anderen Server quer durch Europa (Paris; Warschau; Helsinki).


    Mit Netcup bzw. Anexia erreiche ich stellenweise nur 600KB/s...

    Das ist unzumutbar.

  • Dokumentenstamm lässt sich nicht mehr ändern - Wordpress-Anwendung schlug fehl - WordPress lässt sich nicht mehr löschen

    Ich habe keine Ahnung wie das mit dem Toolkit funktioniert, aber eventuell wäre es doch mal interessant zu klären, wieso das Tool der Ansicht ist, dass die Datenbank noch verwendet wird, wenn diese doch angeblich nur mit dieser zweiten, versehentlich installierten, Instanz zusammenhängt.


    Ohne Zugang kann man nur spekulieren, was hier falsch läuft.


    Ich gehe mal davon aus, dass das Toolkit die Datenbank gleich mit erstellt. In dem Fall, könntest du vielleicht mal versuchen die Datenbank manuell (entweder über Plesk oder phpMyAdmin) zu entfernen und dann nochmal die Deinstallation über das Toolkit versuchen.


    Aber das jetzt mal nur als bescheidene Idee.

    Habe noch nie Webhosting irgendwo oder irgendwie gebucht.

  • Anhaltende/sporadische Probleme mit Domains/DNSSEC

    Auch ein Danke an Andi22.

    Kannte die auch noch nicht, sieht auf alle Fälle sehr gut gemacht aus.


    mfnalex mein Rat hatte die Probleme schon vorhergesehen - leider.

    Solange du zumindest mit den Preisen für die Domains bei netcup zufrieden bist, kannst du die Domains trotzdem hier lassen und einfach die NS ändern (vorausgesetzt Netcup unterstützt DS Records).


    Mache ich eigentlich immer so.

    Egal wo ich die Domains kaufe.


    Habe den Vergleich mit dem Taxifahrer schon verstanden. Solange ich aber auch für meinen Chauffeur nichts bezahlen muss, ist es mir egal wer mich fährt.

  • Anhaltende/sporadische Probleme mit Domains/DNSSEC

    Das ist mir klar und da gebe ich dir 100% recht.

    Aber ganz ehrlich, warum sollte ich etwas langsameres und nicht stabiles benutzen, wenn jemand die gleiche Dienstleistung umsonst und besser erfüllt?


    Zumindest temporär würde ich es dir nahe legen, bis Netcup endlich eine Lösung findet.

    Meine Kunden würden mich jedenfalls steinigen bei solchen Ausfällen.


    Um nochmal auf das eigentliche Problem zurückzukommen:

    https://forum.netcup.de/anwend…ghlight=dnssec#post153660


    Ist bald ein Jahr her...

  • Anhaltende/sporadische Probleme mit Domains/DNSSEC

    Damit so was nicht passiert - nutzt einfach alternative DNS Server.

    Ich will Netcup nicht schlecht reden, aber ich bezweifle, dass AnyCast DNS Server vorhanden sind.


    Und ja, hier wurde ja oft CloudFlare kritisiert, aber die Auflösungs-Zeiten sind beinahe unschlagbar. Einfach Proxy ausschalten und nur die DNS-Server nutzen - 1-2ms Auflösung weltweit. Dazu noch DNSSEC Support, was will man mehr?


    Was daran noch besser ist - selbst wenn man die Domain umzieht, bleibt die Konfiguration erhalten und man muss sich nicht die Mühe machen die bestehende Konfiguration beim neuen Anbieter einzutragen.

  • NGINX-QUIC + Brotli + Google PageSpeed

    Zitat von whoami0501

    Was nginx betrifft - das sind solche Sachen, bei denen ich keine Experimente machen würde. Sofern die nginx Maintainer es noch nicht implementiert haben, würde ich auch keine Klimmzüge machen, um es rein zu bekommen.

    Die genutzte Repo ist eine offizielle von NGINX. Einfach mal dazu einlesen:

    https://www.nginx.com/blog/our…uic-http-3-support-nginx/


    tab NGINX ist wesentlich schneller bei statischen Inhalten und hoher Last (Stichwort Concurrency).

    Die Performance der dynamischen Inhalte (ich gehe in der Annahme aus, dass wir hier primär über PHP reden) hängt schlichtweg von PHP-FPM ab, womit NGINX wiederum nichts am Hut hat.


    Vor einigen Jahren soll das wohl nicht so das Gelbe vom Ei gewesen sein, jedoch ist FPM mittlerweile stark verbessert worden.


    Deshalb - das erste was man machen sollte, ist es die Anzahl der Startserver für FPM in der www.conf hochzusetzen. Das verbessert die TTFB (Time to first byte) enorm.


    Ich komme mit obigen Stack und ein paar weiteren kleineren Spielereien auf eine TTFB von konstant unter 50ms, im Idealfall habe ich schon 30ms gemessen (Shopware 6).

  • NGINX-QUIC + Brotli + Google PageSpeed

    Zitat von frank_m

    Eigentlich kann man nur HTTP/3 und Chrome verwenden.

    Geht bei Firefox, Edge und Chrome für Android mittlerweile auch:

    https://caniuse.com/http3


    Es wird also langsam interessanter.


    Zitat von tab

    Da sind mir zu viele "-dev" dabei. aber wird ja sowieso jeden Monat eine neue Sau durchs Dorf getrieben ;(. Und statische Dateien sind sowieso nicht wirklich das große Problem. Bei manchen Hostern wäre man ja schon froh, wenn man mittlerweile HTTP/2 hätte. Aber immerhin scheinen ja wenigstens gut 70% der verwendeten Browser mittlerweile HTTP/3 zu unterstützen.

    Das muss so, schließlich compilen wir hier.


    Worum man sich aber tatsächlich kümmern muss, ist NGINX-QUIC regelmäßig zu aktualisieren.

    Hierfür führst du das obige Skript einfach nur wieder aus und das wars.

    Aktuell ist der Tree noch nicht für den produktiven Einsatz freigegeben (laut NGINX wird das ganze dann in "Mainline" integriert).


    Mit kleineren Anpassungen an der NGINX und PHP-FPM Config kommst du ohne weiteres auf die gleiche Performance wie mit Apache MPM.

    Das gibt sich also nicht viel (da kommt es einfach mehr auf FPM an).


    Aber wie gesagt - wirklich für den produktiven Einsatz ist es offiziell noch nicht, deshalb abwarten.

    Ansonsten, falls es unbedingt "production ready" sein muss, mal Caddy anschauen.


    Habe damit noch nicht so viel Erfahrung um ehrlich zu sein, aber vom Grundprinzip her klingt das ganze nicht schlecht.

  • NGINX-QUIC + Brotli + Google PageSpeed

    Vielleicht ist es keine eine Frage, aber vielleicht hat der ein oder andere mal mit dem Gedanken gespielt QUIC bzw. HTTP/3 auszuprobieren.


    NGINX


    Natürlich brauchen wir noch ein entsprechendes Systemctl Skript (z.B. unter "/lib/systemd/system/"):

    Danach nochmal kurz Systemctl reloaden und NGINX starten:

    Code
    systemctl daemon-reload
systemctl enable nginx
systemctl start nginx


    Eure entsprechenden Konfigurationsdateien passt ihr wie folgt an:

    Code
    listen 443 http3 quic reuseport;
listen 443 ssl http2;

add_header alt-svc 'h3-27=":443"; ma=86400, h3-28=":443"; ma=86400, h3-29=":443"; ma=86400, h3=":443"; ma=86400';
add_header Alt-Svc 'quic=":443"';
add_header QUIC-Status $quic;

quic_retry on;
ssl_early_data on;


    Hinweis

    Leider ist es notwendig BoringSSL für QUIC-Support zu nutzen, weshalb OCSP Stapling nicht unterstützt wird.

    Es gibt zwar einen Patch auf GitHub, jedoch habe ich noch keinen Versuch unternommen diesen anzuwenden.

  • nginx konfiguration mit lets encrypt und subdomain

    Ganz so einfach sieht die Wahrheit einfach nicht aus. Es hat sehr gute Gründe warum NGINX "Industriestandard" ist.

    Für kleine bis mittelgroße Seiten erfüllt Apache durchaus einwandfrei seinen Dienst.


    Aber versuch mal mehrere 10.000 Verbindungen simultan mit Apache abzuwickeln. Das ist alles andere als ressourceneffizient.


    Synthetische Benchmarks sind meiner Meinung nach zu "statisch", um zu sagen der und der Webserver ist schneller.

    Dennoch - NGINX ist Apache zumindest in dem Thema Effizienz klar und eindeutig überlegen, was sich auch in den hohen Marktanteilen widerspiegelt.

  • Kaufberatung - Server

    Zitat von aRaphael

    Ach? Und das ist nichts?

    Das ist so das was mein privater Internetanschluss hergibt.

    Ich komme im Download immerhin (jetzt erstmalig) auf 1500Mbits, Upload taumelt bei ca. 450-900Mbits.

    Hier nochmal 3 Messungen (SWU TeleNet GmbH; ID 1338):

    http://www.speedtest.net/result/11989641670.png

    http://www.speedtest.net/result/11989643369.png

    http://www.speedtest.net/result/11989644232.png


    Vergleichsserver - Standort Moskau:

    In 3 Messungen Konstant: 970-1000Mbits (Up- & Download)

    Messungen an den gleichen Standort wie oben - um die 700-800Mbits.


    Edit:

    Habe gerade gesehen, dass es ein KVM Update gab.

    Werde nachher mal neustarten, vielleicht bringt das was.

  • Kaufberatung - Server

    Einrichten der "Umgebung"

    Sollte auch das geklappt haben, wird es Zeit unsere Awendungen zu installieren.

    Ich mache das immer ganz bequem unter /home und lege für jedes Projekt einen Ordner an:

    - example

    - example.com/public_html

    - test.example.com/public_html


    Andere nutzen den "standardmäßigen" Pfad "/var/www/".

    Egal welche Variante du wählst - hauptsache du bleibst bei einer Version.

    Das hilft Chaos zu vermeiden.


    In den Ordner "public_html" lädst du dann die entsprechenden Dateien hoch.

    Nach dem Upload machst du dann innerhalb von public_html:

    Code
    chown -R www-data:www-data *

    Damit ändern wir den Besitzer unserer Dateien auf "www-data".

    Vielleicht magst du dich an dieser Stelle fragen, wieso das so wichtig ist.

    Der Grund ist ganz einfach - es gibt die Möglichkeit verschiedene Berechtigungen für Nutzer und Gruppen zuzuweisen.

    Vielleicht hast du mal was von "sudo" gehört oder gelesen, falls nicht:

    https://acloudguru.com/blog/en…mmands-for-beginners-sudo


    Im Endeffekt geht es uns genau darum.

    Wir wollen niemals, dass irgendwelche öffentliche Anwendungen irgendwelche Privilegien haben.

    Sie sollten nur auf Ihre eigenen Ordner zugreifen können und auch nicht in der Lage sein Befehle auzuführen.

    "www-data" erfüllt genau diese Bedingungen.


    Vielleicht merkst du an dieser Stelle auch wie "gefährlich" der root Zugang wirklich ist.

    Du könntest zum Beispiel deinen kompletten Server mit nur einem Befehl in die Tonne hauen, also lass dir Zeit und prüfe insbesondere Löschbefehle zweimal!


    Nachdem das jetzt geklärt und die ersten Dateien hochgeladen sind, wird es Zeit unseren Webserver darüber zu informieren.


    NGINX Basiskonfiguration

    Im Ordner "/etc" findest du in der Regel alle Konfigurationsdateien deiner Dienste.

    Von MariaDB bis SSH ist hier alles vertreten. Wir wollen uns jetzt mal NGINX - also "/etc/nginx" - anschauen.

    Öffne die "nginx.conf" und füge dort das hier ein:

    Ein paar Erklärungen.

    "user"

    NGINX läuft wie unsere Dateien als www-data.

    Würden wir einen anderen User wählen, könnte es zu Berechtigungsproblemen kommen.


    "worker_processes"

    http://nginx.org/en/docs/ngx_c…ule.html#worker_processes

    Du kannst diesen Wert auch erstmal auf "auto" stellen.


    "worker_connections"

    Wieviele gleichzeitige Verbindungen du pro Worker akzeptieren willst.


    "server_tokens"

    Hierbei geht es darum, dass NGINX die Versionsnummer versteckt.

    Die Idee dahinter ist, dass ein Angreifer nicht genau weiß welche Version du nutzt.


    "include"

    Hierdurch verweisen wir darauf noch weitere Konfigurationsdateien zu berücksichtigen.

    Eine davon schauen wir uns gleich mal an.


    NGINX - example.com (WordPress)

    Wir legen also unter "/etc/nginx/sites-enabled" eine Datei an.

    Ich nenne diese immer so wie die Domain heißt. In diesem Beispiel also einfach "example.com".

    Für WordPress sieht diese wie folgt aus:

    "listen"

    Auf welchem Port soll die Verbindung eingehen.

    80 ist dabei der Standardport für HTTP

    443 ist für HTTPS


    "server_name"

    Hier gehört der dazugehörige Domainname rein.

    Solltest du übrigens Wildcards nutzen, kannst du auch "*.example.com" schreiben.


    "root"

    Damit ist der Webroot gemeint, also das Hauptverzeichnis in dem unsere Dateien liegen.


    "PHP-FPM"

    Kleine Übung für dich.

    Versuch mal WordPress unter PHP 7.4 laufen zu lassen.


    Anschließend überprüfst du ob deine Konfigurationen in Ordnung sind:

    Code
    nginx -t

    Falls ja, kannst du NGINX entweder neustarten:

    Code
    service nginx restart

    oder reloaden:

    Code
    service nginx reload

    Deine Website sollte jetzt erreichbar sein.


    Themen an denen du weitermachen solltest

    Natürlich war es das jetzt noch lange nicht.

    Du könntest und solltest dir vor allem noch folgendes anschauen bzw. überlegen:

    - Update-Routine (bei mir einmal pro Tag; über Sicherheitslücken bin ich dank Mailinglisten relativ zügig informiert)

    - Daten deines Webhostings importieren (insbesonderen die Datenbanken)

    - SSL bzw. TLS (ohne HTTPS geht heute "nichts" mehr -> Google will es) -> Let's Encrypt ;)

    - Lynis

    - ClamAV (ignoriere den Teil mit der grafischen Öberfläche)

    - Firewall

    - Fail2Ban (vor allem um SSH abzusichern)

    - Live Kernel Patching

    - MariaDB Tuning (mysqltuner)

    - PHP-FPM Tuning

    - NGINX Hardening


    Hinweise zu apt

    Während der Einrichtung dürfte klar geworden sein, wie du Pakete installierst und das System aktualisierst, doch es gibt weitere Befehle die wichtig sind:

    - apt remove PAKETNAME -> Paket deinstallieren

    - apt purge PAKETNAME -> Löscht alle Konfigdateien

    - apt autoclean -> Löscht lokale Paketversionen die nicht mehr heruntergeladen werden können (wurden aus Repo entfernt oder neuere Version ist verfügbar)

    - apt autoremove -> Löscht Pakete die nicht mehr benötigt werden (wurden z.B. mal installiert um Abhängigkeiten zu erfüllen)


    Gerade die letzten beiden Befehle willst du von Zeit zu Zeit ausführen.

  • Kaufberatung - Server

    Basics

    - mkdir ordername -> erstellt neue Ordner

    - cd /PFAD/ZUM/ORDNER -> damit kannst du dich zu anderen Ordner innerhalb von SSH bewegen

    - ls -> Ordnerinhalt anzeigen

    - cp QUELLE ZIEL -> Datei kopieren

    - mv QUELLE ZIEL -> Dateien verschieben, aber auch umbennen


    Wahl des Betriebssystems

    Fangen wir erstmal bei der Wahl des Betriebssystems an.

    Persönlich nutze ich Ubuntu Server ganz gerne - in der Regel ist die Dokumentation hier besonders üppig.

    Dementsprechend würde ich das zum Einstieg auch empfehlen.


    Erste Verbindung

    Nachdem du die Installation im SCP abgeschlossen hast, willst du dich mit dem Server verbinden.

    Unter Linux erfolgt dies über ein Terminal - SSH genannt.

    Hierfür brauchst du "PuTTY".


    Ich lade mir dort immer die "Alternative binary files" herunter und platziere diese an einem beliebigen Ort.

    Anschließend erstelle ich mir eine Verknüpfung und ändere das "Ziel" wie folgt ab:

    -ssh root@SERVERIP -P 22 -pw DEINPASSWORT


    Damit verbindet sich PuTTY direkt mit deinem Server.

    Bei der ersten Verbindung wirst du diese gesondert bestätigen müssen (einfach auf Ja klicken).

    Es geht hierbei darum den Host Key in deiner Registry zu speichern und somit dem Server zu vertrauen.


    Nachdem das erledigt ist, bist du "drin".


    System-Update

    Das erste was du machen willst, ist es die Paketquellen zu aktualisieren und bereits installierte Pakete zu upgraden.

    Dies macht man so:

    Code
    apt updateapt upgrade

    "apt" ist hierbei der Paketmanager.

    Im übrigen lassen sich mehrere Befehle auch in einer Zeile zusammenfassen, dies erfolgt durch "&&" und sieht z.B. so aus:

    Code
    apt update && apt upgrade

    Eventuell kann es notwendig sein den Server zu rebooten (vor allem bei Kernel Updates!).

    Dies kannst du jedoch auch am Ende der Anleitung erledigen, dann siehst du auch ob die Dienste einen Neustart "überleben".

    SSH Hardening

    Das erste was ich mache, ist es den Zugang zu SSH zu erschweren.

    Dies kannst du auf vielfältige Art und Weise machen.

    Manche User präferieren es sich nur über Keys anzumelden, wieder andere - mich eingeschlossen - ziehen es vor immer auf ihren Server zugreifen zu können.

    Als "Basis" empfehle ich es erstmal den Standard-Port von SSH von 22 auf einen beliebigen Port zu wechseln.

    Achtung, folgende Ports werden von vielen Diensten benutzt:

    - 21

    - 23

    - 25

    - 53

    - 80

    - 143

    - 443

    - 465

    - 587

    - 3306

    - 8080


    Nachfolgend setzen wir SSH z.B. einfach mal auf "198".

    Hierfür führst du folgenden Befehl aus:

    Code
    nano /etc/ssh/sshd_config

    Dir sollte "Port 22" sofort ins Auge stechen.

    Die 22 auf 198 ändern und darauf achten, dass die Zeile nicht auskommentiert ist (es darf kein "#" davor stehen).

    Einmal "STRG+X" drücken und mit "Y" bestätigen.


    Anschließend SSH neustarten:

    Code
    service ssh restart

    Du kannst jetzt versuchen dich über den Port 198 zu verbinden.

    Hierfür kannst du die zuvor genutzten Paramter der Verknüpfung anpassen.


    Wir gehen jetzt noch einen Schritt weiter und fügen eine zweite "Schicht" zur Absicherung hinzu.

    Vielleicht kennst du das schon von deinem Mail-Provider oder Amazon - 2FA.

    Schau dir dazu folgende Anleitung an:

    https://ubuntu.com/tutorials/configure-ssh-2fa#1-overview


    Kleiner Tipp - ich nutze Authy, damit meine 2FA Codes immer abgesichert sind.


    Solltest du den Login mit Schlüsseln bevorzugen, schau dir mal diese Anleitung an:

    https://www.server-world.info/…os=Ubuntu_20.04&p=ssh&f=4


    Im übrigen - du kannst Dateien zwischen deinem Server und deinem Rechner ganz bequem mit "WinSCP" transferieren.


    Damit hast du erstmal die Grundlagen zur Absicherung deines SSH Terminals erledigt.

    Natürlich könnte man noch mehr Arbeit betreiben, aber das würde hier den Rahmen sprengen.


    Als nächstes können wir tatsächlich damit anfangen dein "Stack" für deine Web-Anwendungen zu erstellen.


    MariaDB

    Beginnen wir mit dem SQL Server.

    Hierfür nutzen wir MariaDB, du musst eigentlich nur die Anleitungen auf dieser Seite befolgen:

    https://downloads.mariadb.org/…=host-europe&version=10.6


    Anschließend führst du diesen Befehl aus:

    Code
    mysql_secure_installation

    Lies dir die folgenden Abfragen besonders aufmerksam durch!

    Du willst keine "anonymen" User oder Testdatenbanken.

    Ebenfalls willst du auf GAR KEINEN FALL, dass sich jemand außerhalb von "localhost" als root User auf deinem Datenbankserver anmeldet.


    Nun fragst du dich vermutlich wie du auf deinen Datenbankserver zugreifen kannst.

    Hierfür empfiehlt sich "HeidiSQL".

    Du wählst für deine Verbindung "MariaDB or MySQL (SSH Tunnel)" aus.

    Hinweis: HeidiSQL kann kein 2FA, eventuell müsstest du diesen temporär deaktivieren oder du gehst von Anfang an auf Keys.


    Du kannst dort deine Benutzer und Datenbanken beliebig anlegen.

    Achte nur darauf, dass du den Benutzern nur die entsprechenden Zugriffsrechte auf die Datenbanken gibst und NICHT globale Rechte.


    NGINX

    Als nächstes brauchen wir einen Webserver sowie Interpreter für unsere Anwendungen (ich gehe mal davon aus, dass du nur PHP brauchst).

    Ich verwende hierfür NGINX.

    Dieses kannst du über diese Repo beziehen:

    http://nginx.org/en/linux_packages.html#Ubuntu


    Idealerweise willst du die "stable" nutzen.

    Alternativ kannst du mithilfe meines Anhangs immer die aktuellste Version von NGINX und OpenSSL

    zusammen mit Google PageSpeed selbst compilen (etwas zu viel für den Einstieg).


    PHP-FPM

    Bei PHP-FPM handelt es sich um besagten Interpreter.

    PHP Skripte werden nämlich zur Laufzeit compilet und sind somit "dynamisch".

    Ruft jemand z.B. deine WordPress Seite auf gibt NGINX die Anfrage an PHP-FPM weiter.


    Auch hierfür richten wir zunächst wieder eine Repo ein:

    Code
    apt install software-properties-common
add-apt-repository ppa:ondrej/php


    Je nachdem welche PHP-Version deine Anwendungen benötigen, musst du die nachfolgenden Befehle anpassen.

    Nachfolgend die Installation von PHP 8.0 und 7.4:

    Code
    apt install php7.4-fpm php7.4-mysql php7.4-xml php7.4-mbstring php7.4-curl php7.4-gd
apt install php8.0-fpm php8.0-mysql php8.0-xml php8.0-mbstring php8.0-curl php8.0-gd


    Zwischenschritt

    Um sicher zu gehen, dass alle unsere Dienste nach einem Reboot von alleine starten, führen wir jetzt folgende Befehle aus.

    Code
    systemctl enable mysql
systemctl enable nginx
systemctl enable php7.4-fpm
systemctl enable php8.0-fpm

    Grundsätzlich sollte das bei den meisten automatisch erfolgen, aber sicher ist sicher.

    Wir starten jetzt auch einfach mal den Server mit folgendem Befehl neu und schauen, ob die Dienste wie gewünscht funktionieren:

    Code
    reboot