Kaufberatung - Server

  • Im Endeffekt wird hier so getan als wäre ein Server eine tödliche "Waffe". Könnte man auch über ein Auto behaupten, was man in eine Menschenmenge fährt - nur überleg mal wo du Autofahren gelernt hast.

    Ich stimme dir im Prinzip beim ganzen Beitrag zu, aber das Risiko bzw. besser die Verantwortung eines öffentlich erreichbaren Servers sollten nicht unterschätzt werden. Da kenne ich persönlich eine Person, die bei einem Hoster eine kleine VM gemietet hat und ein paar Wochen später stand direkt das BKA vor der Tür. So etwas ist keine angenehme Erfahrung, durfte ich aus den Erzählungen meines Kollegen schließen.

    Das soll jetzt keine blanke Panikmache o.ä. sein - es sollte den Menschen lediglich bewusst sein, was eben doch auch alles passieren kann.

  • Ich habe den TE nicht als DAU abgestempelt. Wenn aber jemand offen und ehrlich (was ich auch gut finde) sagt, das er ziemlich unbefleckt ist, dann sind "Trockenübungen" IMHO nicht verkehrt. Meine Beiträge sind bloße Panikmache? Gut zu wissen. Es stehen da Praxisdaten im Raum (selbst wenn das nur eine Podologie Praxis ist, sind das personenbezogene Daten).
    Ein Server ist keine tötliche Waffe. Es ist schlimmer, man weiss garnicht was man damit anstellen kann. Bei einem Auto muss du vorher auch einen Führerschein machen, wo du die Grundlagen lernst.

    Mit einfach mal ein paar Skripten und Configs ist ihm geholfen? Dann weiss er trotzdem nicht was er macht? Wenn man das lernen will, dann kann man doch ruhig in einer gesicherten Umgebung anfangen, auch mit deinen Skripten. Wenn man das JETZT braucht, dann holt man sich professionelle Hilfe dazu.
    Klar übertreibe ich mit Aussagen wie "Ich schlafe mal eben eine Nacht drüber und das Dingen ist auf einmal eine Spamschleuder" aber das kam oft genug schon vor. Ich hatte genug Anrufe wie: Wir können keine Mails versenden, da ist etwas kaputt (ach der Provider hat euch wegen Abuse Meldungen das gesperrt. Zum Glück schnell, weil da noch 10k+ in der Queue waren).

    Und ja, ich kenne persönliche Fälle wo eine HD durchgeführt wurde, soviel Fälle von gekaperten Servern die gemeldet wurden (wobei wir hier im Rahmen der Arbeit die Melder beim LKA waren).

  • Also der Vergleich mit dem Autofahren hinkt natürlich erst mal. Der Fahrlehrer sitzt neben dir und hat die Verantwortung für alles was passiert. Deswegen hat er auch einen eigenen Pedalsatz um z.B. jederzeit bremsen zu können. Vorgefertigte Skripte, egal von wem, sind kein Ersatz dafür. Ein Skript von irgendjemand hier ist auch nicht garantiert besser/sicherer als das Setup-Skript des nächstbesten Panels. Ein Auto und auch ein Server können gefährliche Waffen sein. Ordentliche Schäden kann man jedenfalls mit beiden anrichten, ob gewollt oder nicht.


    Ich sage nicht, dass man es nicht schaffen kann, als Anfänger einen Server nach dem "state of the art" abzusichern. Aber es ist zumindest die Gefahr gegeben, dass, durch fehlendes Wissen gepaart mit Ungeduld, Risiken eingegangen werden, die man besser nicht eingehen sollte. Da wird schon mal die Firewall geöffnet oder ein Dateirecht auf 777 gesetzt, "nur um mal eben zu checken ob es prinzipiell schon funktioniert". Man darf nie vergessen, dass eine VM auf einem lokalen PC im heimischen LAN in aller Regel durch den Router einem großen Teil der unablässigen Angriffsversuche von "außen" auf jede öffentliche IP-Adresse gar nicht erst ausgesetzt ist. Wenn man es nicht selbst gesehen hat macht man sich keine Vorstellung, was da ab der ersten Sekunde auf einen frisch von netcup (und natürlich auch anderen Anbietern) bereitgestellten vServer an Verbindungsversuchen auf den "gängigen" Ports hereinprasselt! Wäre der vServer nicht schon halbwegs sicher voreingestellt (immerhin ist das voreingestellte root-Passwort nicht "123456", sondern hat immerhin 15 Stellen, allerdings keine Sonderzeichen), könnte es leicht passieren, dass, wenn man am Morgen den vServer bestellt und ihn abends nach der Arbeit einrichten will, dieser bereits gehackt ist. Denn leider werden vServer hier immer noch in gestartetem Zustand ausgeliefert, sofern sich das nicht in allerletzter Zeit geändert hat. Ein völlig unnötiges Risiko, auch wenn es vielleicht nicht besonders groß ist. Ein gestoppter Server startet bei Bedarf innerhalb weniger Sekunden. Wenn ich nicht sofort Zeit habe, einen neuen Server abzusichern, ist meine erste Aktion nach Erhalt der "Bereitstellungsbenachrichtigung", den Server zu stoppen. Als Anfänger sollte man sich in jedem Fall zumindest erst mal über die vordringlichen Absicherungsmaßnahmen schlau machen und diese dann zügig(!) umsetzen, bevor man mit dem Server rumspielt oder weitere Software installiert.

  • 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


  • 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.

  • 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.