NTLM raubt mir den Nerv bzw. deren Ausnahmen

[Weingeist 157]

Salut zusammen,

Mal wieder ein Sicherheitsthema das seit längerem für mal mehr mal weniger Ärger sorgt. Vermutlich nicht nur bei mir. =)

Folgende Ausgangslage:

• Aktueller Drucker, aktueller Firmwarestand
• Filer mit Freigabe, (auch via DFS), alle üblichen SMB-Hardening-Features aktiv (signing, servernamhardening, nocompression, encryption usw.)
• Drucker kann mit Zertifikaten umgehen
• unterstützt 802.1x
• unterstützt SSL/TLS für Web-Kommunikation inkl. Deaktivierung alter Protokolle
• unterstützt Verschlüsselung/Signierung für die Verbindungen für SMB (alle Härtungseinstellungen am Filer sind unterstützt)

Im Grunde alles was man heute so erwartet, ausser eben Kerberos-Authentifizierung. Gibt auch Hersteller die Kerberos können aber halt nicht alle.

Nun soll dieses Teil weiterhein auf eine SMB Freigabe Dokumente ablegen können wo die User dann die Files abholen können.

 

Szenario 1: Zugriff vom Drucker auf die Freigabe via \\DomäneFQDN\DFS-Root\FreigabeName

Fehlermeldung 4002 nur auf dem DC dann in etwa so:

Calling Process ID: 4

Calling Process LUID: 0x37

Calling Process User Identity: Computer Account Name des DC

Calling Process Domain identity: DomainFQDN

Mechanism-OID: 1.3.6.1.4.1.311.2.2.10

NTLM Authentication request to this server ist blocked

Wie man unschwer erkennen kann, erhält man keinerlei Angaben von wem die ursprüngliche Anfrage kam. Nichtmal das "Relay" also den Filer, erkennt man. Mit Firewall-Logging (BFE) kann man schauen was zur gleichen Zeit reinkam, aber ist natürlich wenig praktikabel wenn eine gewisse Menge Traffice läuft. Eine Ausnahme für das Gerät ist so - wenig verwunderlich - auch nicht möglich.

 

Szenario 2: Zugriff vom Drucker auf die Freigabe direkt auf dem Server, ohne DFS (Tschüss DFS-Komfort)

Übliche Fehlermeldung auf dem DC die gut auswertbar ist. Ausnahme für den Filer kann erteilt werden.

Auf dem Filer habe ich das gleiche Problem wie vorher auf dem DC. Der Verursacher erscheint nicht im Log wenn die Verbindung signiert/verschlüsselt ist. Folglich keine granulierte Ausnahme sondern nur die Schleuse möglich.

Es müsste der komplette NTLM Verkehr auf den Filer zugelassen werden. Nicht so sinnvoll für einen allgemein zugänglichen Server. Den Filer selbst kann man dafür auf dem DC als Ausnahme definieren.

 

Szenario 3: E-Mail-Versand. So prickelnd finde ich das nicht, mit grossen Scan-Files den E-Mail Server zuzumüllen. Dafür extra einen internen Mailserver aufziehen und pflegen ist definitiv zu viel Aufwand für so eine eigentlich triviale Anforderung.

 

 

Bis jetzt habe ich zwei Workarounds die ich im produktiven Test/Einsatz habe:

Der erste ist ein separater Filer der nur mit dem Drucker und den Infrastrukturservern (DC, CA, WSUS) sowie diesen Druckern kommunzieren darf. Dann synchronisiere ich dem Hauptordner mit dem Filer auf den die User Zugriff haben. DFSR und Robocopy  habe ich seit längerem im produktiven Test. Funktioniert soweit beides aber halt mit den üblichen Nachteilen. Und schön ist es nicht wirklich.

Eine Festplatte die ich in mehrere VM's einfüge (physical shared) und die VM's nur in ihren jeweiligen Netzen kommunzieren können. Die Kommunikationseinschränkungen können sowohl physische (Netzwerkkarten) als auch logisch mit Firewalls durgesetzt werden. Also nur die Drucker dürfen mit Server A kommunzieren. Der Server selbst in Richtung Infrastruktur-Server und Drucker. Server B ganz normal. *1)

Soweit OK (nicht gut), aber die zusätzliche Maschine muss bei beiden Würg-around-Varianten, gepflegt, gesichert und insbesondere bei der zweiten Variante 1A dokumentiert werden. Dafür kann man sich auch gleich überlegen ob die Authentifzierung überhaupt gegen AD erfolgen soll oder ob es nicht auch ein lokales Dienstkonto tun würde. DFS fällt logischerweise flach. Eine NTLM-Anfrage in die eigentliche Domäne muss nicht getätigt werden und somit auch keine Ausnahme erfolgen.

 

 

