DSM 6.x und darunter Sicherheitsberater: "Ein oder mehrere nicht normale Benutzer..." - root!

[MrGrateful]

DS415+
DSM 6.2.1-23824-4

Sicherheitsberater meldet kritisches Scan-Ergebnis: "Ein oder mehrere nicht normale Benutzer wurden in der Authentifizierungsdatei gefunden."

"Authentifizierungsdatei enthält nicht normale Benutzer. Überprüfen Sie, ob die folgenden Benutzer von Ihnen oder einer Drittanbieter-Anwendung erstellt wurden: root.
[...]"

€dit: das Problem wurde mir erstmalig am 10.01.2019 per Email gemeldet, ohne dass ich gesondert Änderungen an den Einstellungen des Sicherheitsberaters gemacht oder den root-Account irgendwie geändert hätte. Ich hatte lediglich am 03.01.2019 (also 7 Tage zuvor) von DSM 6.1.x auf DSM 6.2.x gepatcht.

Schritte
Wie unter "Empfohlene Aktion" vorgeschlagen habe ich ein Ticket beim Synology Support aufgemacht. Dort wurde mir mitgeteilt, ich solle zwecks Fernwartung Admin-Username und Passwort Plain-Text in das Online-Formular eintragen - so etwas mache ich selbstverständlich nicht. Stattdessen meine Antwort an den Synology Support, ich sei vom Fach (M.Sc. Angewandte Informatik mit 15 Jahren Berufserfahrung u.a. in der IT Security) und ich könne alle notwendigen Schritte zur Analyse und ggf. Behebung auch selbstständig ausführen; ich müsse nur wissen, was genau zu analysieren wäre.
Darauf die zweite Antwort vom Support:

"Um eine genauere Analyse durchführen zu können benötigen wir einen Fernzugriff auf das NAS. Sollten Sie dies nicht wünschen würde ich Sie bitten sich an ein Systemhaus zu wenden. Einen Link finden Sie hier: https://www.synology.com/de-de/wheretobuy/Germany/System_Integrator"

Optionen

An dieser Stelle bin ich etwas verärgert, da meine drei derzeitigen offiziellen Optionen leider lauten:

1. Sicherheits-Scan anpassen (Benutzer-Scan deaktivieren) --> Sicherheitsrisiko erhöht, da potenziell neue Accounts nicht erkannt werden
2. Für offiziellen Synology Support den Admin-Login an Dritte weitergeben --> dies zu tun verbietet mir meine Erfahrung und mein Verstand, unbekanntes Sicherheitsrisiko
3. Support einkaufen --> mit dem Synology NAS habe ich m.E. genug Geld bezahlt, um für eine derart triviale Herausforderung eine Lösung erwarten zu können

Inoffizielle (technische) Optionen

1. root-Account deaktivieren --> bin kein allzu eingefleischter Linux-Experte, um das final beurteilen zu können, halte es aber grundsätzlich für nicht ratsam: im schlimmsten Fall zerschieße ich mir hier mein NAS und alle darauf befindlichen Daten
2. root-Passwort entfernen und SSH Shell nur noch per Private Key einloggen, siehe https://gander.in/dsm-6-und-login-als-root/ --> möglicherweise sorgt das für Abhilfe beim Sicherheits-Scan, hab das noch nicht ausprobiert

Nächste Schritte?
Ich tendiere zur technischen Option 2, in der Hoffnung, dass die Warnung danach nicht mehr auftaucht.

Trotzdem ärgert mich die Meldung des Sicherheitsberaters prinzipiell - wie kann root hier überhaupt auftauchen? Ich halte den root-Account für den ursprünglichsten und selbstverständlichsten User-Account auf Linux-basierten OS.

Erfahrungen? Empfehlungen?

 

[Puppetmaster]

Die Fragen die sich mir zunächst einmal stellen:

1) Hast du selbst an irgendwelchen den Konfigurationsdateien per Konsole etwas herumgeschraubt?

2) Wie und von wem ist die DS denn überhaupt zugänglich? Ist sie offen im Internet und/oder gibt es weitere Admins lokal, die hier ggf. Änderungen haben vornehmen können?

Die Meldung aus dem Sicherheitsbereiter selber kenne ich jetzt nicht, und kann nicht wirklich sagen, welche Ereignisse dahinter verborgen liegen.
Ein root ist jedenfalls immer auf der DS vorhanden, das kann also so allein nicht der Grund für diese Meldung sein.

 

[peterhoffmann]

Die Meldungen vom "Sicherheits"berater sind leider immer sehr spärlich.
Einerseits wurden Benutzer in der Authentifizierungsdatei gefunden, andererseits können dadurch Angreifer diese Authentifizierungsdatei ändern. Und dann wird nicht mal der Ort der ominösen Authentifizierungsdatei genannt. Ja, das macht alles total viel Sinn.
Da kann man fast nur noch raten.

Ist folgende Datei vorhanden, wenn ja, ist was drin und welches Datum trägt die Datei:

/root/.ssh/authorized_keys

 

[MrGrateful]

Zwei sehr gute Fragen!

1) im Zeitraum der letzten Monate wurde nichts per SSH Konsole herumgeschraubt; erst nach Auftreten des Problems habe ich per sudo ein chmod auf eine Log-Datei gemacht, die ich ansonsten nicht hätte lesen können

2) DSM und Photo Station sind per HTTPS im Internet erreichbar; ich bin der einzige Admin

Die Meldung kommt seit dem 10.01. täglich, ohne dass ich am Vortag irgend etwas geändert hätte. Deshalb wundert es mich auch...

 

[peterhoffmann]

Die Meldung kommt seit dem 10.01. täglich, ohne dass ich am Vortag irgend etwas geändert hätte. Deshalb wundert es mich auch...

Hast du am Tag oder am Tag zuvor ein Update der DS gemacht?

 

[MrGrateful]

Hast du am Tag oder am Tag zuvor ein Update der DS gemacht?

Am 03.01. (also 7 Tage vor erstmaligem Auftreten des Problems am 10.01.) habe ich die DiskStation von DSM 6.1.x auf DSM 6.2.x gepatcht. Habe das gerade extra noch mal im Protokollcenter verifiziert: am 03.01. ist der letzte "Update was complete" Eintrag. Am 09. oder 10.01. gibt es auch keine weiteren Meldungen im Protokollcenter, die auf irgend ein Paket- oder DSM Update hinweisen.

 

[peterhoffmann]

Hier noch mal mein Vorposting:
Ist folgende Datei vorhanden, wenn ja, ist was drin und welches Datum trägt die Datei:

/root/.ssh/authorized_keys

 

[MrGrateful]

Datei /root/.ssh/authorized_keys existiert nicht, in dem .ssh Ordner gibt es nur die known_hosts Datei mit nur einem Eintrag für localhost.

€dit: beim Checken sehe ich gerade zufällig folgende Auffälligkeit: der Ordner /root/.ssh hat den Zeitstempel 3. Januar zu ziemlich genau der Uhrzeit, zu dem ich das DSM Update gemacht habe: Log Eintrag "Update was completed." 19:53 Uhr, Zeitstempel .ssh Ordner: 19:55 Uhr, also zwei Minuten nach DSM 6.2 Update.

 

[peterhoffmann]

Das ist ja schon mal gut.

Leider gehen mir dann langsam die Ideen aus.

 

[MrGrateful]

Habe folgenden Thread aus Jun/Jul 2018 entdeckt: https://www.synology-forum.de/showthread.html?95638-Sicherheitskritische-Warnung-root-in-Authentifizierungsdatei

Leider bislang ebenfalls ohne Lösung.

 

[peterhoffmann]

Dann schau dir die /etc/passwd mal genauer an.

Wechsel ins Verzeichnis /etc und mach mal das:

ls -l --full-time | grep passwd

Als Vergleich:
Meine /etc/passwd

-rw-r--r--  1 root     root      2844 2019-01-05 01:46:06.969112829 +0100 passwd

Der Inhalt für root in dieser Datei ist:

root:x:0:0::/root:/bin/ash

 

[MrGrateful]

Datum und Zeitstempel der Datei /etc/passwd:

> ls -l --full-time passwd
-rw-r--r-- 1 root root 2705 2019-01-04 08:40:28.616294292 +0100 passwd

passwd Inhalt für root:

> more passwd | grep root
root:x:0:0:root:/root:/bin/sh

 

[bselu]

Hallo,

ich habe dasselbe Problem.

Am 18.01.2019 habe ich ein Update auf DSM 6.2.1-23824 Update 4 durchgeführt. Am nächsten Tag ging es los und ich sehe nun dieselbe Fehlermeldung des Sicherheitsberaters, daß "root" in der Authentifizierungsdatei gefunden worden sei. Ich habe es erst jetzt bemerkt, da meine EMail-Notifizierung ins leere lief.

Hat jemand mittlerweile eine Lösung gefunden?

Ich vermute mal ganz stark einen Bug im letzten Update! Hallo, Synology?

Viele Grüße,
bselu

 

[call286]

Ich habe dieses Problem auch gehabt und konnte es für den Moment lösen. ABER: Ich habe bisher nicht alles getestet, der Versuch ist jetzt ein paar Minuten alt.
Irgendwann vor ein paar Monaten hatte ich auch mal ein Paket (Plex Media Server installiert als spk. Da waren ein paar Eingriffe in die Konfiguration nötig, das nutze ich nicht mehr. Es könnte also sein, dass User, die solche Pakete nutzen das so nicht nutzen können. Das kann ich aber mangels tieferem Verständnis der inneren Funktionsweise der Synology nicht beurteilen. Ich werde weiter testen und melden, falls Probleme auftreten.

 ls -l --full-time | grep passwd

-rw-r--r--  1 root     root      2545 2018-07-03 20:49:02.382056059 +0200 passwd
-rw-r--r--  1 root     root       963 2014-03-11 14:48:16.143816762 +0100 passwd.bak
-rw-------  1 root     root      2545 2018-07-03 20:49:02.382056059 +0200 passwd.cfgen.bkp

grep root passwd

root:x:0:0:root:/var/services/homes/root:/bin/ash

1.
* *.bak und *.bkp verschieben nach /root (da gab es z.B. passwd, shadow, ...)
* Eintrag /var/services/homes/root entfernen
--> Hat nicht geklappt

2.
* vim /etc/synouser.conf, root auskommentiert (# vor die Zeile mit root => #root:0: )
* Neustart der DS
--> Jetzt scheint es zu funktionieren nachdem ich im Sicherheitsberater nochmal auf Scannen geklickt habe.

Ich hatte jedoch bei 1. noch nicht neu gestartet, d.h. es könnte auch schon bei 1. geklappt haben.
Jedoch klingt die dünne Meldung "Authentifizierungsdatei enthält..." auch nach der synouser.conf. Ist aber wohl eine Interpretationsfrage.

 

[bselu]

Hallo call286,

danke für die Info.

Ich habe auf meiner Synology auch /etc/passwd.cfgen.bkp und /etc/shadow.cfgen.bkp gefunden und nach /root verschoben. Leider ohne Effekt. Auch nach einem Neustart meckert das Sicherheitscenter.

In /etc/synouser.conf habe ich keinen Eintrag für root.

Scheint also nochmal ein anderes Problem zu sein als bei dir?!

 

[call286]

Kann sein, dass noch mehr gecheckt wird. Hast du im Sicherheitsberater nochmal auf "Scannen" geklickt?

Und kannst du auch mal den Befehl im Verzeichnis /etc ausführen wie MrGrateful und die Ausgabe posten:

Beispiel bei mir:

/etc> more passwd | grep root
root:x:0:0::/root:/bin/ash

 

[bselu]

AHA! Hab's rausgefunden.

Es lag an dem Inhalt in der /etc/passwd. In meiner war vorher:

root@NAS:/etc$ cat /etc/passwd|grep root
root:x:0:0::/root:/bin/sh

Nachdem ich das geändert habe zu dem hier, ist der Sicherheitsberater nun zufrieden:

root@NAS:/etc$ cat /etc/passwd|grep root
root:x:0:0::/root:/bin/[B]a[/B]sh

Es liegt tatsächlich an diesem kleinen "a", ich habe es mehrfach verifiziert. Das kann nur bedeuten, daß dieser "ausgeklügelte" Sicherheitsberater die passwd nach genau diesem String durchsucht und wehe auch nur ein Zeichen weicht ab. Ähm, Synology, WTF?!?!?!?!

Danke, call286! Du hast den entscheidenden Hinweis geliefert.

 

[call286]

So etwas in der Art habe ich mir schon gedacht, denn weiter oben ist mir schon einmal aufgefallen, dass dort in der Ausgabe von peterhoffmann ash stand und bei MrGrateful sh als Loginshell.

Gut, dass es bei dir auch geklappt hat, dann haben wir das auch ohne externen Zugriff gelöst

Edit: Ich hoffe mal, wenn @MrGrateful die ash als shell einträgt, wird das auch sein Problem lösen.

 

[wluttner]

Sieht so aus, als dass der Sicherheitsberater einen diff zwischen
/etc/passwd und
/etc.defaults/passwd
macht.

Da ich gerne die bash habe, habe ich /etc.defaults/passwd angepasst.
Mal sehen, ob es das nächste Update überlebt...

 

[MrGrateful]

Ich hoffe mal, wenn @MrGrateful die ash als shell einträgt, wird das auch sein Problem lösen.

Hallo zusammen, Danke für die Hinweise, die Lösung hat auch bei mir funktioniert (sorry, dass ich keine zeitige Rückmeldung gegeben habe). Da wäre ich von alleine nie im Leben drauf gekommen!

Also noch mal zusammenfassend die Lösung: eine Änderung des Eintrages in /etc/passwd von:

root:x:0:0:root:/root:/bin/sh

nach

root:x:0:0:root:/root:/bin/ash

hat den erwünschten Effekt gehabt: der Sicherheits-Scan identifiziert root nicht mehr fälschlicherweise als nicht normalen Benutzer.

Es liegt tatsächlich an diesem kleinen "a", ich habe es mehrfach verifiziert. Das kann nur bedeuten, daß dieser "ausgeklügelte" Sicherheitsberater die passwd nach genau diesem String durchsucht und wehe auch nur ein Zeichen weicht ab. Ähm, Synology, WTF?!?!?!?!

Technischer Hintergrund wird wohl sein, dass der Sicherheitsberater für den User root die Bourne-again-Shell (a.k.a. bash, startet als "/bin/sh") als Standard-Shell für nicht zulässig betrachtet, die Almquist Shell ("/bin/ash") hingegen schon. Es ist zwar nur ein Buchstabe, aber der hat zur Folge, dass eine andere Shell für Root nach dem Login bereitgestellt wird. Frag mich jetzt aber bitte niemand, was die bash mutmaßlich unsicher macht, und was bei der ash sicherer sein soll