TS-453B ständige Angriffe von fremden IP Adreessen

  • Wieso nicht? Es gibt die Clients für Win, Linux, IOS, Android,...?

    Ja schon klar... aber in meiner Arbeit darf ich nix installieren ;)

    Das höchste der Gefühle wäre ein Chrome-Plugin... wenn es hier etwas gibt, wäre ich auch schon happy...

  • Ganz ehrlich? Dann besorg Dir ein kleines Notebook, das Du entweder mit dem Gästewlan oder per handyhotspot nutzt.

    Und dann per VPN.


    Oder, Du darfst Teamviewer nutzen...

    Je nach NAS ein virtuelles Maschinchen aufsetzen (Windows 10 gibt's für kleines Geld).



    Alles andere ist in meinen Augen grob fahrlässig.


    Und hinterher landen hier wieder Threads, weil das NAS gekapert und verschlüsselt wurde...


    Siehe diesen hier: <<<KLICK>>>

  • Kann ich irgendwie einstellen, dass eine IP automatisch nach zB 4 Fehlversuchen für immer gesperrt wird.

    Geht doch. Bei "Dauer der IP-Sperre" kannst du auch einen Tag oder "immer" auswählen. Ich würde einen Tag wählen. Mit "immer" legt man sich sonst selbst rein, wenn beim Anmelden die Caps-Lock-Taste gedrückt war.

    Aber nicht so wie es über die GUI möglich ist, innerhalb von 30 Min 5 Fehlversuche - das ist mir zu locker.

    So locker ist das nicht, zumindest wenn du keine Trivialpasswörter oder wiederverwendete Passwörter (überall das gleiche) hast. Um die Einschränkung zu umgehen, dürfte ein Angreifer maximal vier Versuche in 30 Minuten haben. Wenn dein Passwort aus sechs Ziffern bestehen sollte - was als viel zu unsicher gilt - bräuchte der Angreifer schon 1 Million Versuche, das Passwort zu erraten, was bei 4 Versuchen in 30 min bereits über 14 Jahre bedeutet, mit sieben Ziffern sind es über 140 Jahre, und wenn du außer Ziffern noch Buchstaben oder andere Zeichen im Passwort hast, ist die Zeit jenseits von gut und böse.


    Ein anderes Angriffsszenario zur Umgehung dieser Einschränkung ist ein verteilter Angriff über ein Botnetz, bei der die Login-Versuche von einer Vielzahl verschiedener IP-Adressen kommen. Da könnten in kurzer Zeit tausende von Login-Versuchen zusammen kommen. Bei sicheren Passwörtern dauert das aber auch seine Zeit, und das fällt dir auf. Außerdem ist der Angriff für den Angreifer aufwendig, d. h. idR. nicht lohnend.


    Ein weiterer Angriff ist ein Exploit über einen Fehler in der Implementierung deines ssh-Servers. ssh gilt hier aber als sehr sicher, da weit verbreitet und dadurch sehr gut getestet.


    Hier wird immer sofort VPN geschrien. Ganz verkehrt ist das nicht, insbesondere Laien gegenüber, da die ersten beiden beschriebenen Angriffsszenarien nicht möglich sind und die Gefahr durch unsichere Trivialpasswörter oder vergessene Admin-Zugänge mit Standardpasswörtern nicht besteht. Die Gefahr eines Exploits, der Implementierungsfehler ausnutzt, besteht hier aber auch, und ich halte sie für größer als bei ssh, da die Implementierung komplizierter ist und es mehr unterschiedliche VPN-Varianten gibt (d. h. weniger getestet/untersucht).


    Du kannst mit ssh dasselbe Sicherheitsniveau wie mit VPN haben, wenn du Login ausschließlich über ssh-Keys zulässt. Allerdings darfst du dann dein Endgerät nicht verlieren (gilt für VPN auch).


    Ein Restrisiko bleibt immer. Auch der Router könnte eine Sicherheitslücke haben und für einen Exploit anfällig sein. Höher ist aber die Gefahr, dass du dir ein Schadprogramm durch die ausführung eines bösartigen Programmes auf dem PC selbst einschleppst.


    Wenn du dich gegen dieses Restrisiko absichern willst, kauf dir zwei USB-Platten, die du abwechseln einmal im Monat ansteckst und dann ein Backup machst. Nach dem Backup wieder abziehen, und eine Platte außer Haus lagern. Da können dir maxima die Daten eines Monats verloren gehen. (Zwei Platten, da der Krypto-Trojaner dann zuschlagen könnte, wenn gerade ein Backup läuft.)


    Und nimm für ssh einen anderen Port als 22 (am Router).



    Edit:

    Siehe diesen hier: <<<KLICK>>>

    Da war aber nicht ssh das Einfallstor, sondern vermutlich die Qnap-Cloud, und die ist aus verschiedenen Gründen deutlich unsicherer.

  • Danke für die ausführliche Antwort Anthracite ... das ist sehr viel Information auf einmal.

    Du hast recht, wenn Du schreibst, dass es mit diesen paar Versuchen am Tag wohl mehr als ewig dauern wird, bis man per Zufall auf meine 16 Stellen gemischt mit Sonderzeichen, Groß, Klein, etc... kommt.

    Dennoch ist es einfach "nervig".


    Den SSH Port habe ich nicht auf 22 - der ist sowieso ein anderer.

    Auch der HTTPS Port ist ein anderer, aber ich werde wohl nochmals alles ändern - möglicherweise ist dann wieder für eine Weile "Ruhe"...


    Danke für Euren Input in dieser Frage: Wie immer wird man mit viel Information bezüglich Sicherheit "erschlagen" 8) (was ja auch gut ist).

    Aber meine eigentliche Frage wurde nicht so wirklich geklärt: Aber ich gehe mal davon aus, dass man KEINE weitere Regel einstellen kann um nach zB 3 fehlgeschlagenen Anmeldungen innerhalb von zB 5 Stunden bereits eine IP für immer sperren kann.


    5 Versuche innerhalb 30 Min sind wohl das "schärfste" was qnap anbietet und mehr geht nicht... schade eigentlich, dass man diese Werte nicht frei einstellen kann... :|


    Danke jedenfalls für alle Infos und die Hilfen !!

  • Da wird es sicherlich irgendwo eine config Datei geben in der man von den durch die GUI vorgegebenen Werte abweichen kann. Diese wiederum würde nach jedem restart wieder überschrieben werden, ....


    Das ändern der ports wirst du dir sicherlich sparen können, die sind genau so schnell ausgemacht wie deine alten wenn du ohnehin schon vom Standard weg bist.

  • Ja schon klar... aber in meiner Arbeit darf ich nix installieren


    Privates NAS verseucht. Es wird sich vom Firmennetz aufs NAS eingelogt, die Seuche springt ins Firmennetz. Klage am Hintern. Job los. Aber Hauptsache aufs NAS gekommen. Wäre ich dein Arbeitgeber und würde das mitbekommen, würde ich Dich rausschmeißen.

  • Wenn unbedingt mit dem NAS Daten von außerhalb getauscht werden müssen, kann ich Hybridmount ans Herz legen.


    Also ein NAS Ordner wird beidseitig mit der Cloud Synchronisiert und wird am NAS sogar via Freigabe bereitgestellt.


    Also ohne VPN oder Browserplugin Daten tauschen und man stellt keine direkte Netzwerkverbindung nach Hause her.

  • Auch SSH hatte schon so einige Lücken und es werden auch noch welche folgen.

    Denn da steckt SSL hinter was lange als absolut sicher galt bis dann Tag x kam.

    Aber auch Intel galt als sicher bis dann Tag y kam.


    Aber da gerade VPN Implementierungen dafür gedacht sind, von außen erreichbar zu sein, sind diese besonders harte Gegner.

    Da mache ich mir sehr wenig Sorgen das hier was reinschlägt.

    Aber möglich ist immer alles.


    Was aber wahrscheinlich ist, das QNAP irgend nen Schrott im php verbaut hat, was dann über den https Port durchschlägt.

    Einfach abwarten, ist ja wie in einem Honeypot, irgendwann kommt die Killerbine vorbei und sticht zu.

  • Kann ich irgendwie einstellen, dass eine IP automatisch nach zB 4 Fehlversuchen für immer gesperrt wird.

    IP-Adressen dauerhaft sperren bringt exakt gar nichts.

    Kein ernsthafter Angreifer ist so dumm, eigene IP-Adressen für Angriffe zu nutzen.

    Das kommt immer über wechselnde Adressen fremder gehackter Systeme.

    Sperrst du eine, geht's von der nächsten weiter.


    Wenn es um wirkliche Sicherheit geht, ist eine Sperre für 5 Minuten genauso gut wie eine "ewige" Sperre. (Ein hinreichend langes und zufälliges Passwort vorausgesetzt.)

    Wenn es um das Genervtsein durch die Meldungen geht, gibt es nur die Alternative: Abschalten.

    Wie gesagt: was im Internet erreichbar ist, wird auch angegriffen.

    Auch SSH hatte schon so einige Lücken und es werden auch noch welche folgen.

    Denn da steckt SSL hinter was lange als absolut sicher galt bis dann Tag x kam.

    Das kann ich so nicht stehen lassen.


    Erstens steckt nicht SSL hinter SSH. SSH und SSL sind zwei völlig unterschiedliche Protokolle. Bestimmte Implementierungen dieser beiden Protokolle benutzen (wie fast alles in der Softwarewelt) teilweise die gleichen Komponenten, und wenn ausgerechnet in einer solchen Komponente ein sicherheitsrelevanter Fehler steckt, ist das natürlich blöd. Aber weder ist damit gesagt, dass sich der Fehler in beiden Implementierungen in gleicher Weise als Sicherheitslücke niederschlägt. Noch hat jede Sicherheitslücke von SSL auch eine Sicherheitslücke von SSH zur Folge oder umgekehrt.


    Zweitens hat kein vernünftiger Mensch SSL jemals für absolut sicher gehalten. Ganz im Gegenteil: von Anfang an wurden Angriffsszenarien diskutiert, ja sogar (die Älteren unter uns erinnern sich) absichtlich die Sicherheit für Anwender außerhalb der USA eingeschränkt, immer wieder neue Verschlüsselungs- und Hash-Algorithmen eingeführt, Schlüssellängen diskutiert und Empfehlungen angepasst. Es ging nie um absolute Sicherheit, immer nur darum, den Aufwand für den potentiellen Angreifer hoch genug zu treiben, dass ein erfolgreicher Angriff unwahrscheinlich oder für den Angreifer unwirtschaftlich wird.


    Und drittens gab es keinen Tag x. Bei beiden Protokollen und bei allen ihren Implementierungen wurden und werden laufend Fehler und Sicherheitslücken gesucht, gefunden und behoben. Mal größere, mal kleinere. Mal solche, die den Einsatz komplett infrage stellen und mal solche, wo Ottilie Normaluser sagt "so what". (Wenn sie Englisch kann.) Ab und zu schrie die Presse dann "Super-GAU" und der Fachmann schüttelte den Kopf. Aber "Tag x", vorher sicher, nachher unsicher? Nö.