Qnap NAS IP Blockierung aufheben

[Tiu]

Moin moin,

ich habe in meinem Qnap NAS eine blockierte IP die ich gerne wieder entsperren möchte.
Unter Control Panel / Sicherheit / Erlauben-Verweigern wird mir die blockierte IP angezeigte. Wenn ich diese aber mit Haken setzen und Entfernen - Übernehmen drücke erscheint die Meldung "Konfiguration nicht erfolgreich" und die IP ist weiterhin blockiert. Natürlich bin ich als Administrator mit vollen zugriffsrechten eingeloggt. Warum übernimmt er die Aufhebung der Blockade nicht?

 

[iSource]

Gerade bei mir getestet, das Entfernen funktioniert hier ebenfalls nicht.

Modell: TS-873
Firmware: 4.4.1.1216
Browser: Firefox 74.0 und Chrome 80.0.3987.149

Ich nutze die Funktion nicht, habe aber gerade testweise einfach mal eine IP hinzugefügt (was geklappt hat) und wollte sie dann wie du über das Web Interface wieder entfernen. Ergebnis: Gleicher Fehler wie bei dir.

Wenn du mehrere IPs drin hast, kannst du die allerdings auch problemlos über die Shell rausnehmen. Dazu einfach die /etc/config/ipsec_deny.conf entsprechend anpassen.

 

[chrigu]

den bug an den qnap Support melden !

 

[Tiu]

Im Dezember mit der vorletzten Firmware ging es noch
Dachte schon ich hätte vielleicht irgendwo eine Einstellung geändert die es verhindert.

 

[iSource]

@Tiu: Halte mich und uns mal bitte auf dem Laufenden. Ich würde die Config gerne wieder sauber wegbekommen - bisher keine *.conf-Datei gefunden, welche diese Radio Buttons steuert:

Man kann nämlich auch nicht mehr auf "Alle Verbindungen zulassen" stellen, da auch dort der Fehler auftaucht. Ist zwar technisch irrelevant, aber ich würde es trotzdem gerne wieder richtig setzen, wenn die Liste darunter eh schon leer ist.

 

[Tiu]

Habe gerade eine Mail an den Support geleitet, hoffe die melden sich zeitnah!

 

[Tiu]

So, also der Support löscht nun via Fernwartung meine gesperrten IP´s.
Alternativ hat er mir vorgeschlagen auf die Vorgängerversion zu downgraden und auszuprobieren, ob es dort funktioniert

 

[iSource]

Wow... 😒

Recht sicher macht er das dann auch über die Shell, weil die GUI dahingehend ja offensichtlich "kaputt" ist.

Wenn du die Chance hast zu fragen, wie man die Radio Buttons ändern kann, wäre das super.

 

[Tiu]

Noch immer nicht ganz behoben

vielen Dank für Ihre Nachricht. Auf Nachfrage in Taiwan konnte mir bestätigt werden, dass dieser Fehler in einer der Kommenden Firmware Versionen behoben wird. Zwei IPs konnte ich, jeweils einzeln, aus der GUI löschen. Die dritte IP könnte ich nur per SSH Zugriff löschen. Leider habe ich per SSH keinen Zugriff auf Ihre NAS, da die Kennwortabfrage für den Nutzer: Admin erscheint, für die ich kein Passwort habe. Bitte prüfen Sie die Einstellungen auf Ihrer NAS. Der Standardport für den SSH-Zugriff auf Ihrer NAS sollte der Port 22 sein und der "_qnap_support" Nutzer sollte die Berechtigung haben zuzugreifen.

 

[Raijin]

Der Standardport für den SSH-Zugriff auf Ihrer NAS sollte der Port 22 sein und der "_qnap_support" Nutzer sollte die Berechtigung haben zuzugreifen.

Ja ne is klar.. Und der Nutzer soll natürlich auch 24/7 Zugriff auf das NAS haben, was?

Wenn, sollte man diesen Nutzer dann nur temporär für die Dauer des Supports zulassen. Sonst hätte QNAP zumindest theoretisch die Möglichkeit, jederzeit auf das NAS zu gucken. Das wäre vielleicht noch halb so wild, weil ich QNAP keine böswilligen Absichten unterstellen möchte, aber wenn der Nutzer _qnap_support dann auch noch ein Standardpasswort hat wie der berüchtigte lkwpeter, dann wird gefühlt spätestens der 4. ssh-bot einen Treffer landen und das NAS ist offen wie ein Scheunentor und man hat ungebetene Besucher.

 

[Tiu]