Die Frage

Entweder stehe ich auf dem Schlauch oder das geht tatsächlich nicht besser? Löst man das besser ganz anders? Davon abgesehen, habe nur ich das Gefühl, dass die NTLM-Logs sowie Ausnahme-Regeln etwas halbgar umgesetzt wurde wenn die Ausgangslage nicht "Keinerlei Sicherheit" ist?

 

Bis die Hersteller durchgängig ihre Software und Gerät angepasst haben, dürfte es wohl noch eine ganze Weile dauern, eine Lösung wäre daher schön. Interessant finde ich, dass auch nach fast einem Jahr wo das nun im Netz breitgetreten wird, mein Druckerlieferant meint, ich wäre der einzige der das überhaupt anfragt. Er beliefert auch diverse Gross-Firmen und SMB sei fast immer eingerichtet für den Scanner. 

Wird in grösseren Betrieben einfach noch grosszügiger mit Ausnahmen hantiert? Ist die NTLM-Problematik in den IT-Abteilungen wirklich noch nicht angekommten oder ist das ganze doch nicht so problematisch wie einem das die ganzen Internetartikel vermitteln wenn alles über signierte Clients läuft?

Grüsse und vielen Dank für Inputs!

 

 

Zusatzinfo zu 1) Das funktioniert mit NTFS, solange auf einer Seite nur gelesen wird. Knackpunkt ist die Indexierung, die muss am besten auf beiden Seiten deaktiviert werden. Man kann mit aktivieren/deaktivieren der Disc arbeiten (bei manuellen oder zeit/triggergesteuerten Aufgaben) oder mit Lockfiles welches die andere Seite vor einem Schreibvorgang prüft. Funktioniert 1A, ist aber halt aufwendig in der Einrichtung und nicht jeder versteht so ein Konstrukt. Dafür kann man auch eine quasi-physische Netztrennung - zumindest auf Netzwerkebene -  erreichen und hat dennoch den Komfort eines Datenaustausches. Klar ist ein Würg-Around. Weder schön noch besonders Wartungsfreundlich. Aber immerhin kann man gewissen Anforderungen einigermassen Rechnung tragen ohne gleich alles freizugeben.

[daabm 1.185]

vor 7 Stunden schrieb Weingeist:

Gibt auch Hersteller die Kerberos können aber halt nicht alle.

 

Hersteller wechseln. Klingt b***d, ist aber so. Oder ein SMB-Relay davorsetzen (Raspi z.B. ).

[Weingeist 157]

vor 15 Stunden schrieb daabm:

Hersteller wechseln. Klingt b***d, ist aber so. Oder ein SMB-Relay davorsetzen (Raspi z.B. ).

Schon, aber sind ja sehr teure Geräte die grossen Multifunktionsdrucker. Die schmeisst man nicht einfach so raus. Einigermassen mühsam ist es auch, wenn man wieder die Eigenheiten eines neuen Herstellers aneignen muss. Insbesondere punkto Automatisation. Meine Umgebungen sind immer recht ähnlich aufgebaut damit es möglichst wenig Leerläufe gibt und dennoch das meiste an Sicherheitsempfehlungen auch im kleinen umsetzen kann ohne das die Stunden masslos überborden.

 

SMB-Relay mit nem RASPI. Gibts so ein Relay +- transparent? Also ohne Speicher auf dem Raspi? Habe eine 'fertige' Lösung vor einiger Zeit gesucht, aber leider nicht gefunden. Selber auf die Beine stellen ist mir zu mühsam/Pflegeintensiv. Theoretisch wäre das mit Linux ja gut möglich, aber mir fehlt mir schlicht das KnowHow. Da gefällt mir dann eine Windows-Lösungen besser. Ist ja dann ähnlich wie meine Work-Arounds.

[zahni 521]

Hi,

 

wir verwenden Lexmark. Ob dort direkt im Drucker direkt Kerberos unterstützt wird, kann ich nicht sagen. Jedoch müsste der Drucker hier in der Domäne gejoint sein oder zumindest mit über eine Kerberos-Konfig mit einem privaten Schlüssel verfügen. Lexmark bietet jedoch zahlreiche Managment-Lösungen an, bei denen die Scan-Funktion zar am Drucker erfolgt, die Ablage der die Scans dann aber von der Mangement-Lösung.

