Ergebnis 1 bis 4 von 4

Port-Weiterleitung um über SSH auf Raspberry Pi zuzugreifen

  1. #1 Zitieren
    Ritter Avatar von Feuerstern
    Registriert seit
    Sep 2007
    Beiträge
    1.798
    Hallo zusammen,
    Zuhause läuft bei mir ein Raspberry Pi der im Netzwerk ein paar Aufgaben erfüllt. Bisher war dieser nicht über das Internet erreichbar. Ich bräuchte aber in Zukunft die Möglichkeit gelegentlich auch von außerhalb des Netzwerks auf den Raspberry Pi zuzugreifen. Dazu scheint sich eine Port-Weiterleitung anzubieten um dann über SSH Zugreifen zu können. Dabei möchte ich sicherstellen das nicht versehentlich das ganze Netz Zugriff auf meinen Rapsberry Pi oder das Heimnetz bekommt. Bisher habe ich folgende Schritt unternommen:
    - pi Benutzer standard Passwort geändert (lang und kompliziert)
    - Neuen User hinzugefügt unter dem ich hauptsächlich "arbeite" (Passwort nicht zu leicht, aber Alltags tauglich)
    - sudo nur noch mit Passwort Eingabe nutzbar gemacht
    - fail2ban installiert
    - ssh nur noch über rsa key erlaubt

    Daraus ergeben sich jetzt noch weitere Fragen.
    - Sollte ich auch noch den standard SSH Port ändern?
    - Das Benutzer Passwort selbst ist zwar nicht super schlecht, aber auch nicht super kompliziert, da ich es ja häufiger eingeben muss (bei updates etc). Als der Raspberry Pi nur im Netzwerk zugreifbar war habe ich mir da keine Gedanken drüber gemacht, aber müsste ich das Passwort dann weiter verkomplizieren? Da SSH nur über meinen rsa key Zugänglich ist, sollte das erstmal nicht also sehr ins Gewicht fallen oder irre ich mich?

    Ich würde mich über Anregungen und Tipps freuen.

    Viele Grüße
    Feuerstern ist offline

  2. #2 Zitieren
    Tieftöner Avatar von Lookbehind
    Registriert seit
    Dec 2007
    Beiträge
    15.176
    Gute Passwörter sind immer eine gute Idee. Wenn man sie einigermaßen häufig braucht, kann man auch lange Passwörter mit der Zeit schnell tippen, weil sie ins Muscle-Memory über gehen. Und bei Passwörtern die man nicht so oft braucht, well, da tuts auch nicht so weh, wenn die mal länger zum eingeben brauchen, weil man es eben auch nicht so oft macht.

    An sich sind die wichtigsten Sicherungsmaßnahmen für einen SSH-Server, dass man sich ausschließlich per Public-Key anmelden kann, und dass man gegebenenfalls den SSH-Login für root direkt sperrt. Wenn der Benutzername nicht zu leicht zu erraten ist, hilft das auch. Ich lösche den User "pi" auf Raspbian Systemen immer, sobald ich ihn nicht mehr brauche. Mit Fail2Bann hast du noch eine zusätzliche Sicherheits-Ebene implementiert, was schon mal gut ist.

    Wenn man ganz paranoid ist, kann man den SSH-Port noch in der Firewall dicht machen, und nur per Port-Knocking freigeben. Das ist zwar kein super sicheres vorgehen, hält aber einen Haufen Script-Kidies ab. Auf der andern Seite ist das aber auch nicht ganz einfach zu konfigurrieren, wenn man das Konzept nicht verstanden hat. Also eher ein Nice2Have. Zudem macht es die Benutzung etwas komplizierter, weil man nicht mehr einfach mit "ssh user@host" auf die Kiste rauf kommt.

    Den Default-Port zu ändern hat einen ähnlichen Nutzen. Wer deinen SSH-Server knacken will, findet den auch auf nem Highport, aber es klopfen deutlich weniger Bots und Script-Kidies an, was unter anderem auch die Logs kleiner hält. Das brauchst du nicht mal in deinem LAN machen. Es genügt, wenn du am Router Port 12345 (oder whatever) an Port 22 auf deinem Pi weiter leitest. Dann kannst du im LAN immer noch über Port 22 zugreifen, und übers Netz dann per Port 12345.

    Aber im großen und ganzen, macht dein Setup schon einen recht soliden Eindruck. Insgesamt ist SSH auch nicht erst seit gestern im Internet unterwegs und wird für etliche, durchaus auch wichtige Geräte genutzt. Das kann man durchaus als Kampferprobt bezeichnen. Was natürlich nicht heißt, dass nicht evtl jemand morgen eine Mega Sicherheitslücke darin findet. Ein gewisses Restrisiko bleibt eben immer. Aber das sollte hier überschaubar sein. Sieh nur zu, dass du dein System auch einigermaßen aktuell hältst.
    Lookbehind ist offline

  3. #3 Zitieren
    Ritter Avatar von Feuerstern
    Registriert seit
    Sep 2007
    Beiträge
    1.798
    Danke für deine ausführliche Antwort. Den pi Benutzer wollte ich auch erst löschen, im Guide von raspberrypi.org stand allerdings das dieser für manche Dinge benötigt wird und man den Benutzer deshalb nur löschen soll wenn man sicher ist diesen nicht mehr zu brauchen. Deshalb hatte ich den Benutzer erstmal da gelassen und mit einem Sicheren Passwort versehen.
    Würdest du generell eine Firewall auf dem Server empfehlen?
    Feuerstern ist offline Geändert von Feuerstern (29.03.2021 um 20:16 Uhr)

  4. #4 Zitieren
    Tieftöner Avatar von Lookbehind
    Registriert seit
    Dec 2007
    Beiträge
    15.176
    Zitat Zitat von Feuerstern Beitrag anzeigen
    Danke für deine ausführliche Antwort. Den pi Benutzer wollte ich auch erst löschen, im Guide von raspberrypi.org stand allerdings das dieser für manche Dinge benötigt wird und man den Benutzer deshalb nur löschen soll wenn man sicher ist diesen nicht mehr zu brauchen. Deshalb hatte ich den Benutzer erstmal da gelassen und mit einem Sicheren Passwort versehen.
    Naja, die offizielle Doku vom RasPi richtet sich natürlich auch an ein Ziel-Publikum, welches evtl von Administration noch nicht SO viel Ahnung hat. Unten drunter liegt ein ... naja, nicht mehr so richtig stinck normales, die RasPi-Jungs und Mädels haben da schon recht viel angepasst ... aber letztlich liegt da trotzdem ein Debian drunter. Und insbesondere die User-Verwaltung ist ziemlich standard. Warum soll man auch an einem ansonsten sehr gut funktionierenden System unnötig rum basteln? Sprich: Wenn du weißt, was du tust, kannst du auch ohne den pi-User alles hin bekommen.

    Mich würde nicht wundern, wenn die Warnung vor allem darauf basiert, dass der pi-User im Default der einzige User mit sudo rechten ist und man nur verhindern wollte, dass die Leute den einzigen Admin-User auf dem System löschen.

    Zitat Zitat von Feuerstern Beitrag anzeigen
    Würdest du generell eine Firewall auf dem Server empfehlen?
    Darauf ein eindeutiges: Kommt drauf an!
    Allgemein muss man vielleicht mal klären, was mit "Firewall" genau gemeint ist. Da gibts verschiedene Ansätze, die mal mehr mal weniger sinnvoll sind.

    Für deinen Anwendungsfall wäre wohl ein Paketfilter das sinnvollste. Den liefert Linux mit iptables (bzw. neuerdings nftables) gleich mit, und der taugt auch durchaus was. Was macht der Paketfilter? Er filtert alle Daten-Pakete, die die Netzwerkkarte sieht (eingehend, ausgehend, durchgehend, whatever) nach von dir vorgegebenen Kriterien und wenn ein Kriterium passt, wird die von dir vorgeschriebene Operation damit ausgeführt.

    Ein einfaches Beispiel: iptables -I INPUT -s 1.2.3.4 -p TCP --dport 22 -j DROP
    Für alle eingehenden (INPUT) Datenpakete, die von IP 1.2.3.4 kommen, und den TCP-Port 22 (SSH) ansprechen => Schmeiß weg! (DROP)

    Spoiler:(zum lesen bitte Text markieren)

    Kleiner Exkurs:
    Das ist übrigens genau das, was dein Fail2Ban macht. Es untersucht die Log-Files, und wenn in einer gewissen Zeit von einer bestimmten IP-Adresse zu viele fehlgeschlagene Login-Versuche auftreten, legt es für diese IP-Adresse genau so eine Regel an.

    Evtl nimmt der auch "REJECT" statt "DROP". Der größte Unterschied ist, das bei REJECT der Absender darüber informiert wird, dass sein Paket abgelehnt wurde, bei DROP nicht.


    Das Haupt-Anwendungs-Feld wäre hier also einzelne Ports zu sperren. Damit ist die Anwendung hinter dem Port nicht mehr erreichbar. Wenn ich den Port aber ganz dicht mache, und die Anwendung damit gar nicht mehr erreichbar ist ... warum betreibe ich die Anwendung dann überhaupt? Dann wäre es tatsächlich sinnvoller, die Server-Anwendung (in diesem Beispiel SSH) einfach ganz ab zu schalten. Dann brauch ich da auch keinen Paketfilter mehr davor. Wo nix läuft, kann man auch nix angreifen.

    So ein Paketfilter macht also vor allem dann Sinn, wenn man komplexere Anwendungsfälle hat, wo man z.B. auf Basis des Herkunftsnetzes entscheiden kann, ob man das Paket annehmen möchte, oder nicht. Wobei die Regeln bisweilen durchaus noch komplexer werden können und man damit wirklich coolen Kram machen kann. Dennoch braucht man aber auch den Anwendungsfall dafür.

    Spoiler:(zum lesen bitte Text markieren)

    Kleiner Exkurs:
    Ich hab bei mir mehrere Netzwerke eingerichtet und benutze tatsächlich ein Debian als Router. Unter anderem habe ich ein eigenes Netzwerk für alle IoT Geräte. Diese will ich bisweilen vom Laptop oder Smartphone aus steuern können, ich möchte aber nicht, dass die IoT-Geräte selbst, an irgendwelche sensiblen Daten oder gar ans Internet ran kommen. Das löse ich tatsächlich mit solchen Paketfilterregeln.


    Ich nehme mal an, du möchtest den SSH-Server vor allem deshalb ans Internet anklemmen, damit du, auch wenn du nicht zuhause bist, noch deinen Pi administrieren kannst. Um eine entsprechende Regel für den Paketfilter zu formulieren, die das noch ermöglicht, aber alle "bösen Jungs" aussperrt, musst du entweder vorher wissen, welche IPs die bösen Jungs benutzen, oder, noch besser, welche IP-Adressen du haben wirst, wenn du von außen darauf zugreifen können möchtest. Beides halte ich für schwer vorhersehbar.

    Man könnte höchstens überlegen, ob man einige Adressbereiche, von denen man weiß, dass man sie garantiert nie brauchen wird, von vornherein ausschließt. Was weiß ich, wenn du weißt, dass du nie aus China heraus auf deinen SSH zugreifen wirst, kannst du entsprechende IP-Bereiche sperren. Das ersetzt aber nicht, die nötige Sicherheit deines SSH-Servers selbst. Denn der Bösewicht sitzt im Zweifelsfall direkt neben dir.
    Lookbehind ist offline

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •