DSM 6.x und darunter 7.1-42661 Update 1

[odol26]

Mir wurde gerade eben ein Update angeboten.
Installation lief erfolgreich mit Neustart durch.
Das Einzige der SMB Dienst mußte anschließend repariert werden.

(2022-04-27)
Important Note

1. The update is expected to be available in all regions shortly. If you want to update your DSM to this version now, please click here.
2. This update will restart your Synology NAS.
3. If users' Synology NAS aren't connected to the Internet, they must download SMB Service 4.10.18-0434 from the Download Center and manually install it after the DSM update to make sure the package functions properly. Note: Before users install SMB Service 4.10.18-0434, the package and its dependent package, Synology Directory Server, will be deactivated.

Fixed Issues

1. Fixed an issue where users couldn't upload files to DSM via the Finder on macOS Big Sur 11.
2. Fixed multiple security vulnerabilities regarding Netatalk (CVE-2022-0194, CVE-2022-23121, CVE-2022-23122, CVE-2022-23123, CVE-2022-23124, CVE-2022-23125).

 

[Adrian-S]

War bei mir gerade auch so. Läuft aber alles.

 

[roterteufel81]

Bug in dieser Version, der mir erst mal den Schweiß in die Stirn trieb:

Synology sendete eine Mail zu, dass die IP-Blockierliste die maximale Größe erreicht hat.

Ich erst mal Puls, ob es da einen Massen-Login Versuch über DDNS gegeben hat.

Gleich mal Remote auf die Kiste drauf.

Ergebnis im Logfile: Ein einziger bekannter Client hatte sich durch zu oft falsches PW eingeben in zu kurzer Zeit (User Problem) selbst ausgesperrt mit einer einzigen IP.

Länger war die Liste nicht und es gab auch ansonsten keine Login Versuche.

 

[Mavalok2]

Bei einer blockierten IP-Adresse kann man ja eigentlich nicht von einer Liste sprechen. Eine IP als Maximum ist schon etwas wenig. Kannst Du die exakte Meldung posten? Was steht im Protokoll?

 

[geimist]

Am Donnerstag hatte ich dieselbe Meldung. Allerdings hab ich ~40.000 Einträge in der DB, die ich mit blocklist.de abgleiche. Daher fand ich ein Limit zwar nicht schön, aber auch nicht wirklich verwunderlich.

Aber wenn ich das jetzt hier lese, scheint es ja nicht wirklich an der Länge der Liste zu liegen.

Die DB liegt hier, wenn du mal reingucken möchtest: /etc/synoautoblock.db

Ihre Blockierungsliste auf Diskstation ist zu lang. Kontrollieren Sie die IP-Adressen unter Systemsteuerung > Sicherheit > Schutz > Automatische Blockierung.

Versuchen Sie Folgendes:

• Wenn die IP-Adressen manuell hinzugefügt wurden, könnten Sie diese stattdessen mit der Firewall blockieren.
• Wenn die IP-Adressen automatisch erstellt wurden, kontrollieren Sie Ihre Regel für die automatische Blockierung.

Von Diskstation

 

[roterteufel81]

Genau diese Meldung mit dem Hinweis in deinem Zitat kam bei mir per Email.

Meine Analyse dazu steht im nächsten Beitrag.

 

[roterteufel81]

So, ich habe mir mal die Mühe gemacht und alles nachgeprüft und lege es mal Schritt für Schritt dar, was passiert ist:

Jeder User muss zum Login einer App (DS Finder, Synology Photos, DS File, DS Cam, usw.) via Smartphone / Tablet via HTTPS DDNS zusätzlich einen 2FA Login via Google Auth machen. Das klappt auch super.

Bei der iOS App KyPass, die via WebDav auf meine Keepass Datenbank zugreift, funktioniert das jedoch ganz so korrekt, da diese kein Google Auth unterstützt. Ist aber nicht schlimm, warum steht im Weiteren erklärt.

