SSH sicher am Imternet

Heute ist Stammtischzeit:
Jeden Donnerstag 20:30 Uhr hier im Chat.
Wer Lust hat, kann sich gerne beteiligen. ;)
  • Den Zugriff auf SSH über das Internet freizugeben ist sicher keine gute Idee.
    Besser wäre die Lösung über ein VPN.
    Wer jedoch das Risiko in Kauf nehmen möchte dem wird hier gezeigt wie man den SSH Daemon härten kann um das Risiko zu minimieren.

    OpenSSL Heartbleed fixen
    Ist mitlerweile in den Repro's gefixet, ich lass es mal stehen.

    Achtung die Version ist aus dem Testing Zweig von Jessie

    Display Spoiler


    Der PI hat auch nach dem letzten Update wohl noch eine verwundbare Version von OpenSSL.
    Ich kann nicht mit Sicherheit sagen ob diese version gefixed ist oder nicht.
    Laut OpenSSL ist die 1.0.1e verwundbar.

    Vorher :

    Code
    root@pi-wz:/home/pi# openssl version
    OpenSSL 1.0.1e 11 Feb 2013

    Nachher :

    Code
    root@pi-wz:/home/pi# openssl version
    OpenSSL 1.0.1k 8 Jan 2015

    Damit diese auf die aktuelle Version gebracht werden kann einfach folgende Schritte ausführen :

    sudo nano /etc/apt/sources.list
    folgende Zeilen anfügen

    Code
    deb http://mirrordirector.raspbian.org/raspbian/ jessie main contrib non-free rpi
    deb http://archive.raspbian.org/raspbian jessie main contrib non-free rpi

    dann mal einmal die Listen aktialisieren

    Code
    sudo apt-get update

    Und jetzt openssl aktualisieren, aus dem jessie Zweig.
    Wenn wir dabei sind, SSH direkt mit.

    Code
    apt-get -t jessie install openssl libssl1.0.0 openssh-client openssh-server ssh

    Danach die Repro's aus der sources.list wieder entfernen oder Auskommentieren


    SSH härten


    1. einen extra User für den SSH Zugriff erstellen
    *****
    Dieser Schritt ist Optional. Es kann sich nachher nur dieser User, auch aus dem lokalen Netzwerk am PI per SSH anmelden. Wer das nicht möchte kann diesen Schritt überspringen und ab 2) mit dem User PI weitermachen.
    *****
    Warum ?
    Der User PI hat das Recht mittels sudo root Befehle auszuführen.
    Dies ist natürlich übel, sollte der User einmal kompromittiert werden.
    Daher erstellen wir einen Benutzer für den SSH Zugriff welcher dieses Recht nicht besitzt.

    Code
    sudo adduser sshuser

    und folgen den Anweisungen.

    Jetzt werden wir zum sshuser um weiter zu arbeiten.

    Code
    su sshuser

    2. Authentifizierung mittels Keys statt Passwort

    Wir wechseln in das Home Verzeichnis des User und erstellen ein Verzeichnis .ssh

    Code
    cd ~
    mkdir .ssh
    cd .ssh

    Jetzt erstellen wir das Schlüsselpaar.

    ( Das geht auch mit PuTTy, siehe >>hier )

    Hier sollte unbedingt eine passpharse vergeben werden. Dieses schützt den Key zusätzlich.

    Code
    ssh-keygen -t rsa -b 2048 -f ~/.ssh/id_rsa

    Im Verzeichnis befinden sich jetzt zwei Dateien.
    id_rsa = Der Key des Benutzers
    id_rsa.pub = DerPublic Key des Benutzer

    Den Public Key kommt nun in das authorized_keys file des PI

    Code
    cat id_rsa.pub >>authorized_keys
    chmod 600 authorized_keys

    Die Datei id_rsa beinhaltet den Privaten Schlüssel welchen wir für den SSH Zugriff des Klienten benötigen und muss auf den Rechner kopiert werden welcher dann auf den PI zugreift. Das könnt ihr am besten per SCP machen.

    Nun bringen wir dem SSH Daemon bei nur noch Key Auth zu akzepieren.
    Dazu müssen wir die Config Datei bearbeiten.
    Da der sshuser keine Rechte hat wechseln wir erst mal wieder zum User PI und öffnen die Config Datei des SSH Daemon

    Code
    su pi


    und wir werden PI.

    als erstes sichern wir uns die Config Datei :

    Code
    sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bak


    Damit können wir alles wieder zurücksetzen falls wir uns irgendwo vertun.
    Es ist immer eine gute Idee Dateien for der Änderung zu sichern ;)

    "Zurücksetzen"


    sudo cp /etc/ssh/sshd_config.bak /etc/ssh/sshd_config

    Code
    sudo nano /etc/ssh/sshd_config

    Dort ändern wir folgende Zeilen :

    Code
    Protocol 2
    PermitRootLogin No
    AuthorizedKeysFile      %h/.ssh/authorized_keys
    ChallengeResponseAuthentication no
    PasswordAuthentication no
    UsePAM no


    !!!! ACHTUNG !!!!
    Nach einen Neustart des Daemon ist es nur noch möglich sich als sshuser mit dem Key einzuloggen !!!

    Den Daemon neustarten

    Code
    sudo /etc/init.d/ssh restart

    JETZT DIE AKTUELLE CONSOLE NICHT BEENDEN
    Mit der zur Zeit aktiven Konsole könnt ihr noch die Änderungen rückgängig machen falls etwas nicht funktioniert.
    Macht eine neue Verbindung auf und versucht euch anzumelden.


    Nach dem Einloggen als sshuser könnt ihr mit

    Code
    su pi


    zum User PI wechseln und wie gewohnt weiterarbeiten.

    3. Den Daemon paranoider einstellen
    Wir stellen jetzt den SSH Daemon ein wenig paranoider ein.
    Dazu öffnen wir wieder die Config Datei.

    Code
    sudo nano /etc/ssh/sshd_config
    Code
    AllowUsers sshuser


    Beschränkt den SSH Zugriff auf den User sshuser

    Code
    LoginGraceTime 30


    Gibt dir 30 Sekunden Zeit nach Aufbau der Verbindung zum Anmelden.
    Wird in der Zeit nix gemacht trennt der PI die verbindung

    Code
    MaxAuthTries 3


    Nur drei Anmeldeversuche

    Code
    MaxStartups 3:30:10


    Ist sehr schwer zu erklären aber eine sehr effektive Einstellung.

    "Aus der Man Page"


    Specifies the maximum number of concurrent unauthenticated con-
    nections to the sshd daemon. Additional connections will be
    dropped until authentication succeeds or the LoginGraceTime
    expires for a connection. The default is 10.

    Alternatively, random early drop can be enabled by specifying the
    three colon separated values "start:rate:full" (e.g.,
    "10:30:60"). sshd will refuse connection attempts with a proba-
    bility of "rate/100" (30%) if there are currently "start" (10)
    unauthenticated connections. The probability increases linearly
    and all connection attempts are refused if the number of unau-
    thenticated connections reaches "full" (60)

    4. Fail2Ban installieren
    Fail2ban ist ein Program was die Logfiles überwacht und nach X ungültigen Anmeldeversuchen die IP des Clienten per IPTables für xx Minuten aussperrt.
    Ein sehr wirkungsvolles Program was nicht fehlen sollte.
    Es kann nicht nur den SSHD überwachen sondern u.a. auch FTP und den Webserver.

    Fail2ban installieren :

    Code
    sudo apt-get install fail2ban

    Wir sichern die Konfiguratiion :

    Code
    sudo cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.conf,bak
    "Zurücksetzen"


    sudo cp /etc/fail2ban/jail.conf,bak /etc/fail2ban/jail.conf

    Die Konfiguration :

    Code
    sudo nano /etc/fail2ban/jail.conf


    Die wichtigsten Einstellungen :
    ignoreip = 127.0.0.1/8 192.168.0.1/24 #Hier sollte unbedingt euer Lokales Netzwerk mit eingetragen werden.
    bantime = 600 # Wie lange bleibt die IP gesperrt
    maxretry = 3 # Wieviele Fehlversuche ?
    Die Voreinstellungen sind so OK.

    Wessen PI Email versenden kann sollte folgende Zeile wie folgt ändern :
    action = %(action_mwl)s

    Jetzt zum SSH "Jail"

    [ssh]
    enabled = true # true schaltet den "Jail" ein
    port = ssh # Der Port, wer seinen SSH Clienten auf einen anderen als Port 22 hören lässt muss diesen hier eintragen, z.B. 9922
    filter = sshd # der Filter für das Log
    logpath = /var/log/auth.log # Das Log in dem die Anmeoldeversuche protokolliert werden.
    maxretry = 3 # Drei anmelde Versuche erlaubt

    Wenn ihr euch in der Datei umseht dann findet ihr einige vorgefertigte Jails für die unterschiedlichsten Dienste.

    ein

    Code
    /etc/init.d/fail2ban restart


    Übernimmt die Änderungen.
    Dieses setzt auch alle Blocks zurück !


    Damit sollte euer PI Fit für das Internet sein.
    Behaltet nur immer in Hinterkopf das NICHTS 100% Sicher ist.

    Wem die permanenten Meldungen jetzt auf den Sack gehen der kann seinen SSH Port noch verschleiern.

    Dieses würde ich jedoch im Router machen und den PI weiterhin auf Port 22 lauschen lassen.
    Im Router würde dann eine Freigabe eingreichtet welche vom öffentlichen Port 33322 auf den lokalen Port 22 zeigt.

    Damit kommt dann etwas Ruhe rein, ist aber bei weitem nicht so interessant ;)

    Fragen ? Bitte hier stellen, niicht per PN oder Mail.
    Fehler gefunden ? Bitte per PN und nicht den Thread flooden.
    Rechtschreibfehler ? Ich hab ne Rechtschreibschwäche ( ehrlich ), von daher geht mir das am Popo vorbei ;)

    Offizieller Schmier und Schmutzfink des Forum.

    Edited once, last by Der_Imperator (March 21, 2015 at 11:10 AM).


  • Heartbleat bugfix für OpenSSL / OpenSSH eingefügt
    ... auf das Problem aufmerksam gemacht hat.

    Ist das so, dass hier die Version etwas über die Verwundbarkeit aussagt? Ich denke, die (updatete) Version OpenSSL 1.0.1e 11 Feb 2013 ist durch den maintainer des Packages gepatcht/gefixt worden und somit (... was die Sicherheit/Verwundbarkeit betrifft) auf dem gleichen Stand wie die Version OpenSSL 1.0.1k 8 Jan 2015?

    EDIT:

    Ein evtl. und möglicher Zusammenhang zwischen OpenSSL (Heartbleed) und OpenSSH, kann man u. a., z. B. hier lesen: http://superuser.com/questions/7393…affect-ssh-keys

    The most popular websites without IPv6 in Germany.  IPv6-Ausreden
    "Das dauert plötzlich ½ Sekunde länger. Das muss ich mir anschauen!" - Andres Freund

    Meine PIs

    PI4B/8GB (border device) OpenBSD 7.5 (64bit): SSH-Server, WireGuard-Server, ircd-hybrid-Server, Mumble-Server

    PI3B+ FreeBSD 14.0-R-p6 (arm64): SSH-Serv., WireGuard-Serv., ircd-hybrid-Serv., Mumble-Serv., ddclient

    PI4B/4GB Bullseye-lite (64bit; modifiziert): SSH-Server, WireGuard-Server, ircd-hybrid-Server, Mumble-Server, botamusique, ample

    Edited once, last by rpi444 (February 27, 2015 at 3:30 PM).

  • Sicherheitstechnisch finde ichs aber auch bedenklich eine nicht grundlos als unstable (bzw testing) eingestufte jessie Version zu installieren, zumal in der Anleitung nichts vom wieder entfernen des Repos beschrieben steht, noch gibts irgendwelche Hinweise darauf das es sich dabei um eine beta Version handelt usw


    (es schimpft sich btw Heartbleed, nicht Heartbleat)

  • Ist das so, dass hier die Version etwas über die Verwundbarkeit aussagt? Ich denke, die (updatete) Version OpenSSL 1.0.1e 11 Feb 2013 ist durch den maintainer des Packages gepatcht/gefixt worden und somit (... was die Sicherheit/Verwundbarkeit betrifft) auf dem gleichen Stand wie die Version OpenSSL 1.0.1k 8 Jan 2015?

    Das ist eine gute Frage.
    Offiziell ist die Version 1.0.1.e kompromittiert.
    https://www.openssl.org/news/vulnerabilities.html

    openssl version sowie apt-cache show openssl zeigen 1.0.1e
    Ob nun deb7u14 sauber ist kann ich nicht sagen.
    Da hab ich nix drüber gefunden.
    Lasse mich jedoch gerne Aufklären.



    Sicherheitstechnisch finde ichs aber auch bedenklich eine nicht grundlos als unstable (bzw testing) eingestufte jessie Version zu installieren, zumal in der Anleitung nichts vom wieder entfernen des Repos beschrieben steht,

    Na ja, die Version 1.0.1k als unstable zu bezeichen halte ich für doch etwas übertrieben.
    Gut sie ist in Jessie zu finden, nicht im wheezy. Allerdings ist schon 1.0.2 freigegeben.

    Ich werde es um einen Hinweis ergänzen.


    noch gibts irgendwelche Hinweise darauf das es sich dabei um eine beta Version handelt usw

    Stimmt, da muß ich dir recht geben.


    (es schimpft sich btw Heartbleed, nicht Heartbleat)

    War wohl ein Tipfehler im zweiten Thread.

    Offizieller Schmier und Schmutzfink des Forum.


  • Das ist eine gute Frage.
    Offiziell ist die Version 1.0.1.e kompromittiert.
    https://www.openssl.org/news/vulnerabilities.html

    Wo steht auf der Seite das die 1.0.1e-2+rvt+deb7u14 von Raspbian kompromittiert sei?

    Es gibt verschiedene 1.0.1e Versionen.
    Laut heartbleed.com ist die 1.0.1e-2+deb7u4 betroffen aber auf Raspbian Wheezy ist 1.0.1e-2+rvt+deb7u14 aktuell. Nicht nur 'rvt' anders sondern auch 'deb7u14' vs. 'deb7u4'

    Ein wenig nach 'debian openssl heartbeat' googlen und man findet zum Beispiel:
    https://www.debian.org/security/2014/dsa-2896
    Dort steht dass das Problem ab Version 1.0.1e-2+deb7u5 behoben wurde.

    https://security-tracker.debian.org/tracker/CVE-2014-0160
    Demzufolge ist das Problem ebenfalls mit 1.0.1e-2+deb7u14 gefixt.

    Wer sich trotzdem unsicher ist kann zumindest seinen SSL-Webserver > hier < testen lassen.

    Fazit: Die unter Raspbian installierte OpenSSL Version ist nicht mehr vom Heartbleat aka Heartbleed betroffen


    Na ja, die Version 1.0.1k als unstable zu bezeichen halte ich für doch etwas übertrieben.
    Gut sie ist in Jessie zu finden, nicht im wheezy.

    Jessie als ganzes ist zum einen immernoch 'testing', aber auch die von dir verwendete Version 1.0.1k ist offiziell ebenfalls als 'testing' eingestuft, was auch ein Grund ist wieso es noch nicht im stable Repo verfügbar ist, das hat mit Jessie an sich erst mal nichts zu tun.

    Siehe dazu auch hier:
    https://packages.qa.debian.org/o/openssl.html
    https://bugs.debian.org/cgi-bin/pkgrep…l;dist=unstable

    Allerdings ist schon 1.0.2 freigegeben.

    Das ist der aktuelle Entwicklungstree und ist als 'Experimental' markiert. Es gibt auch schon eine 1.1.0-dev Version, was aber nichts mit dem hier bisher erwähnten zu tun hat.

    Neuer bedeutet nicht zwangsläufig besser.

  • Fail2Ban etc. war vor wenigen Tagen ein Thema in der Tor-Relay Mailinglist.
    Ich denke das sollte hier nicht fehlen, auch wenn man keinen Tor-Server auf seinem RasPi laufen hat.

    via https://lists.torproject.org/cgi-bin/mailma…info/tor-relays

    Edited once, last by meckl (February 28, 2015 at 12:17 PM).


  • Fail2Ban etc. war vor wenigen Tagen ein Thema in der Tor-Relay Mailinglist.
    Ich denke das sollte hier nicht fehlen, auch wenn man keinen Tor-Server auf seinem RasPi laufen hat.

    Ja nee, ist klar.
    Wenn dein SSH aus TOR angegriffen wird dann werden alle Exit Nodes gebannt.
    Deswegen verwende kein Fail2Ban sondern verschleiere den Port.

    Frage : Ist das nicht genau das was Fail2Ban machen soll, die IP rejecten ?

    Ist natürlich doof wenn du dieses undurchsichtige US Netzwerk verwendest.
    Dann sind die Exit Nodes gebannt, in diesem Fall die Quelle des Bösen.
    Und was macht du wenn dein verschleierter SSH Port 4711 angegriffen wird ?

    Offizieller Schmier und Schmutzfink des Forum.

    Edited once, last by Der_Imperator (February 28, 2015 at 1:19 PM).

  • Ich persönlich nutze momentan DenyHost mit ein paar zusätzlichen Scripts.
    Sobald ein Angriff erkannt wird, wird diese IP Adresse natürlich erstmal (für eine gewisse Zeit) komplett vom System ausgesperrt,
    ebenso wie die momentan bekannten Angreifer von DenyHost (http://xmlrpc.denyhosts.net).
    Nach einer gewissen Zeit, wenn die Angriffe aufhört haben, bzw. die Angreifer "weitergezogen" sind, werden die IP-Adressen wieder freigegeben.
    Zusätzlich werde ich bei jedem erfolgreichen Login informiert.
    Wenn also ein unauthorisierter Login auftaucht, weiß ich das mein System kompromitiert wurde und ich ein altes (sicheres) Backup einspielen muss.
    Root-Login wurde natürlich ausgeschalten, Port geändert, Benutzer eingeschränkt, Login nur mit Schlüssel, etc...

    Edit: Ich denke so kann ich dieses "undurchsichtige US-Netzwerk" ohne bedenken unterstützen...

    Edited once, last by meckl (February 28, 2015 at 2:25 PM).

Participate now!

Don’t have an account yet? Register yourself now and be a part of our community!