Sichere sshd_config

  • Moin,


    ich baue mir gerade eine sichere/paranoide Standard Konfiguration für SSH auf meinen Servern.


    Gibt es weitere Ideen/Empfehlungen?



    Viele Grüße

    Christian

  • Port ändern und gff. Fail2ban für SSH

    Hi,


    Port ändern hat nichts mit Sicherheit zu tun. Statt Fail2ban werde ich eine Begrenzung auf spezifische User, Public Keys only und das PAM Modul von Google Authenticator ausrollen. Je nach Server. (Die Konfiguration wird noch in ein Ansible Template umgebaut)

  • Zitat

    PermitRootLogin yes

    Warum nicht "without-password" oder ganz aus stellen und nur für einzelne IPs Key-Login zulassen?

    Meine Minecraft-Plugins auf SpigotMC (Open Source): www.spigotmc.org/members/mfnalex.175238/#resources

    Discord: discord.jeff-media.com

  • Wieviele User/SSH-Keys hast du, dass du so viele Cihper aktiv haben musst? Mir reicht in der Regel genau 1 Cipher.


    btw, per iptables / ipset den SSH-Bereich massiv einschränken. z.B. dein DSL-Provider + andere vServer (als Backup). Wenn du keine statische IP hast, dann einfach mal auf die letzten IPs aus dem Router-Log/etc ein whois machen und dort den Bereich von deinen DSL-Provider nehmen.

    "Security is like an onion - the more you dig in the more you want to cry"

  • Port ändern bringt nur was wenn man auch Firewall Regeln gegen Portscan hat.

    Fail2Ban würde ich auch bei No Password Auth nehmen, alleine um die Last und Log files kleiner zu halten.

    Code
    PermitRootLogin no
    PasswordAuthentication no
    AllowGroups sshusers
    AuthorizedKeysFile      %h/.ssh/authorized_keys /var/lib/ssh/user/%u/authorized_keys /var/lib/ssh/allusers

    Die allusers Datei wird per puppet oder anderen tools beliefert.

    so können die Admins auf alle User zugreifen direkt, falls notwendig.


    eine "/etc/ssh/sshrc" ist auch noch anzuraten ;)

    Bash
    #!/bin/bash
    
    HOSTNAME=`hostname`
    echo "Subject: SSH Login $IP at ${USER}@${HOSTNAME}\r\nUser $USER just logged in from $IP at Server $HOSTNAME" | /usr/sbin/sendmail root &

    diese sendet beim Login einfach an den root, welcher bei uns in der alias Datei auf einer E-Mail Adresse weiterleitet.

    So kann man auch Logins erkenne, falls es mal einen "Eingriff" geben sollte.

  • Ich habe keine Firewallregeln gegen Portscans (letztlich kann jeder ja trotzdem die Ports herausfinden, ist nur aufwändiger und erfordert z. B. ein VPN, oder tor, falls man das nicht geblockt hat...) und habe mal nachgesehen, wie viele "authentication failure" ich bei ssh in den logs finde:


    Code
    zcat -f /var/log/auth.log* | grep 'sshd.*fail' | wc -l
    5


    Also gerade einmal 5 Stück und wie viele davon stammen nicht von mir selber, eil ich mich vertippt habe? 0


    Also Portänderung ist schon sehr effektiv. Die meisten Scriptkiddies machen sich gar nicht die Mühe den Port zu scannen. Dabei geht es mir vor allem darum, dass die Logs nicht so zugemüllt werden, fail2ban muss dadurch auch weniger Arbeiten. Als ich noch 22er Port hatte, waren meine Logs voll mit Angriffen...


    Mich würde ja mal interessieren, welche Zahl mein obiger Befehl bei Leuten liefert, die noch den 22er Port verwenden.

  • Hier ein paar Zahlen bei Systemen mit konfiguriertem fail2ban (48h bantime):


    Will gar nicht wissen wie das ohne fail2ban aussehen würde, bei mir sind meist auch immer 100+ IPs wegen fail2ban gesperrt =O

  • perryflynn

    Code
    LogLevel VERBOSE

    Damit Du u.a. weißt, über welchen Public Key der Login stattgefunden hat.

    Code
    PermitRootLogin prohibit-password

    Das ist mittlerweile der bevorzugte Wert.

    "Wer nur noch Enten sieht, hat die Kontrolle über seine Server verloren." (Netzentenfund)

  • Hier ein paar Zahlen bei Systemen mit konfiguriertem fail2ban (48h bantime):


    Will gar nicht wissen wie das ohne fail2ban aussehen würde, bei mir sind meist auch immer 100+ IPs wegen fail2ban gesperrt =O

    Ja so sah das bei mir auch mal aus, bevor ich den Port geändert habe. Bei mir ist derzeit keine einzige IP gebannt, weil fail2ban nicht aktiv werden muss.

  • Bei Paranoid denk ich direkt an Port-Knocking, ... ekelig im Alltag zu gebrauchen, gerade bei mobilen Clients, ... aber dafür Paranoid +1 haha

    Meine Produkte: definitiv zu viele, RS, VPS, Domains, Webhosting, ...

  • Richtig, wenn der Angreifer erstmal im Dunkeln die Tür suchen muss, an der er den Schraubendreher ansetzen kann dann hat er in der Zeit eher zig andere Server mit Tür an bekanntem Ort gefunden.

    Natürlich sollte die Tür im Dunkeln nicht offenstehen, das hat dann wirklich nichts mit Sicherheit zu tun. Aber um es dem Angreifer so schwer wie möglich zu machen bietet sich Portänderung als zusätzliches und einfaches Mittel an.


    Ich habe die gleiche Erfahrung gemacht. Mit 22 volle Logs mit failed auths. Nach Änderung Ruhe. Schont halt auch das System, wenn die Angreifer nicht erst vom Dienst zurückgewiesen werden, sondern schon von der Firewall abprallen.

  • Wieviele User/SSH-Keys hast du, dass du so viele Cihper aktiv haben musst? Mir reicht in der Regel genau 1 Cipher.

    Die Cipher Liste ist aus den Mozilla Security Guidelines. Einzige Anpassung welche ich gemacht habe war die Entfernung der NIST Curves, weil ich dem Verein nicht vertraue. Ich werde die Config die Tage ausrollen und dann mit verschiedenen Clients testen und anschließend schrittweise die Ciphers entfernen bis nur noch ChaCha übrig ist.

    eine "/etc/ssh/sshrc" ist auch noch anzuraten

    Nett. Da bastel ich mir noch was für. Danke!

    Das ist mittlerweile der bevorzugte Wert.

    Okay, scheint ja kein Unterschied zu "without-password" zu geben. Ich ändere es mal, da es im manpage auch als Standard definiert ist.

    Bei Paranoid denk ich direkt an Port-Knocking

    Zum Port Knocking und zum Ändern von Ports: Das ganze soll in einer Standard Umgebung funktionieren. Sprich auch, wenn ich mich in einer "Enterprise" Umgebung mit Proxy und Company Firewall befinde. Und das geht nun mal nur über Port 22.

    btw, per iptables / ipset den SSH-Bereich massiv einschränken.

    Gucke später mal ob da einen Kompromiss aus "sicher" und "erreichbar" finde.

  • Zitat

    Zum Port Knocking und zum Ändern von Ports: Das ganze soll in einer Standard Umgebung funktionieren. Sprich auch, wenn ich mich in einer "Enterprise" Umgebung mit Proxy und Company Firewall befinde. Und das geht nun mal nur über Port 22.


    Was haltet ihr von der Idee Port Knocking über den Umweg Webserver zu machen (wenn eh einer auf dem Server läuft).


    Also Port Knocking wird von einem Skript, z.b. in PHP oder Pyhton, ausgeführt, das ganz normal über http oder https aufrufbar ist.

    Evtl mit Passwort-Schutz, wenn man will.


    Vorteile:

    - Port ist nur offen, wenn er gebraucht wird, Port Knocking eben

    - sollte auch mit erwähnter ""Enterprise" Umgebung mit Proxy und Company Firewall" funktionieren

    - kann leicht automatisiert werden, indem besagte Webseite einfach vorher per curl aufgerufen wird

    - Webserver-Skript benötigt, dank Port Knocking, keine root Rechte


    Varianten

    - Port Knocking nur auf localhost erlauben

    - noch mehr security by obscurity, indem die Webseite ein ganz normale Seite mit einem Formular ist, und nur wenn z.B. bei Straße und Postleitzahl etwas bestimmtes steht, wird geknockt.

    - Skript könnte auch auf einem anderen Server laufen, wenn man das für mehrere VMs verwenden will, aber dann geht Punkt 1 nicht mehr (localhost)

  • per iptables kann man noch nach treten


    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

    INET_ADDRESS ist die Main IP des Servers.