Lexmark bietet hier z.B. LPM an https://www.lexmark.com/de_de/products/smart-mfp-ecosystem/manageability.html , für das es zahlreiche Erweiterungen gibt.

Ansonsten schau mal hier:

 

https://infoserve.lexmark.com/ids/ifc/ids_topic.aspx?root=kb20211201183846179&topic=FA1041&productCode=Lexmark_X925&loc=en_NZ

[Weingeist 157]

@zahni Lexmark unterstützt direkt Kerberos. So nach der verlinkten Beschreibung sollten recht viele Drucker Kerberos direkt können. Scheinbare hinkt von den Herstellern grösserer Drucker nur Canon hinterher. *hmpf*

Management-Lösung wäre meistens wohl etwas oversized für eine Handvoll Mitarbeiter die wirklich scannen dürfen/sollen. Würde aber ebenso einen Herstellerwechsel erfordern. :(

 

Danke an alle für die Inputs!

[daabm 1.185]

Am 12.10.2022 um 09:32 schrieb Weingeist:

SMB-Relay mit nem RASPI. Gibts so ein Relay +- transparent? Also ohne Speicher auf dem Raspi? Habe eine 'fertige' Lösung vor einiger Zeit gesucht, aber leider nicht gefunden. Selber auf die Beine stellen ist mir zu mühsam/Pflegeintensiv. Theoretisch wäre das mit Linux ja gut möglich, aber mir fehlt mir schlicht das KnowHow. Da gefällt mir dann eine Windows-Lösungen besser. Ist ja dann ähnlich w

 

Da bin ich leider raus - ich kenne SMB-Relays nur vom Hörensagen Brauchen tun wir sowas gottseidank nicht. Wobei Dir das vermutlich nicht mal hilft, weil ja die Authentifizierung immer noch ein Problem ist - die SMB-Relays, die ich bisher wahrgenommen habe, waren wegen unterschiedlicher Versionen.

[Weingeist 157]

vor 22 Stunden schrieb daabm:

Da bin ich leider raus - ich kenne SMB-Relays nur vom Hörensagen Brauchen tun wir sowas gottseidank nicht. Wobei Dir das vermutlich nicht mal hilft, weil ja die Authentifizierung immer noch ein Problem ist - die SMB-Relays, die ich bisher wahrgenommen habe, waren wegen unterschiedlicher Versionen.

Nope dient hier eigentlich nicht so viel, weil ja eben nicht die Verschlüsselung/Signierung das Problem ist, sondern wie Du sagst die Authenifizierung. Könnte man aber sicher so lösen, dass er sich nur gegen den Raspi authentifiziert. Aber eben, muss ich sowas machen, nehme ich dann doch lieber eine Windows VM wie meine bisherigen Work-Arounds. Dirty aber funktional.

 

Wenn jemand noch Verbesserungsvorschläge für die Logs hat, gerne her damit. Zumindest diese Prob sollte ja theoretisch verbreiteter sein =)

bearbeitet 14. Oktober 2022 von Weingeist

[Weingeist 157]

Kurze Rückmeldung, die Authentifizierung gegen ein lokales Konto auf dem Zwischen-Server funktioniert übrigens genauso gut. Insofern im eigentlichen Netz keine NTLM-Ausnahme notwendig. Hätte ich auch früher drauf kommen können. Hätte mir einiges an Arbeit erspart.

 

Jemand eine Ahnung wie man dem UserManager Dienst die NTLM-Abfragen austreibt? Füllt unnötigerweise die Logs

[Weingeist 157]

Mal ein Update wo ich noch Hilfe bräuchte:

Aktuell kämpfe ich immer noch damit, dass der User-Manager Service via seiner svchost.exe in gesperrtem Zustand des Computers (User angemeldet, aber nicht am Platz), irgendwas mit NTLM authentifizieren möchte. In der Regel dauert es ein paar Stunden nach dem sperren. Anschliessend gibts folgende Sympthome:

• Anwendung der User Polices schlagen fehl (Computer scheinen zu ziehen, bin aber nicht 100% sicher, da schwierig zu prüfen)
• SMB-Verbindungen werden getrennt
• Es kommt beim Anmelden eine Info, dass die aktuellen Anmeldeinfos nicht aktuell sind und man sich an- und abmelden soll. Diese verschwindet aber rasch wieder.

