SSH Angriffe

    Seit einiger Zeit verzeichne ich vermehrt SSH Angriffe auf meiner NAS. Hier mal ein Ausschnitt:

    pasted-from-clipboard.png


    Frage: Ich habe SSH abgeschaltet, nicht mal ich im eigenen LAN kann eine Verbindung aufbauen. Wie schaffen die das, dass ein "Login Fail" kommt?

    Dazumal SSH (wenn ich es mal brauche), nur im LAN zugänglich ist und mit einem atypischen Port, den man nur durch abscannen finden könnte.

    Aber da ich den im Router nicht weiterleite, frage ich mich allen ernstes, wie die NAS SSH Logins verzeichnen kann.

    Im Router tauchen auch keine fremden Geräte oder User auf.


    Kann ich irgendwo rausfinden, ob die NAS und ihre DDNS irgendwo im Netz auftaucht und man es darüber versucht?

    Oder andere Tipps, wie ich hier prüfen kann, was da abgeht?

    Das klingt strange. Die IPs kommen auf jeden Fall von außerhalb, hast du evtl UPnP am NAS und Router aktiv?

    Das ist ja nun auch schon einige Zeit her, finden die Versuche immer noch statt oder war das nur dieser Zeitraum?

    Da wird dein SSH frei im Netz sein (Port Weiterleitung) jegliche Port Weiterleitungen aufs NAS sind extrem gefährlich.


    Sofort im Router Port Forwards und upnp deaktivieren !

    Das verrückte ist doch aber, dass ssh gar nicht aktiv ist...

    Jo wie du gesagt hast .. möglicherweise momentan deaktiviert aber zu der Zeit (wo die Logs her sind) war's aktiv?

    Einmal editiert, zuletzt von dolbyman ()

    Kk, wollte nur sicher gehen, dass es nicht wirklich noch irgendeine weitere Möglichkeit gibt.

    HeeroYuy was hast du für einen Router/Firewall? Kann man da in dem Zeitraum irgendwas in den Logs erkennen? ZB Steuerungen durch UPnP?

    Das ist ein ASUS RT-AC87u. Sämtliche Schutzfunktionen (DDOS-Schutz, Firewall, usw von TrendMicro) darin sind aktiviert. Einzige Weiterleitungen sind diese hier:


    pasted-from-clipboard.png


    Vorhin waren wieder einige dabei, als ich kurz SSH aktiv hatte, um was zu schauen. Liegt wohl an UPnP, weil das ist tatsächlich aktiviert. Hier im Verbindungslog taucht der SSH Port auch auf mit Vermerk auf UPnP..shit. Jetzt müsste ich nur noch wissen, warum UPnP aktiv ist, weil ich das ganz sicher aus hatte.

    SourceDestinationProtocolPort rangeRedirect toLocal Port
    ALLALLTCP5613192.168.1.115613

    "Einzige" ist gut... Das ist echt übel und sollte gerade deine größte Sorge sein!

    Stell das echt lieber ab, sonst sind solche ungewöhnlichen Beobachtungen wie das SSH Ding gar nicht mehr so ungewöhnlich!

    Das ist ja schonmal das volle Programm and Sicherheits Fiaskos ....NIEMALS irgendwelche QTS Ports ans Web weiterleiten .. Malware Verbrecher lieben sowas

    Mod: Unnötiges Volltext-/Direktzitat entfernt! :handbuch::arrow: Forenregeln beachten und Die Zitat Funktion des Forums richtig nutzen


    was wäre denn die beste Lösung, wenn man lauter unterschiedliche Endgeräte hat mit unterschiedlichen Betriebssystemen, die auch außerhalb des LAN Zugriff auf unterschiedliche Dienste brauchen?


    FTP und Nextcloud Zugriff wären das mindeste. Und allein das bereitet auf Applegeräten nur Probleme, weswegen DAS hier bisher die praktikabelste Lösung war.

    Zitat von HeeroYuy

    wäre denn die beste Lösung, wenn man lauter unterschiedliche Endgeräte hat mit unterschiedlichen Betriebssystemen, die auch außerhalb des LAN Zugriff auf unterschiedliche Dienste brauchen?

    Externe Daten am besten onedrive,dropbox,etc. teilen.. Diese "Private Cloud" Geschichten sind halt leider nix für private NAS


    Zitat von HeeroYuy

    FTP und Nextcloud Zugriff wären das mindeste. Und allein das bereitet auf Applegeräten nur Probleme, weswegen DAS hier bisher die praktikabelste Lösung war.

    Praktisch ist halt leider nicht sicher.. FTP ist ja extrem veraltet und wenn dann mal wieder ein 0-day für den verwendeten FTP Server rauskommt ists vorbei.


    Nextcloud kann man machen, würde ich aber auf keinen Fall direkt auf dem NAS betreiben, wird das Ding nicht akutell gehalten oder es gibt ne 0-day ist das ganze NAS mit in Gefahr, da der WebServer auf root läuft.

    Wenn überhaupt, sowas via Container oder VM laufen lassen! (abgeschottet vom NAS)

    Einmal editiert, zuletzt von dolbyman ()

    Zitat von tiermutter

    Praktikabel und gefährlich... lass Dir da mal lieber was anderes einfallen, vor allem 443 und 80 ist absolutes Nogo!

    Es ist schon fast ein Wunder, dass es Dich noch nicht übel erwischt hat (was nichtmal auszuschließen ist).

    Noch so ein Kritikpunkt an QNAP:

    Gelegentlich hatte ich früher schon mal den externen Zugang für den taiwansischen Support geöffnet. Bin mir eigentlich ziemlich sicher, dass ich früher dafür nie irgendwelche Ports freigeben musste. Heute erfordern die aber das Öffnen sämtlicher dieser Standardports. Das kann dann schon eine Woche oder länger dauern. Heute sage ich dann lieber, dass ich auf diese Form des Supports verzichte - der mir in meinen Fällen ehrlich gesagt eigentlich auch nie wirklich weitergeholfen hat als der Standardsupport.

    Das muss aber schon länger her sein... Ich kenne diese Anforderung auch noch aus Tickets, aber mittlerweile ist das öffnen von Ports dafür nicht mehr erforderlich.

    Ganz laut "Bloß nicht!" schreien ist das Mantra hier im Forum, wenn es um Zugriffe von außen geht. Das ist jetzt nicht falsch, wenn man bedenkt, dass hier immer mal wieder Hilfesuchende vorbeikommen, die nur verschlüsselte Daten auf ihrem NAS vorfinden, aber im Detail sehe ich das anders.


    Zitat von HeeroYuy

    was wäre denn die beste Lösung, wenn man lauter unterschiedliche Endgeräte hat mit unterschiedlichen Betriebssystemen, die auch außerhalb des LAN Zugriff auf unterschiedliche Dienste brauchen?

    Da würde ich zwei Konzepte kombinieren, d. h. gleichzeitig nutzen.


    1) Nur Dienste verwenden, die eine erwiesen hohe Sicherheit bieten.


    Eine Möglichkeit ist ein Zugriff über ein VPN. Damit stehen alle Möglichkeiten wie im LAN offen. Der VPN-Server befindet sich meistens auf dem Router (also nicht auf dem NAS, daher keine Portweiterleitung zum NAS).


    Eine weitere Möglichkeit ist ssh (mit Portweiterleitung auf das NAS). ssh ist nur so sicher wie die verwendeten Passwörter (insbesondere auch Passwörter "vergessener" Zugänge wie einem Standard-Passwort zum nicht benutzten Admin). Wenn ssh auf ausschließlich ssh-Keys umgestellt wird, ist die Sicherheit vergleichbar mit VPN. Mit sftp gibt es einen sicheren Dateitransfer dazu, über ssh-Tunnel kann das GUI im Browser erreicht werden oder Netzlaufwerke verbunden werden. ssh bietet nicht die Flexibilität von VPN, läuft aber meiner Erfahrung nach bei schlechten Internetverbindungen stabiler und kann manchmal eingesetzt werden, wenn VPN aus gewissen Gründen nicht geht.


    Nicht sicher ist hingegen http(s), da das eine viel größere Angriffsfläche bietet, und da die Sicherheit vom Webserver und der darauf laufenden Anwendung (z. B. die qts-GUI) abhängt, und gerade letztere ist vergleichsweise schlecht auf Sicherheit getestet (allgemein, nicht nur qts).


    Gar nicht geht ftp im Original, da dabei selbst die Login-Daten im Klartext übertragen werden und für jeden "Man in the middle" lesbar sind. Die sicheren Varianten sftp und ftps können hingegen genutzt werden, siehe zu ssh.


    2) Ein Backup machen, das sicher gegen Verschlüsselungssoftware ist. Behalte im Hinterkopf, dass du einen Fehler in Punkt 1) gemacht haben könntest oder dass dein Programm einen Fehler (Sicherheitslücke) hat. Selbst wenn du dein NAS nicht freigibst, ist dies sinnvoll, denn die Verschlüsselungssoftware könnte auch durch einen versehentlich angeklickten bösartigen Mailanhang auf dein System gelangen.


    Verschlüsselungstrojaner zerstören gerne alle erreichbaren Backups, weil das die Zahlungsmoral der Opfer hebt. Daher muss es ein Backup geben, das nicht vom NAS aus erreichbar ist. Im einfachsten Falle sind das zwei abwechselnd genutzte USB-Festplatten, von denen immer mindestens eine gerade nicht an das NAS angeschlossen ist.

    Zitat von tiermutter

    aber mittlerweile ist das öffnen von Ports dafür nicht mehr erforderlich.

    Beziehst Du Dich dabei auf das Allgemeine oder speziell auf QNAP? Also ich bin mir absolut sicher, dass ca. 2018 die Forderung nicht explizit gestellt wurde, in einem Ticket vor ca. 3-4 Wochen hingegen doch.

    Ich beziehe mich speziell auf QNAP.

    Ich würde es eher andersrum verstehen... 2018 die Forderung und heute nicht mehr.

    Demnach https://docs.qnap.com/operatin…52-85F2-311DA328CB0B.html scheint es nicht erforderlich zu sein... Demnach https://www.qnap.com/de-de/how…reitstellung-von-feedback aber explizit schon.

    Jetzt müsste irgendwas davon von jemanden bestätigt werden, der in letzter Zeit schonmal remote Support erhalten hat.


    Edit: wobei sich die offenen Ports eventuell auf die QuFirewall beziehen...

    Zitat von tiermutter

    Jetzt müsste irgendwas davon von jemanden bestätigt werden, der in letzter Zeit schonmal remote Support erhalten hat.

    In der Antwort vom 17.03. diesen Jahres auf eines meiner aktuellen Tickets:

    Naja... Das steht da... Bei mir auch in einem aus Juni 21. Aber bei QNAP hat das ja nicht unbedingt was zu bedeuten X/