[Eisfair_dev] Samba 2.29.0 badlock (Status 'testing')

[Thomas Bork]

Am 15.04.2016 um 16:21 schrieb Thomas Zweifel:

> Wenn das so ist, dann wohl doch eher den Support für alte OS
> standardmässig aktiviert lassen, und quasi per "Kill-Switch"
> irreversibel auf sicher umschaltbar.
> Gegebenenfalls einen rot gefärbten Hinweistext beim Abspeichern, falls
> man noch den Kompatibilitätsmodus betreibt.

Ich schrieb:

#########################################################################
Dazu ist anzumerken, dass ich aufgrund schon vorher veränderter Defaults 
in Samba explizit

# compatibility with older servers
lanman auth = yes
client lanman auth = yes
client plaintext auth = yes
client ntlmv2 auth = no
require strong key = no
allow nt4 crypto = yes
#########################################################################

Und:

#########################################################################
Im Bild fehlen noch ältere Samba-Versionen als Client oder Server. Hier 
hat anscheinend zur Zeit Debian mit seinem Samba 3.6 nach den Patches 
für badlock zu kämpfen.

Auch solche Clients und Server müssen nach einer Änderung in Tests mit 
einbezogen werden. Das kann ich allein nicht leisten. Jeder mit älteren 
Clients oder Servern in Verbindung mit eisfair-Samba ist also hiermit 
zur Mithilfe aufgerufen.
#########################################################################

Bevor ich so etwas wie einen wie auch immer gearteten Schalter in 
Erwägung ziehe, sollte jeder mit älteren Clients/Servern in Verbindung 
mit eisfair-Samba manuell einmal die oben erwähnten Optionen in 
/etc/smb.conf auskommentieren, Samba neu starten und testen, was danach 
noch läuft und was nicht. Dazu gehört auch eine Änderung des 
Samba-Passwortes.

Ergebnisse hierher detailliert aufgelistet nach:

- zugreifender Client mit Patchlevel / Servicepack
- Server, auf den zugegriffen wird
- eisfair-Samba PDC ja/nein
- Zugriff möglich ja/nein
- Lanman Password Hash bei existierenden Usern vorhanden
- Lanman Password Hash bei existierenden Usern nach Passwort-Änderung
   noch vorhanden
- Lanman Password Hash bei existierenden Maschinen-Accounts vorhanden

Die Passwort-Hashes kann man sich für alle User und Maschinen mit

pdbedit -Lw

anzeigen lassen. Die einzelnen Felder sind hier mit dem Doppelpunkt 
abgetrennt. Der Lanman Password Hash befindet sich in Feld 3, der NT 
Password Hash in Feld 4.

Beispiel (verfälscht, da man so etwas nicht offenlegt):

testeis # pdbedit -Lw
[...]
sambatestuser:2002:C187B8085FE1D9DFAAD3B435B51404EE:A9F0DD57E1EDAB5BB55A9AC0A99C15EC:[U 
          ]:LCT-571267C2:

In dem Beispiel ist der Lanman Password Hash für den User sambatestuser 
mit der UID 2002 also C187B8085FE1D9DFAAD3B435B51404EE.

Nach Auskommentieren der o.g. Optionen und Änderung des Samba-Passwortes 
ist der alte Lanman Password Hash verloren:

testeis # pdbedit -Lw
[...]
sambatestuser:2002:XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX:0366F5C43990657D4AF37BC470E0EF97:[U 
          ]:LCT-5712690F:

Maschinen-Konten in einer Domäne ändern periodisch ihr Passwort, damit 
ist wohl klar, was passiert...


Was mir an Deinem Kill-Switch nicht gefällt:

Wenn jemand nach "sicherem" Betrieb nun doch plötzlich einen alten 
Client zugreifen lassen muss, weil der einfach kein Update mehr bekommt 
(meinetwegen ein NAS):

Demjenigen ist schlecht zu vermitteln, dass das nicht geht - er 
möchte/muss mit der Unsicherheit leben.

Und woran mache ich eigentlich fest, dass das Paket sich schon mal im 
sicheren Modus befand?

Das wird in jedem Fall eine undankbare Aufgabe:

Ich müsste das so umfangreich dokumentieren, dass es jeder versteht (die 
Dokumentation liest aber sowieso keiner). Ich bin in jedem Fall der 
Arsch, der entweder vorhandene Konfigurationen kaputt macht oder nicht 
genug absichert.

Im Moment hält sich meine Lust auf so etwas mächtig in Grenzen.

-- 
der tom
[eisfair-team]