Meldet man sich wieder an, werden alle Verbindungen wieder mit Kerberos aufgebaut (Tokens werden wieder ausgestellt, nachprüfbar im Log). Das wäre nicht ultra-dramatisch, wenn ich nicht ein paar Anwendungen hätte, denen die Trennung gar nicht schmeckt. Braucht jedes mal ein Restart der Anwendung. Die alten Reg-Flags die das trennen verhindern, scheinen nicht mehr zu ziehen.

 

 

 

Im Printerbereich/Scanner hoffe ich, dass Canon endlich nachzieht. Dann könnte ich ein paar Workarounds aufheben. Meine Anfragen werden immer mit dem Verweis auf die Sicherheitsangaben im Manual für SMB verwiesen. Jemand "Grösseres" mit mehr Einfluss hier oder anderen Infos? Laut meinem Distri bin ich immer noch der einzige der das überhaupt nachfragt und sie erhalten keine bessere Antwort von Canon als ich selbst. Kann ja eigentlich nicht sein. Kommt dann vielleicht wenn das enforcment erzwungend wird...

 

 

 

 

Dann ein kleines Update zum Workaround den ich nun seit mehreren Monaten im produktiven Einsatz habe:

 

DFSR-Variante zwecks Sync und reine Bordmittel.

• eigenes LAN für Maschinen mit NTLM und Lanport auf Relay wo möglich und die Kommunikation des Relay mittels Firewall auf die NTLM-Clients eingeschränkt. Alles an sonstigen Massnahmen aktiviert, was geht (Erst alles aktiviert, dann einzeln deaktiviert um herauszufinden was notwendig für die Funktion war)
• NTLM in der ganzen Domäne Deaktiviert und enforcement auf den DC's auf 2, für die OU mit dem Relay-Server NTLM Beschränkung aufgehoben. *1)
• Freigegebener Ordner auf dem Relay-Server in welchen die Maschinen (z.Bsp. Scanner) mit einem Service Account und NTLM-Auth schreiben dürfen
• DFSR welches diesen Ordner mit einem Ordner auf einem Filer synchronisiert der wiederum zugänglich ist

Das Service-Konto für den SMB-Verkehr darf sich jeweils weder per RDP (eh gesperrt) noch lokal anmelden. Besitzt Lese/Schreibrechte für den Ordner. Für lokales Anmelden gibt es einen speziellen Admin Account  für diese Maschine in der Domäne. Ansonsten hat er keine Rechte. Da mein Wissen eher breit als besonders tief ist in den einzelnen Gebieten, würde mich die Meinung von ein paar Profis interessieren, inwiefern solche Massnahmen ausreichenden Schutz bieten oder ob das nur Aufwand für wenig Schutz ist.

 

1*) Da nur der Relay-Server NTLM akzeptiert, schlagen alle Authentifizierungsversuche gegen Domain-Accounts fehl wenn sie mit NTLM getätigt werden.

Man kann leider nach wie vor keine Remotemaschinen-Ausnahme definieren wenn SMB-Signing aktiviert wird. Daran haben auch die aktuellsten April-Updats nichts geändert (Server-Account und nicht der Initiator - also z.Bsp. der Scanner - wird gelogt). Das macht die Auwertung mühsam. Wer weiss Abhilfe?

Leider hat dieser Workaround wohl ein Ablaufdatum, weil MS die Möglichkeit von Ausnahmen voraussichtlich im Oktober/November entfernen wird. Ich schätze der Termin wird verlängert, aber selbst wenn er nur mit Remote-Ausnahmen möglich bleiben würde, bringt das eigentlich nichts, weil er die Remote-Maschine nicht als solche behandelt.

 

 

Der zweite Workaround mit der komplexeren Shared-Disc-Aktivierung-Deaktiverungs-Geschichte via zwei VM's ist je nach Art der Kommunikation (Einweg oder Zweiweg) einigermassen umständlich, wende ich aber nach wie vor an wo ich ein LAN-technisch strikte Trennung haben möchte.

