SSH sicher am Imternet

Registriere dich jetzt, um exklusive Vorteile zu genießen! Als registriertes Mitglied kannst du Inhalte herunterladen und profitierst von einem werbefreien Forum.
Mach mit und werde Teil unserer Community!
  • 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


    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 ;)


    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.


    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



    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.
    Warum einfach wenn's auch schwer geht ?


    Kein Support per PN !
    Fragen bitte hier im Forum stellen. So hat jeder etwas davon.

    Edited once, last by Der_Imperator ().

  • UPDATE
    Heartbleet bugfix für OpenSSL / OpenSSH eingefügt
    Danke an chrisd1982 der mich mit einer Frage auf das Problem aufmerksam gemacht hat.

    Offizieller Schmier und Schmutzfink des Forum.
    Warum einfach wenn's auch schwer geht ?


    Kein Support per PN !
    Fragen bitte hier im Forum stellen. So hat jeder etwas davon.

    Edited once, last by Der_Imperator ().


  • 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…eartbleed-affect-ssh-keys

    The most popular websites without IPv6 in Germany.  IPv6-Ausreden

    Edited once, last by rpi444 ().

  • 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.
    Warum einfach wenn's auch schwer geht ?


    Kein Support per PN !
    Fragen bitte hier im Forum stellen. So hat jeder etwas davon.


  • 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-bi…pkg=openssl;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/c…ilman/listinfo/tor-relays

    Edited once, last by meckl ().


  • 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.
    Warum einfach wenn's auch schwer geht ?


    Kein Support per PN !
    Fragen bitte hier im Forum stellen. So hat jeder etwas davon.

    Edited once, last by Der_Imperator ().

  • 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 ().