Debian GNU/Linux erweiterte Sicherheit

  • Sehr geehrte Damen und Herren,


    ich bin nun erfolgreich zu Netcup umgezogen, sehr zufrieden mit dem Verhältnis von Preis/ Leistung und dem Support.

    In der Vergangenheit wurde mein System immer wieder das Ziel von wahllosen Angriffen über SSH, Erfolg hatte noch keiner aber ein kleines Risiko bleibt ja leider immer.

    Da ich hier auch nicht davon verschont bleiben werde, wie ich feststellen musste nachdem ich mir den auth.log mal angeschaut habe, bin ich nun dabei noch tiefer in die Sicherheit einzugreifen und so paranoid wie möglich zu werden.


    Folgendes habe ich bisher vorgenommen:

    - Einen direkten Zugriff auf den Benutzer "root" verboten und abgeschaltet

    - Einen unprivilegierten Benutzer erstellt und diesem die Rechte für sudo gegeben

    - Jeglichen Benutzern den Zugriff auf SSH entzogen, außer dem von mir erstellten Benutzer

    - SELinux eingerichtet

    - Ein mehr als ausreichend starkes Passwort generiert (64 Ziffern mit allen möglichen Zeichen aus UTF-8)

    - Den Zugriff auf SSH mit einem Passwort abgeschaltet und 8192 RSA Schlüsselpaare erzeugt

    - Jedem Schlüssel eine eigene Passphrase gegeben, ebenfalls 64 Ziffern lang

    - Die Passphrase auf einem USB-Stick abgelegt, welcher verschlossen in meinem Schrank liegt

    - Jeglichen Traffic eingehend blockiert, bis auf SSH aktuell

    - Den Port von SSH geändert auf einen zufälligen >1000


    Gibt es noch mehr was ich tun könnte ? Ich bin für jegliche Vorschläge offen und bedanke mich schon einmal im voraus.


    Mit freundlichen Grüßen,

    Lukas

    RS 4000 SAS G7SEa3 - Debian GNU/Linux 9 "Stretch"

  • Hallo und willkommen bei uns ;)


    Sieht doch sehr solide aus.

    Falls doch mal jemand deinen Port herausbekommt und anfängt zu bruteforcen, wäre fail2ban noch eine gute Abhilfe um diese Angriffe schnell zu unterbinden.

  • Sieht soweit gut aus. Genrell sollte man die Regel verfolgen, dass man die Ports Whitelistet.

    So sind wir von einer "Katastrophalen" Standard Einstellung bei MongoDB nicht betroffen gewesen, als ein Kollege diese bei einem Kunden verwendet hat und aktiv genutzt hat.


    Bezüglich SSH würde ich komplett auf Keys setzen und Passwort in der Konfig deaktivieren.

    root ebenfalls nicht per Key zulassen.

    per IPTABLES pro IPv4 einen hitcount hinterlegen

    Beispiel:

    Code
    $IPT -A tcp_outbound -p TCP -s 0/0 -d $INET_ADDRESS --destination-port 22 -j ACCEPT
    $IPT -A tcp_inbound -d $INET_ADDRESS -p tcp -m tcp --dport 22 -m state --state NEW -m recent --set --name DEFAULT --rsource
    $IPT -A tcp_inbound -d $INET_ADDRESS -p tcp -m tcp --dport 22 -m state --state NEW -m recent --update --seconds 60 --hitcount 5 --name DEFAULT --rsource -j DROP
    $IPT -A tcp_inbound -d $INET_ADDRESS -p tcp -m tcp --dport 22 -j ACCEPT

    Den Port Ändern bringt nur einen Pseudo erfolg, wenn der Port dicht ist, musst du von vielen einen Portscan über dich laufen lassen.

    Nach dem der Port dann bekannt war ging es weiter bei uns...


    Bei großen Setups nutzen wir 2 IPs

  • Auch in den Bereich der Verschleierung fällt "(SSH-)Port-Knocking", das sich anbietet, wenn man nur mit einer IP arbeitet (und keine weitere [private] IP hat, auf der der SSH-Daemon hört). Der SSH-Port wird hierbei erst für eine konkrete IP gewhitelisted sobald bestimmte Ports direkt aufeinander folgend in einer bestimmten Reihenfolge "angeklopft" werden. Das verhindert das Ausspähen des SSH-Ports per Portscan recht gut. Ich nutze dies mit sich wöchentlich ändernden Ports.

  • Vielen Dank für die hilfreichen Beiträge, ich habe mir fail2ban angeschaut, jedoch brauche ich ich dieses nicht weil bei mir Passwörter nicht akzeptiert werden, nur Schlüssel.

    Wie sieht es eigentlich aus mit der Sicherheit des Host ? Kann man auf mein System zugreifen oder ist die virtuelle Festplatte verschlüsselt ?

    RS 4000 SAS G7SEa3 - Debian GNU/Linux 9 "Stretch"