Also ich verwende nie die Standardports. Selbst wenn ich dem Support Zugriff gewährt hätte, wäre er nicht über den Standport hineingekommen!
Die Zugriffsberechtigung ist ja zeitlich begrenzt... Außerdem kann ich ihn zu jederzeit auch manuell kicken.
Blöde ist halt nur, dass die mein Problem in der neuesten Firmware verbockt haben. Um das Problem selbst zu lösen, müsste ich eine ältere Firmware installieren... ist aber auch blöde, von daher soll der Support mal einen Tag hier arbeiten!

 

[Raijin]

Also ich verwende nie die Standardports.

Was jedoch nur gefühlte Sicherheit bringt. Security by Obscurity. Das ist so wie Atomkraftwerke, die sich mit Nebelwerfern vor Angriffen schützen wollen. Das AKW bleibt hinter dem Nebel aber so angreifbar wie zuvor. Das gilt auch für ssh. SSH mit starkem Passwort oder besser noch zertifikatsbasierter Authentifizierung kann problemlos auf TCP 22 laufen. Auf einem Alternativport wird nur das syslog kürzer, aber sicherer wird's dadurch in keinster Weise.

Die Zugriffsberechtigung ist ja zeitlich begrenzt...

Das ist gut. Ich hatte nur die Befürchtung, dass das bei QNAP so Standard ist. Aber dann war meine Sorge unbegründet

 

[Tiu]

Ja und Nein
Die Wirksamkeit des Schutzes ist dabei gegen Standardangriffe gegeben.
Es ist so ähnlich wie bei vielen BruteForce Attacken. Wenn man, egal ob im Router oder NAS, den Benutzernamen schon auf Admin belässt, ist man um ein vielfaches angreifbarer als wenn man eben auch den Benutzernamen "und" das Passwort ändert!
Verbunden mit zusätzlich 2FA und dann darf mich jeder versuchen mit BruteForce zu attackieren
Die Änderung der Standardports ist eben auch ein Zahnrädchen innerhalb des gesamten Sicherheitskonzeptes!

 

[Raijin]

Wie gesagt, nein. Du reduzierst nur die Anzahl der Angriffe, die bei einem gut gesicherten Zugang sowieso ins Leere laufen. Dies sind aber lediglich die flyby-Attacken, quasi der Passant, der an deiner Haustür anhält und guckt ob abgeschlossen ist oder nicht. Ist abgeschlossen (Passwort stark oder gar nur mit Zertifikat), geht er weiter. Der versierte Einbrecher versucht aber nicht nur die Türklinke, sondern will das Schloss knacken. Versteckst du nun die Türklinke umme Ecke, hat der Passant auch nix zu drücken, er taucht im Log also nicht auf, weil er einfach schulterzuckend dran vorbeigeht. Der versierte Einbrecher sucht die Türklinke aber, findet sie binnen Sekunden und macht sich sofort daran, das Schloß zu knacken wie er es auch getan hätte, wenn die Türklinke noch offen sichtbar gewesen wäre.

Das heißt du vermeidest nur die halbherzigen Angriffe von Skriptkiddies, die du durch eine adäquate Absicherung des ssh-Zugangs eh schon abwehren würdest. Einem "Profi" ist es egal auf welchem noch so obskuren Port dein ssh läuft. Wenn er will, findet er ihn binnen Sekunden.

Aber gut, diese Diskussion ist so alt wie das Internet und eigentlich wollte ich nur auf den _qnap_support User hinweisen (weil es so klang als wenn der standardmäßig immer aktiv ist).
Solange man darauf achtet, dass ssh ungeachtet des Ports abgesichert ist, kann man den Port ändern wenn man will oder man lässt es eben bleiben. Das darf also maximal eine zusätzliche Maßnahme sein. Immerhin wird das syslog etwas kürzer (und ich weiß wovon ich diesbezüglich rede ) . Ich habe aber auch schon Leute getroffen, die meinten, dass es ausreicht, den Port zu ändern - auf sowas uuuuuunglaublich kreatives wie 2222 und mit admin/admin, versteht sich. Zitat: "Den Port findet ja niemand"
Wenn das bei dir nicht der Fall ist, ok, aber man kann nicht oft genug darauf hinweisen, weil es genug unbedarfte Menschen gibt, die nur hier und da ein paar Schlagworte aufschnappen

In diesem Sinne

 

[iSource]

@Tiu und andere, die das Thema hier über die Suche finden:
Der Bug ist - zumindest bei mir auf einer TS-873 - mit Version 4.4.2.1270 behoben.

 

[Tiu]

Ich muss es mal versuchen! Danke für den Hinweis