Sicherheit SCP | Anfänger

  • Hallo zusammen,


    zunächst mal vorweg, ich bin blutiger anfänger und setze gerade meinen ersten VPS mit Ubuntu 20.04 auf.

    Dabei macht man sich halt so seine Gedanken zur Sicherheit.

    Jetzt wollte ich mal Fragen wie ihr das SCP beim Thema Sicherheit einordnet. Das ist ja nur mit einem PW (nicht 2FA) gesichert. Wenn ich das richtig verstehe kann jmd durch ausspähen dieses einen Passworts und der zugehörigen Benutzerkennung root Zugriff auf alle meine Server erlangen, durch die Möglichkeit den Server Abzuschalten und ein neues root-PW zu vergeben. Kann man das irgendwie absichern, oder sehe ich das zu kritisch?


    Viele Grüße

    Simon

    1. 2FA im CCP aktivieren: https://www.netcup-wiki.de/wik…thentifizierung_.282FA.29
    2. Und danach den Sicherheitsmodus im SCP aktivieren: https://www.netcup-wiki.de/wik…nel_(SCP)#Einstellungen_3

    Danach ist ein direkter Login ins SCP nicht mehr möglich! Dieser muss dann übers CCP mit den Autologin-Buttons auf der Hauptseite erfolgen und ist somit mittels 2FA abgesichert.

    1. 2FA im CCP aktivieren: https://www.netcup-wiki.de/wik…thentifizierung_.282FA.29
    2. Und danach den Sicherheitsmodus im SCP aktivieren: https://www.netcup-wiki.de/wik…nel_(SCP)#Einstellungen_3

    Danach ist ein direkter Login ins SCP nicht mehr möglich! Dieser muss dann übers CCP mit den Autologin-Buttons auf der Hauptseite erfolgen und ist somit mittels 2FA abgesichert.

    Ah, den hatte ich noch nicht gefunden, danke. 2FA im CCP ist schon aktiv.



    2FA aktivieren, Passwort Tresor nutzen. Hast du dir über die Sicherheit deines VPS schon Gedanken gemacht? Schon einmal "Trockenübungen" (lokale VM usw.) gemacht?

    Die Sicherheit des VPS an sich versuche ich gerade zu verbessern. Ich bin mir z.B. nicht sicher wie gut die VNC von Netcup im Vergleich zu SSH ist. mir würde es reichen den SSH dienst auf dem Server komplett zu deaktivieren, wenn die VNC von Netcup über das SCP ausreichend Sicherheit bietet. alternativ würde ich SSH mit Zertifikatlogin nutzen, dann kommt man über das SCP halt nicht mehr rein, außer man setzt das root PW über die Schaltfläche ein.


    Generelle Server Sicherheit hab ich mir bisher so überlegt:

    fail2ban

    ufw

    unattended-upgrades

    root account auf /sbin/nologin

    faillog

    evtl. IPv6 deaktivieren


    drauf soll dann Docker.


    VG

    Simon

  • […] alternativ würde ich SSH mit Zertifikatlogin nutzen, dann kommt man über das SCP halt nicht mehr rein, außer man setzt das root PW über die Schaltfläche ein. […]

    Der Vergabe eines Nutzerkontopassworts für ein Login via SCP steht doch trotz Zertifikatszwangs über SSH nichts entgegen?

  • Der Vergabe eines Nutzerkontopassworts für ein Login via SCP steht doch trotz Zertifikatszwangs über SSH nichts entgegen?

    Ich wollte das eigentlich noch ausführen und habs vergessen:

    In VNC kann ich ja nichts reinkopieren, drum ein Nutzer PW mit nicht zu vielen Stellen aber genügend.

    Wenn ich SSH nutze um den VPS zu administrieren würde ich einfach ein sehr langes PW aus dem PW-Tresor für den Nutzer Login nehmen, das ich dann aber nicht mehr von Hand in der VNC Konsole eingeben möchte...

    Eine Alternative wäre noch, einfach ein merkbares PW und 2FA auch für den Nutzerlogin unter Linux zu nutzen.

  • Überlegt? Also noch nichts gemacht? Du hast das auch noch nich lokal in einer VM durchgespielt?

  • In VNC kann ich ja nichts reinkopieren, drum ein Nutzer PW mit nicht zu vielen Stellen aber genügend.

    Wenn ich SSH nutze um den VPS zu administrieren würde ich einfach ein sehr langes PW aus dem PW-Tresor für den Nutzer Login nehmen, das ich dann aber nicht mehr von Hand in der VNC Konsole eingeben möchte...

    Am besten möchtest du garkein SSH Passwort sondern einen SSH Key verwenden.

    Den kannst du dann natürlich noch mit einem Passwort versehen.

    Nur, damit nicht aneinander vorbeigeredet wird: Die "Passphrase" für einen SSH-Schlüssel kann (und sollte) von einem Nutzerkontopasswort abweichen. Letzteres kann bei (Not-)Login via SCP durchaus relativ kurz sein, wenn man es nur dort nutzen kann. Denn wer Zugang auf den VPS via SCP hat, den interessieren Nutzerkonto­pass­wör­ter sowieso nicht mehr, weil er (sofern das Dateisystem nicht verschlüsselt und nach einem Reboot somit nicht mehr ohne weiteres lesbar ist) einfach über eine alternative Bootmöglichkeit (Rettungssystem/Bootdisk) an alle Inhalte herankommt…

  • Holt die Mistgabeln und die Fackeln! Es wird zeit endlich wieder einen Server Anfänger zu rösten!*


    *Achtung: Beitrag kann spuren von Ironie beinhalten.

    Nein, das war eine ernst gemeinte Frage. Wenn ich ihn hätte rösten wollen, hätte ich das anders formuliert. Es war ja auch keine Antwort auf die erste Frage.

  • Überlegt? Also noch nichts gemacht? Du hast das auch noch nich lokal in einer VM durchgespielt?

    Noch läuft der VPS nicht, keine Sorge :). Genau darum will ich erst überlegen wie ich ihn aufsetze bevor ich anfange "rumzuspielen" Das auf ner lokalen VM durchzuspielen werd ich mal machen bevor ich den Server aufsetze.

    Ich denke arbeiten über VNC ohne die Möglichkeit eines Shell Zugangs möchtest du nicht!

    Kannst du das evtl. kurz ausführen?

    Was für einen Nachteil habe ich, wenn ich nur die VNC zur Serveradministration nutze?

    Nur, damit nicht aneinander vorbeigeredet wird: Die "Passphrase" für einen SSH-Schlüssel kann (und sollte) von einem Nutzerkontopasswort abweichen. Letzteres kann bei (Not-)Login via SCP durchaus relativ kurz sein, wenn man es nur dort nutzen kann. Denn wer Zugang auf den VPS via SCP hat, den interessieren Nutzerkonto­pass­wör­ter sowieso nicht mehr, weil er (sofern das Dateisystem nicht verschlüsselt und nach einem Reboot somit nicht mehr ohne weiteres lesbar ist) einfach über eine alternative Bootmöglichkeit (Rettungssystem/Bootdisk) an alle Inhalte herankommt…

    Vielen Dank.

  • Danach ist ein direkter Login ins SCP nicht mehr möglich! Dieser muss dann übers CCP mit den Autologin-Buttons auf der Hauptseite erfolgen und ist somit mittels 2FA abgesichert.

    Leider stimmt das nicht. Denn Netcup setzt ein eigenes neues Passwort für das SCP, welches der Kunde dann nicht zu sehen bekommt.


    Wenn aber der Kunde sich das Passwort für das SCP über dessen Webinterface zurücksetzen lässt, kennt er es und kann sich weiterhin optional auch über das CCP mit den Autologin-Button in das SCP einloggen.


    Besser wäre es, wenn optional und separat auch das SCP mit der 2FA ausgestattet wäre.

  • Wenn aber der Kunde sich das Passwort für das SCP über dessen Webinterface zurücksetzen lässt, kennt er es und kann sich weiterhin optional auch über das CCP mit den Autologin-Button in das SCP einloggen.

    Du meinst die SOAP-Methode sendPasswordResetRequest vom SCP-Webservice? Oder wovon genau reden wir hier? :/


    Denn über servercontrolpanel.de/PasswordResetRequest erhalte ich beim Sicherheitsmodus nur eine Fehlermeldung:


    "Zu den angegeben Daten kann kein passender Datensatz gefunden werden."

  • Du bist sehr in der Kategorie „Prävention“ unterwegs. Nicht vergessen, dass Informationssicherheit aus mehr besteht:

    • Identifiziere und definiere, was du gegen wen schützen willst: Gegen welche Angreifer willst du dich schützen? Wie wichtig sind einzelne Dienste auf deinem Server? Welche Dienste sollen überhaupt laufen? Welche Ports brauchen die? Unter welchem Account laufen die? Brauchen die Upstream-Server? …
    • Implementiere präventive Maßnahmen: Das hast du quasi schon aufgeschrieben. Bedenke, dass du diese Maßnahmen gezielt einsetzt. Gegen was sollen sie schützen? Was sind ihre Grenzen? Was passiert, wenn sie falsch konfiguriert sind?
    • Implementiere detektierende Maßnahmen: Viele „Hardening Guides“ kommen mit langen Listen präventiver Maßnahmen. Präventive Maßnahmen helfen aber nicht für immer. Stell dir die präventiven Maßnahmen wie einen Burgwall vor: Irgendein Angreifer kann den immer überwinden. Du brauchst etwas, was Angriffe detektiert. Beispiele: 1) Monitoring von sicherheitsrelevanten Log-Dateien und Benachrichtigung an dich, wenn etwas Seltsames passiert. 2) Integritätsüberwachung wichtiger Systemdateien und regelmäßiger Check, ob die noch alle so sind, wie du sie konfiguriert hast. 3) Benachrichtigung bei SSH-Logins …
    • Implementiere reaktive Maßnahmen: Was passiert, wenn der Angreifer deine präventiven Maßnahmen überwindet und die Detektion anschlägt? Stell dir vor, du bist bei der Arbeit/an der Uni/auf dem Klo und wirst über einen SSH-Login benachrichtigt. Was machst du? Gibt es einen Plan, was du prüfst? Gibt es einen Plan, was du abschaltest? Wo ist dein Passwort für den Notfallzugriff unterwegs? …
    • Implementiere wiederherstellende Maßnahmen: Was passiert nach dem Brand? Der Angreifer war auf deinem System, du konntest ihn abwehren oder auch nicht. Auf jeden Fall stehst du jetzt da. Was jetzt? Hast du Backups wichtiger Daten? Hast du eine Liste, was auf dem System installiert war? Hast du Backups von Konfigurationsdateien? Hast du eine Liste der Firewalleinstellungen? …

    Und bedenke, dass du all diese Maßnahmen regelmäßig auf Wirkung prüfen solltest. Eine eingeschaltete Firewall, die aber nichts blockt, ist nutzlos. Log-Dateien, die niemand überwacht und im Zweifel vom Angreifer bereinigt werden, sind nutzlos. 5 Jahre Backups sind nutzlos, wenn sie alle defekt sind und eine Wiederherstellung nicht funktioniert.


    Ich hoffe, dass die Denkanstöße der/dem einen oder anderen noch weiterhelfen. Nie nur an Prävention denken!