• Aufgabenplanung mit Scripts für das Aktivieren/Deaktivieren der Disc um die MFT neu zu laden um zu erkennen ob die andere VM etwas geschrieben hat (sonst sind die Files nicht sichtbar) --> Gibts dafür auch nen einfcheren Weg wie nen WMI Befehl?
• Indexdienste auf die HDD deaktivieren um MFT-Beschädigung zu vermeiden
• Lockfile dessen anwesenheit man abfragt und verhindert das der Partner schreibt wenn er es gerade tut (wenn Zweiweg notwendig ist, ist aber trivialer wenn man mit zwei Festplatten arbeitet.  Für jede "Schreibrichtung" eine.

Alles halt recht hässliche Work-Arounds, weil die Industrieumgebungen leider nicht so schön aktuell zu halten sind wie die Büros, aber heute alles vernetzt sein muss.

[Weingeist 157]

Mittlerweile habe ich auch rausgefunden, dass die versuchten NTLM-authentifizierungen und deren Logs definitiv daher kommen, dass das Kerberos-Ticket abgelaufen ist. Es wird dann permanet versucht die bestehenden Verbindungen von Netzlaufwerken, GroupPolicy-Abfragen, Printerverbindungen etc. via NTLM zu authentifizieren. Was natürlich fehlschlägt. Führt aber zu sehr vielen Einträgen. Das Kerberos Ticket wird auch nicht selbst wieder erstellt wie ursprünglich angenommen, man muss effektiv den Arbeitsplatz sperren/entsperren. Trifft insbesondere für User der Gruppe "Protected Users" zu wo der Spass nach 3h oder so abläuft.

 

Wir noch ein paar Kopfschmerzen bereiten bis alles kompatibel ist. Und noch mehr, wenn NTLM für Lokale Accounts auch unwiederbringlich abgeschaltet wird...

[cj_berlin 1.137]

vor 3 Stunden schrieb Weingeist:

Trifft insbesondere für User der Gruppe "Protected Users" zu wo der Spass nach 3h oder so abläuft.

Ja, 4h, und dort ist es auch explizit im FM beschrieben. Deshalb dürfen auch keine Computer- und Service-Accounts in die Protected Users.

[Weingeist 157]

Yep... Habe mittlerweile auch gelesen. Habe ich vermutlich wieder vergessen. Shame on me. Schiebe schon sehr lange alle "normalen" User da rein.

Oder die User setzen wirklich immer brav das sperren/entsperren um in Kaffeepausen und abmelden am Abend und die jahrelangen Mühen tragen Früchte... auch wenn schwer vorstellbar ist in allen Umbgebungen.

Wobei ich auch nicht so besonders die NTLM-Logs von den Clients prüfe wenn niemand reklamiert das etwas nicht geht... hmmm....

 

 

Dafür habe ich noch ein Problem gefunden. Meine CA's mögen kein Kerberos für das ausstellen von Zertifikaten obwohl durchgängig aktiviert. Fällt mir wohl auch bald irgendwo auf die Füsse. Hach wäre das doch schon überall komplett durch. Wobei eigentlich hätte man ja fast 20 Jahre Zeit gehabt, muss man jetzt nicht rumjammern (Wobei stimmt nicht ganz, manche Services von MS waren ja auch nicht Kerberos tauglich) ;)

[daabm 1.185]

"Manche Services"? Da fällt mir spontan alles ein, was irgendwie mit Cluster zu tun hat - HyperV, SQL usw. Und "waren" stimmt da auch nicht ganz, wobei ich nicht weiß, wie der Stand mit Server 2022 aussieht.

[Weingeist 157]

vor 2 Stunden schrieb daabm:

"Manche Services"? Da fällt mir spontan alles ein, was irgendwie mit Cluster zu tun hat - HyperV, SQL usw. Und "waren" stimmt da auch nicht ganz, wobei ich nicht weiß, wie der Stand mit Server 2022 aussieht.

Die meinte ich mit "Manche Services" hab nur die optische akzentuierung vergessen Cluster sind ja ne Kleinigkeit *hust*

 

Mit 2022 hat das geändert. Nicht mehr NTLM abhängig. Glaube man bekommt heute alles mit Kerberos zum laufen (Bis auf das was man nicht zum laufen bekommt und wir vielleicht noch nicht wissen). Sonst könnte MS ja schlecht per Ende Jahr alles abschalten. Ich persönlich glaube zwar noch nicht daran, sondern tippe auf erst mal Messer ansetzen aber noch nicht ganz zustechen.

Mein Wett-Tipp: NTLM für lokale Accounts wird die letzte Ausnahme sein, die vermutlich nicht mal fallen wird weil man damit die Würg-Arounds hinbekommt, den manchernorts vermutlich noch 10 Jahre oder mehr notwendig sein werden. Auch wens unschön ist, ich würde es begrüssen und Risiko ist tendenziell abschätzbar. 

bearbeitet 10. Mai 2023 von Weingeist

[cj_berlin 1.137]

vor 2 Stunden schrieb Weingeist:

Mein Wett-Tipp: NTLM für lokale Accounts wird die letzte Ausnahme sein, 

Durch welches Protokoll würdest Du dieses für lokale Accounts ersetzen wollen, wenn Du dir was wünschen könntest?