Massive Angriffe auf ssh

  • ich will ja nix sagen. aber PowerShell hat echt Konstrukte die haben es in sich;

    nicht mal C, des syntaktisch so ziemlich alles auf Lager hat, kennt derartiges;


    Code
    Function func( [String] $s, [Int] $i ) {
      ...
    }

    dass man des so func "Hello" 3 oder so func -s "Hello" -i 3 aufrufen muss

    und nicht so func "Hello, 3 aufrufen darf, auf des kommt niemand^^

    Grüße / Greetings

    Walter H.


    RS, VPS, Webhosting - was man halt so braucht;)

  • Wird wohl grafana sein? Oder irre ich? sdellenb

    Kibana.

    Ich füttere meine syslogs in einen ElasticStack. Die fail2ban logs werden noch im Logstash mit geoip2 angereichert für die Karte.

    CentOS 7 / nginx / php-fpm / postfix / rspamd / clamav / dovecot / nextcloud running on RS 1000 SSDx4 G8 / VPS 500 G8 / VPS 2000 G8 Plus

  • Ich wiederhole meine Empfehlung auch noch einmal :)

    >> Oder gleich eine modernere Variante: fwknop(d)

    (Falls man kein "klassisches" Port-Knocking haben möchte.)

    Danke für die Erinnerung! Da gab es ja hier noch das (Meta-)TODO, die Nutzung dieses Werkzeugs auf die TODO-Liste zu setzen… ;(

    Nachdem ich gestern 'mal fwknop angesehen habe, frage ich mich, ob das in der Praxis überhaupt große Verbreitung auf mobilen Geräten findet (vgl. Issue #138: "Extend allowed IP's to entire subnets for rapidly changing mobile environments"). Natürlich kann man dort bei Rückgriff auf ein VPN (wie bspw. MeshVPN) auf fwknop[d]/knock[d] verzichten, aber es ist bedauerlich, dass man nicht explizit (zumindest teilweise) eine stringente IP-Adressprüfung deaktivieren kann, zumal es auch die Zertifikatsverwaltung in Testumgebungen o. ä. vereinfachen würde. Werde aus diesem Grund wohl doch noch eine Weile bei meinem präferierten knock-Fork v0.8.1 bleiben… :pinch:

    (Allerdings bin ich ganz Ohr, falls jemand obengenannte Funktionalität in einem fwknop-Fork entdecken sollte! :love:)

    VServer IOPS Comparison Sheet: https://docs.google.com/spreadsheets/d/1w38zM0Bwbd4VdDCQoi1buo2I-zpwg8e0wVzFGSPh3iE/edit?usp=sharing

  • Ich denke, dass man sich auf die grundsätzliche Sicherheit von Tools wie OpenSSH schon recht gut verlassen kann, sofern man sie aktuell hält und sich seiner Konfiguration bewusst ist. Tatsächlich erlaube ich sogar den Login als root auf meinem Server, allerdings nur mittels eines 4096-bit RSA private keys, und da ist noch nie einer rein gekommen. Die üblichen Botnet-Angriffe verdienen es nicht, als Hacking-Versuch betrachtet zu werden. Das sind meist ganz dumme scripte, die recht ziellos herumstochern, weil halt auch ein blindes Huhn irgendwann ein Korn findet, und gegen die ist das verwenden eines selbst gewählten Ports das Beste, was man machen kann. Nicht, weil es die Sicherheit erhöht, sondern weil es die Systemlast veringert, wenn die gleich vor 'ne Wand rennen.

  • Hallo,


    auf meinen Servern mit den selbstgewählten Ports nehmen die Versuche auch teilweise drastisch zu.

    Scheint so als wenn das irgendwann in einer Datenbank landet. Wenn man da was erreichen will muss man wohl regelmäßig den

    Port ändern.


    Gruß Eckhard

  • Ich nutze Debian Buster und war mit dessen fail2ban nicht vollkommen glücklich. Ziemlich viele Loginversuche wurden nicht erkannt, Ich habe dann an den Rules herumgeschraubt, das hat dann einigermaßen gepasst. Ich finde die fail2ban-Lösung aber recht aufwendig. Der Openssh-Server hat keine wirklichen Performance-Probleme bei den "üblichen" Loginversuchen. Nur wenn das einer übertreibt sollte man ihn auf die Finger hauen.


    Ich habe also die fail2ban-Lösung durch ein RateLimit der Firewall ersetzt, hier ein Auszug meiner nftables Regeln:


    Code
    chain input {
        ct state invalid drop
        ct state { established, related } accept
        iif "lo" accept
        tcp dport { http, https } accept
        ip version 4 tcp dport ssh meter ssh4blocked size 1024 { ip saddr & 255.255.255.0 timeout 1h limit rate 1/minute burst 10 packets}  counter name "ssh_connections" accept
        ip6 version 6 tcp dport ssh meter ssh6blocked size 1024 { ip6 saddr & ffff:ffff:ffff:ff00:: timeout 1h limit rate 1/minute burst 10 packets}  counter name "ssh_connections" accept
        tcp dport ssh counter name "ssh_rate_limit" reject

    Die Syntax ist angepasst an die etwas angestaubte Version von nftables in Debian Buster, für aktuelle Versionen siehe https://wiki.nftables.org/wiki-nftables/index.php/Meters.


    Damit darf jedes /24 IPv4-Netz bzw. /56 IPv6-Netz einen ssh-Verbindungsaufbau pro Minute machen, der Burst von 10 erlaubt ein Überschreiten dieses Limits um bis zu 10 Verbindungsaufbauten. Alles was drüber liegt, wird von der Firewall abgeschmettert.


    Mit einem kurzen Script hole ich mir alle 3 Strunden eine Statistik:


    Bash
    conn=$(/usr/sbin/nft reset counter inet filter ssh_connections | awk '$1 == "packets" { print $2 }')
    [ -z "$conn" ] && exit 1
    rl=$(/usr/sbin/nft reset counter inet filter ssh_rate_limit | awk '$1 == "packets" { print $2 }')
    [ -z "$rl" ] && exit 1
    logger -p auth.info -t nftables "SSH connections: $conn, rate limit exceeded: $rl"


    Hier mal ein Auszug aus dem Log:

    Code
    Nov 17 15:00:01 netcup nftables: SSH connections: 43, rate limit exceeded: 0
    Nov 17 18:00:01 netcup nftables: SSH connections: 68, rate limit exceeded: 0
    Nov 17 21:00:01 netcup nftables: SSH connections: 35, rate limit exceeded: 4
    Nov 18 00:00:01 netcup nftables: SSH connections: 72, rate limit exceeded: 4
    Nov 18 03:00:01 netcup nftables: SSH connections: 40, rate limit exceeded: 0
    Nov 18 06:00:01 netcup nftables: SSH connections: 105, rate limit exceeded: 98
    Nov 18 09:00:01 netcup nftables: SSH connections: 80, rate limit exceeded: 0


    Ich bekomme also so etwa 80 Requests/3 Stunden, die vom ssh-Server bearbeitet werden müssen, heftigere Scans blockt die Firewall ab. Das ganze auf dem Standardport 22. Diese recht simple Konfiguration hat sich bislang bestens bewährt. Die "normalen" Scans kann der ssh-Server locker ab, heftigere Scans filtert die Firewall weg.

  • Ich verstehe die Aufregung nicht. Solange der Login nur via Key funktioniert und ggf prominente Account Namen blacklisted sind gibt es praktisch keine Möglichkeit sich via SSH in den Server zu hacken. Und solange Logging und der SSHd selbst korrekt konfiguriert sind, ist das auch vollkommen egal wie oft da ein Login versucht wird.


    Als ob der SSHd Prozess bei sowas auf einmal auf 80% CPU Last läuft.


    Sollen die sich doch austoben.