Zunächst hatte sich der Client am besagten Tag (11.05. 01:22 Uhr) zu oft mit der iOS App KyPass eingeloggt, was von Synology mangels der 2FA Unterstützung der KyPass App als Fehlversuch eingestuft wird, sie funktioniert aber (kurioserweise) trotzdem und ruft auch die Datenbank via WebDAV ab, bekommt aber einen Login-Fehlversuch pro Abruf auf dem Strafkonto aufgebrummt. Das ist soweit kein Problem, da es mir bekannt ist.

Dieser Login ist aber nur notwendig, wenn man mal eine neue lokale Version der Datenbank auf seinem Smartphone / Tablet haben möchte.

Wenn ich mich dann später im Safari mit Keepass auf einer Webseite einloggen will, ruft er nur die aktuelle lokale Version auf dem Smartphone ab, ohne jedesmal einen Login auf das NAS zu benötigen. Daher akzeptiere ich das so.

Der besagte gesperrte Client hatte im Unwissen dieses Umstandes zu oft hintereinander die KyPass synchronisierung gemacht, weil er rumgespielt hatte.

Aber das ist auch nur der Hintergrund, wie es bei mir zu Sperrung kam und auch egal, weil es hätte jeder irgendwie geartete (echte) falsche Loginversuch sein können.

Sieht dann im Protokoll-Center unter Verbindung so aus (Beispiel. von gestern Abend, zwangserzeugt, indem ich einfach mal paar Mal mit der KyPass App in kurzer Zeit synchronisiert habe, um Protokolleinträge zu erzeugen.)




Sollte das Sperrlimit überschritten werden (10 Login Fails in 5 Minuten), sieht es im Protokoll Center unter Allgemein korrekt so aus (Das ist der Original Protokoll Eintrag vom 11.05. 01:22 Uhr). Ansonsten gibt es unter Allgemein über 4 Monate rückwärts keinerlei Warnungen, die mit Login und IP-Sperrung in Zusammenhang stehen:




Wenn man dann die Blockierliste aufgerufen hat, gab es dort genau diesen einen Eintrag dieser IP, die gerade gesperrt wurde (hier schon wieder leer, habe den Client schon freigegeben):



Gleichzeitig gab es dann via Email zunächst die mir bestens bekannte korrekte Information, dass die angesprochene IP um 01:22 Uhr gesperrt wurde:




Direkt danach kam dann aber die entscheidende Mail, die mir den Schweiß auf die Stirn trieb. So eine Email habe ich bei all den Sperrungen in den vielen Jahren noch nie gesehen:




Und das scheint mir dann der Bug zu sein?

Die Datenbank habe ich via SSH der Vollständigkeithalber auch mal aufgerufen, die sieht für mich von der Größe her unauffällig aus:




Gruß

 

[geimist]

Meine DB hat eine Größe von über 10MB. Aber auch bei mir kam die Mail nach einer automatischen Blockierung (hier der Mailserver). Ich vermute, dass sich da was im DSM verschluckt.

 

[roterteufel81]

Ich habe es gerade auf meiner eigenen Synology mit komplett leerer Blockierliste beliebig reproduzieren können.

Für jede Email einer blockierten IP kommt zusätzlich eine zweite Email mit der Info, dass das Limit der Blockierliste überschritten wurde.

Auch hier war es jeweils der erste Eintrag in der Liste.

Muss ich wohl mal wieder ein Ticket bei Synology eröffnen

 

[DerIng]

Ist das normal, das bei meiner DS218+ das Update auf 7.1 nicht gefunden wird.

 

[roterteufel81]

Ticket bei Synology ist eröffnet.

@DerIng :

Ja, das kann sein.

Manuell aber hier zu finden:

https://archive.synology.com/download/Os/DSM

Solltest Du auf einer Beta <7.1-1 oder auf einer Version unter 7.1 gewesen sein, musst Du das 7.1-42661-1-NanoPacked (Vollversion) ziehen, wenn Du schon auf 7.1-42661 warst, reicht das 7.1-42661-1 (Mini-Update)

 

[EDvonSchleck]

Das ist ja nicht unbedingt was neues, dass Updates online nicht angezeigt werden.

Habe irgendwo einmal gelesen das man die Netzwerkeinstellungen von Statisch auf DHCP und zurück stellen soll. Danach sollen die Updates angezeigt werden, sofern sie auf den Server liegen - das muss nicht der Fileserver sein!

 

[roterteufel81]

Nein, an der DHCP Einstellungen liegt es eher nicht. Vielmehr daran, dass nie alle DS gleichzeitig Auto-Update erhalten. Das geht immer in Tranchen. Die von mir verwalteten 920+ und 416Slim hatten auch Tage nachdem das Update war noch keine Benachrichtigung erhalten. Habe es dann einfach manuell drüber gebügelt. Bei 7.0.1 waren sie dagegen direkt am ersten Tag dabei.

Ansonsten gibt es ja eine Liste der DS, die keine Auto-Benachrichtung mehr bekommen. Alle anderen bekommen es früher oder später:

 

[Mavalok2]

Ich persönlich ziehe das manuelle Update vor, also von HP herunterladen und per WebGUI unter kontrollierten Bedingungen installieren, so mit aktuellem Backup, Sicherung der Einstellungen und Neustart vorgängig. Download landet dann im Archiv. Man weiß ja nie.

 

[roterteufel81]

Ich mache es auch am liebsten manuell. Habe auch keine meiner DS für komplettes Auto-Backup mit Auto Restart konfiguriert (das ginge schon allein deshalb nicht, weil bei mir alle Ordner verschlüsselt sind).

Das Backup Problem habe ich mittlerweile mittels Autostart Plugin im Griff. Permanent angeklemmte USB HDD bekommt via Smarter Steckdose Strom, Autostart läuft los und löst ein HyperBackup Job aus, der fährt durch, wirft die Platte aus und am Ende schaltet die Smarte Steckdose die USB HDD nach 20 Minuten leerlauf automatisch stromlos. Läuft jede nach automatisch und kann bei Bedarf auch manuell angestoßen werden.

 

[roterteufel81]

Am Donnerstag hatte ich dieselbe Meldung. Allerdings hab ich ~40.000 Einträge in der DB, die ich mit blocklist.de abgleiche. Daher fand ich ein Limit zwar nicht schön, aber auch nicht wirklich verwunderlich.

Aber wenn ich das jetzt hier lese, scheint es ja nicht wirklich an der Länge der Liste zu liegen.[/ICODE]

Ich hatte die Frage zur Klärung in mein Ticket bei Synology für Dich mit rein gepackt. Hier die Antwort:

"Zu Ihrer Frage. Ein Limit für die Datenbank gibt es nicht. Da Sie sich die Datenbank ja einmal angesehen haben ist Ihnen vielleicht auch aufgefallen, das diese in einer seperaten Systempartition liegt. Diese stellt das Limit dar. Wenn die Datenbank zu groß wird, ist das System nicht mehr erreichbar."

Das lässt mich selbst aber dann fragen, wozu es dann überhaupt diese ominöse E-Mail gibt. Wenn das System nicht mehr erreichbar ist, kann es auch keine E-Mails mehr versenden. Außer sie kommt kurz vorm Exitus.

 

[geimist]

Inzwischen hatte ich mal wieder eine automatische Blockierung, nach der es keine separate E-Mail bzgl. der Datenbankgröße gab. Ich denke, dass hier einfach diese (pauschale) Meldung ausgegeben wird, sofern das Schreiben des DB-Eintrags nicht positiv quittiert wird (oder Ähnliches).

Auch schön zu wissen, dass es keine Obergrenze für die DB gibt.

Vielen Dank für deinen Bericht.