Weingeist

@MurdocX Sorry für die späte Antwort. Habe ich auch nicht so aufgefasst. Mir ist das ja auch ziemlich unlogisch und die Theorie und normale Praxis dazu ist mir ebenfalls bekannt, so ist es nicht. Aber erstellen musste ich auf dem Client nunmal Inbound und Outbound, sonst lief es nicht (mehr) und seither erstelle ich beide. Unsere Voraussetzungen sind in Deinem Test auf alle Fälle nicht identisch. Du greifst via IP zu und benutzt deshalb NTLM und kein Kerberos. Sprich NTLM ist gestattet wenn Du Zugriff bekommst. Ich erzwinge Kerberos. Wie sieht den Deine sonstige SMB-Konfiguration aus? Also Server und Client? Jeweils beides. Also SmbServer und SmbClient. RequireSecuritySignature, EnableStrictNameChecking, RejectUnencryptedAccess, SmbServerNameHardeningLevel auf 1, minium SMB-Level, ValidateTargetName und was ich allenfalls noch so vergessen habe das man setzen sollte und nicht Standard ist (Genaue Differenz zu Standard-Einstellungen müsste ich erst gegenprüfen). Ohne jetzt 100% sicher zu sein, aber meiner Meinung nach fing das Theater an, als ich alle diese Features gesetzt habe. Wobei ich einen Teil schon vorher hatte. Ob nun vor oder nach durchsetzen von Kerberos kann ich ebenfalls nicht mehr mit Sicherheit sagen. Schlicht zu lange her. Im Moment ist aber grad essig mit viel rumtesten. Am Feierabend bekomme ich bei diesem Wetter haue und am Tag grad keine Zeit

Wartung: Da verlangen die grossen Hersteller etwas für Garantie, Updates etc. Je 'grösser' und leistungsfähiger (Bandbreite) die FW, desto teurer wird das bei den 'besseren' Hersteller. Doppelte Netzteile gibts eigentlich bei allen erst bei den grösseren. Es geht nicht per se um das sparen, es geht darum nicht unnötig Geld zu verpulvern für eine Leistung, die man nicht braucht. Ein zweites Netzteil ist z.B. nunmal keine 1000 Euro pro Jahr wert wenn man den rest nicht benötigt. Und jede zusätzliche Hardware die ich nicht einsetze, geht nicht kaputt. Der Vorteil bei Windows-Bordmitteln sehe ich immer in den zeitnahen Updates und der bereits integrierten Rechte-Verwaltung. Sprich Kopplung an AD möglich ohne irgendwelche Verrenkungen. Und eben keine zusätzliche Hardware. Ist Dir grad etwas gutes bekannt? Sollte +- einfach in der Konfig, Updates etc. sein und über vernünftige Logs verfügen. Primär geht es aber nicht darum nichts zu bezahlen, sondern tendenziell wenig laufende Kosten zu verursachen.

@Admin666 Verweis auf Kosten gesehen? Von den grösseren Hersteller ist das richtig teuer. Ebenso die Wartung pro Jahr. Für Leistung die ich ausser den Netzteilen nie brauchen werde. Heute wo alles virtualisiert ist, sehe ich das unkritisch. Insbesondere für eine interne FW. Die Funktion ist eh die selbe. Unterschied ist bei den grossen Hersteller nur ob ein propritäres System oder eben Vmware/HyperV die Virtualisierung übernimmt. Wie dem auch sei, da niemand diesbzüglich mit Windows bzw. dessen Firewahl in Verbindung mit einer Bridge entsprechende Erfahrung zu haben scheint, werde ich die Tests selber machen. Sehe punkto Bridge zwar wenig Chancen aber schauen wir mal. Sonst gibt es eben eine Appliance.

Dann würde ich mal von einer zweiten VM versuchen, die erste aufzulösen. So kannst Du ausschliessen, dass die erste VM sich selber kennt wenn Du eine fixe eingibtst. Das er dafür konfiguriert wurde, glaub ich Dir ja, aber hast Du es auch mit der Firewall geprüft? Sprich kommen die Pakete an auf den Ports? Resolve-DnsName gib hier mal explizit Deinen DNS-Server an und zwinge das cmdlet nur DNS zu verwenden und keine andere Art der Namensauflösung. Also Flags -Server und -dnsonly verwenden. Ich kann mir nicht vorstellen, dass die Auflösung mit einer Statischen IP von einem anderen Client her dann geht und mit einer DHCP-Adresse nicht. Wenn doch, müssen andere rann, mit den Eigenheiten von IPv6 kenne ich mich zu wenig aus. Ich deaktiviere das solange IPv4 funktioniert.

@daabm Aufhängen.... Hmm, das wäre in der Tat unschön. Bis jetzt wusste ich nur, dass er etwas "grässlich" in der Konfig sein soll und nicht unbedingt das performanteste (wobei das bei einer >3GHZ CPU heute auch egal sein dürfte). Mein Link war halt folgender, MS macht mittlerweile viel auf Netzwerkebene mit HyperV, also sollte sie das mittlerweile auch zuverlässig können. Und auch der ISA/TMG konnte das problemlos zuverlässig vor über 10 Jahren. Also warum sollte das heute, über 15 Jahre nach dem ersten vernünftigen ISA, nicht auch mit Bordmittel gehen @Admin666 Ja klar ist es das klassische Produktions-Problem. Und gerade aus genannten Gründen, mag ich da keine LAN-Verbindungen. Daher sehe ich auch eher das Büro als Bedrohung für die Produktion als anderes rum, auch wenn in der Produktion die unsicheren Rechner sitzen. Ist ein Bürorechner befallen, hat er leichtes Spiel mit einem Rechner in der Produktion. Anders rum eher nicht und die Wahrscheinlichkeit ist deutlich tiefer ohne Internetzugriff. An die Nutzung der Firewall welche jeweils den Internet-Teil erledigt, habe ich durchaus auch schon gedacht. Aber ich möchte ja eben nicht ein Gerät ohne doppelte Netzteile etc. als wichtiges Bindeglied haben. Gibt nur wieder Potential für super dringende Einsätze vor Ort und genau die möchte ich möglichst verhindern. Dann lieber eine Appliance. Oder eben Windows Aber Windows schlage ich mir wohl wieder aus dem Kopf auch wenn mir die Filtermöglichkeiten der Firewall ausreichen würden bzw. teilweise sogar einfacher ist (koppeln mit AD-Konten z.B.) Natürlich nicht. Aber die Daten müssen ja dennoch ausgetausch werden (siehe Posts weiter oben). Mit verschiedensten unsicheren Protokollen und eben mittlerweile immer mehr Live-Daten. Und nur weil man eine Firewall hat, heisst das ja nicht, dass es deswegen sicher ist wenn man auf unsichere Weise kommunziert. Datenaustausch mit USB-Sticks.: Nope, das habe ich alles ausgemerzt. In jedem Betrieb gibt es ein absolutes Stick-Verbot. Egal ob Externe oder interne Mitarbeiter. Man muss immer bedenken, eine Machschin die 50k bis 1 mio kostet, mechanisch top ist, wird nicht komplett getauscht nur weil der Steuerrechner veraltet ist. Da muss man eine erträgliche, manchmal kreative Lösung suchen. Bei hochtintegrierten Maschinen/Produktionszellen wird das zunehmend schwieriger. Insbesondere weil das so mit XP/7 erst so richtig angefangen hat. Aber auch ein aktuelles Windows 10 hilft nichts, wenn der Hersteller sämtlichen Support verweigert wenn Updates eingespielt werden. Was ich sogar verstehen kann bei der Pro Version (Bei XP 7 habe ich dank getrennten Sicherheits/Featureupdates die reinen Sicherheitsupdates dennoch problmlos eingespielt). MS hätte ja Abhilfe geschaffen mit IoT/LTSC aber ich bin nicht sicher, dass ich das noch erlebe solange ich arbeite bis das in der Industrie durch ist und nicht mehr Pro verwendet wird. (Der Beschaffungsweg ist ja auch tendenziell beschissen). Im Messbereich gibt es schon löbliche Ausnahmen. :)

1. Frage prüfst Du mit nslookup vom gleichen Client wo Du auch die IP eigibst oder von einem anderen? Ohne das selber überrüft zu haben, sich selber könnte er dann möglicherweise durchaus kennen wenn Du die IP statisch hinterlegst. Auch kann die Adresse noch im Cache liegen. --> ipconfig /flushdns nach jeder Änderung 2. Frage: Ohne den Prozess bei der Vergabe von IPv6 Adressen und die nachfolgende Registrierung in DNS zu kennen, sicher dass Dein Windows-DHCP Server auch die IPv6 vergibt? Oder könnte das auch ein Router sein, wo der Haken nicht rausgenommen wurde? Dann gäbe es den Eintrag im DNS nicht wenn der. (Aber eben, ich weiss nicht wie das gelöst ist in IPv6, sprich ich habe keine Ahnung ob der Client oder der Server die Registrierung vornimmt) --> Du könntest z.B. mal das Auditing der Firewall aktivieren, dann erkennst von wem die DHCP-Pakete kommen (erkennbar an den Ports 67/68). Die Einträge erscheinen im Sicherheitslog. Am besten Neztwerkadapter deaktivieren, Ereignisfenster aufmachen und Netzadapter aktivieren. Oder ipconfig /renew. Englisches OS: auditpol.exe /set /category:"Object Access" /subcategory:"Filtering Platform packet drop" /success:enable /failure:enable Deutsches OS: auditpol.exe /set /category:"Objektzugriff" /subcategory:"Filterplattform: verworfene Pakete" /success:enable /failure:enable Sprachübergreifend: auditpol.exe /set /category:"{6997984A-797A-11D9-BED3-505054503030}" /subcategory:"{0CCE9225-69AE-11D9-BED3-505054503030}" /success:enable /failure:enable

Vielleicht habe ich das etwas missverständlich ausgedrückt. Ich versuche es mal anders. Wenn man eine Inbound-Regel erstellt, heisst das nicht, dass die Antwort auch tatsächlich zurück gehen kann. Dafür braucht es oft eine zusätzliche Outbound-Regel. Bei der Outbound-Regel muss aber so gut wie nie eine entsprechende Inbound-Regel erstellt werden um die Kommunikation zu ermöglichen. Die Rückantwort geht auch so durch die Firewall. Ausnahme ist z.B. SMB. Du kannst SMB für inbound nicht in der FW abdrehen ohne bescheidene Side-Effects. Die Kommunikation mit DC, CA, WSUS, Filer, Printer brauchen die Inbound-Regeln von SMB. Teilweise sogar zwei Rules (Local/Remote). Das einzige was ich nicht sicher bin, ob sie sie nur brauchen wenn die Verbindung gesichert/signed etc. ist, oder obe es auch für eine ungesicherte Verbindung ebenfalls notwendig ist. Das kann man feststellen, wenn man sämtliche Standardregeln deaktiviert und alle selber nachbaut aufgrund der fehlgeschlagener Kommunikation. Edit: Ja ich habe mir das mal angetan obwohl das kein Mensch macht. Sprich geschaut was alles an minimaler Kommunikation notwendig ist, damit das anmelden an eine Domäne, austausch von Zertifikation, File-Services, Printservices etc. schmerzfrei funktioniert. Macht kein Mensch, ich habs trotzdem mal gemacht. ;) Meine Vermutung geht dahin, dass das unterschiedliche Verhalten etwas mit der Sicherung der Kommunikation zu tun hat. Also das es nicht eine "richtige" Antwort ist, sondern teilweise ein Neuaufbau einer Verbindung für die Rücksendung ist bei SMB. Wenn Windows selber der Initiator ist, bleibt es wohl wie es ist. Ist aber reine Mutmassung. Dafür habe ich die Pakete an sich zu wenig analysiert sondern nur die geblockten Pakete auf den entsprechenden Ports/Protokoll/Dienst festgestellt. Block all heisst: eine Blockieregel gewinnt über eine Erlauben-Regel. Egal welche. Block standard heisst: eine Erlauben-Regel gewinnt über eine Blockier-Regel. Das ist eine "Krücke" der Windows Firewall. Vermutlich ist das dem Umstand geschuldet, dass die Windows-Firewall nicht wie eine "normale" Firewall Regeln der Reihe nach abarbeitet sondern eben alle zusammen. So kann man immerhin sagen, welche gewinnen soll. Je nach dem echt zum "werfen".

Alles was Outbound erlaubt ist, ist bei der Windows-Firewall auch automatisch Inbound erlaubt. Sprich wenn die Port/Protokoll/Local/Remote-Paarung etc. identisch ist bewirkt eine Outbound-Regel, dass der Inbound-Part ebenfalls erlaubt ist. Deshalb muss man auch sehr selten Inbound-Regeln definieren. Umgekehrt gilt das nicht. Wenn Du Outbound auf Standard Offen lässt, kann jede Software problemlos überall hin und her kommunzieren. Der komplette Inbound-Traffic ist erlaubt, solange der Verbindungsaufbau durch den Client stattfindet. Wodurch der auch immer ausgelöst wird (Service, Mausklick, Task, installiertes Programm etc.). Dann gibt es noch diverse vordefinierte Regeln die für Basis-kommunikation grundsätzlich zwingend notwendig ist oder der Sicherheit dienen (Block). Die bekommst Du in der GUI und selbst command line nie zu Gesicht (Registry, Static Rules). Ein kleiner Teil der System-Rules sind Configurable, die sieht man zwar nicht in der GUI, dafür aber in der cmd. Dann gibts eine stark wachsende Anzahl von App-Rules. Die siehst (fast) nur in der Registry und sind auch nur da manipulierbar (die neuesten Updates bringen hier angeblich etwas Funktion in die GUI oder Cmd-Line, noch nicht getestet) Zu SMB: Du kannst nicht einfach SMB auf den Clients abdrehen. Da geht dann wirklich einiges nicht mehr. LanmanServer kann man theoretisch abdrehen. Irgendwo habe ich mal aufgeschrieben was nicht mehr geht (mir wars dann aufgrund einer Situation zu doof, weiss aber nicht mehr warum, müsste ich suchen). Findest aber sicher per google raus. LanManWorkstation kannst nicht wirklich abschalten, sonst geht nicht mehr viel weil z.B. Netlogon oder die Ausführung von GPO's etc. davon abhängig sind. Auch DFS oder Zugriff auf Fileshares geht nicht mehr. Was geht ist die Beschränkung des Traffics auf bestimmte Endgeräte oder sogar Benutzer/Gruppen. Was so wohin geht/herkommt kann man sehr schön erkennen wenn man das Firewall-Journaling aktiviert. Englisches OS: auditpol.exe /set /category:"Object Access" /subcategory:"Filtering Platform packet drop" /success:enable /failure:enable Deutsches OS: auditpol.exe /set /category:"Objektzugriff" /subcategory:"Filterplattform: verworfene Pakete" /success:enable /failure:enable Sprachübergreifend: auditpol.exe /set /category:"{6997984A-797A-11D9-BED3-505054503030}" /subcategory:"{0CCE9225-69AE-11D9-BED3-505054503030}" /success:enable /failure:enable Die Einträge landen im Security Log. Musst die Grösse auf 256MB oder mehr hochstellen, sonst ist das rasch voll. Du wirst erstaunt sein, wieviel Kommunikation so ins weite Netz geht. Mühsam ist die Unterscheidung von Traffic der via der svchost.exe läuft. Da erkennt man zwar die Prozess-Nummer (wiederum mit tasklist.exe aufrufbar), aber die ist nicht zwingend aktuell, weil der Prozess schon wieder beendet sein kann. Da muss man sich dann damit behlefen den Services eigene Hardlinks zur svchost.exe zu spendieren. Dann werden die Verursacher sichtbar (z.B. svchost_servicename.exe) und man kann entsprechende Regeln aufsetzen. (Wobei es unzuverlässig ist auf Services Regeln zu erstellen weil manche von Windows aus Sicherheitsgründen maskiert werden, leider erkennt sie dann auch die Windows-Firewall nicht mehr *hmpf*) Da musst Du entweder tatsächlich mit den Hardlinks arbeiten oder tiefer rein und auf BFE-Ebene filtern via den zugehörigen Service-Protokollen (RPC).

Danke euch! @mwiederkehr Zusätzliche 0815 Hardware will ich vermeiden wenn ausfallsichere Server vorhanden sind. Dann doch lieber eine VM-Appliance. Wenn es mit Bordmitteln von Windows sinnvoll klappt, ist das aber jeweils meine bevorzugte Variante (Kosten, KnowHow usw). @daabm Wieso meinst Gebastel? Weil es tendenziell mühsam in der Konfig/Konfigauswertung ist und nicht "Ressourcenschonend"? Eigentlich will ich ja kein Routing sondern eine simple Bridge mit Filterfunktion. Wenn der Verkehr über die Windows-Firewall/BFE läuft, kann ich da ran, sonst nicht. @cj_berlin ISA/TMG: Für alles brauchte man den Client nicht. Im Detail ist das per Schieberegister aus meinem Gedächnis raus, wann er es notwendig war und wann nicht. Konfig war halt sehr straight und imho einfach verständlich. Und selbst die GUI und die Logs waren gut. Beim TMG konnte man soweit ich mich erinnere die Patches über all die Jahre gesehen glaub an einer Hand abzählen. Muss also doch ziemlich gut programmiert worden sein. Und da sie in die BFE eingegliedert war, muss auch diese an sich ziemlich gut sein. Aber zurück zum Thema: Im Grunde bin ich gezwungen davon auszugehen, das die "unsicheren" Maschinen grundsätzlich safe sind da von extern möglichst abgeschottet. Sonst dürften keine Daten zwischen Maschinen/CAD/Büro ausgetauscht werden. Auf gar keine Weise. Das ist mir durchaus bewusst. Genau deshalb soll diese Maschine zwischen den Netzen ja eine Brücke mit Kontrollstelle/Beschränkung sein. Also im Grunde einfache Firewall-Funktionen übernehmen. Hauptziel ist es, einem allfällig infizierten Desktop die Möglichkeit zu nehmen/erschweren/Potential einzugrenzen, die unsicheren Clients der Produktion direkt mit unsicheren/anfälligen Protokollen zu erreichen/befallen und somit die Produktion lahmzulegen. Auch mit Kopien der Steuerung ist das äusserst mühsam (0-Punkte neu einlernen, neu kalibrieren, auslagern und neu einspielen von 800-1000 Werkzeuge pro Fräscenter, das gleiche mit Rohmaterial in den Roboter-Lager). Wenn jemand die Kontrolle über den Client hat, kann er die Schutz-Funktionen ja auch aushebeln. Wenn die Nutzung von der Brücke geblockt wird, hilft ihm das auf seinem Weg in die Produktion (hoffentlich) nicht weiter. Etwas mehr Hintergrundinfos falls von Belang: Client A aus Bereich "Büro" ist Up to Date, hat empfohlenen Einstellungen, hat Internetzugriff Client B aus Bereich "Maschinennetz" mit denen ich ins Büro kommuniziere möchte sind Up to Date, haben ein modernes OS. Möglicherweisegewisse sind aber unsichere Einstellungen notwendig, um die Kommunikation innerhalb Netz zu den "alten" zu ermöglichen. Vieles was nicht sicher ist, kann ich per Windows-Firewall auf die Maschinenziele beschränken. Aber halt nicht alles (SMB1 z.B. kann nicht auf bestimmte Endgeräte beschränkt werden sondern nur SMB an sich, NTLM ist auch an oder aus). Wenn der eigentlich sichere B mit Einstellungen unsicher gemacht werden muss, soll der Zugriff von A auf B über einen sicheren Brückenkopf/Relay erfolgen. Dieser stellt dann auschliesslich die Funktionen bereitstellt die zwischen A und B benötigt werden. Dieser Brückenkopf (C) hat keine unsicheren Einstellungen wie aktiviertes SMB1/FTP und ist Bestandteil des AD. Die Idee ist nun sicherzustellen, dass nur die C Server und die sicheren B von den Clients A erreicht werden können und umgekehrt. Auch wenn B und C sowie Uralt-Clients im gleichen Netz sind. Wenn ein C nicht mit verhältnissmässigem Aufwand zu bewerkstelligen ist obwohl B unsicher ist, soll die Bridge die Kommunikation mit dem proprietären Protokoll von A nach B direkt ermöglichen. Das soll dann auch möglichst nur auf Systemen sein, wo kein Usere mit Internetzugriff direkt darauf arbeitet. Da das alles irgendwie einfach handelbar bleiben soll, auch für die Fehlersuche, möchte ich eben möglichst kein Routing sondern eine Bridge die gewisse Kommunikationswege erlaubt und den Rest blockiert. Auch soll es möglich sein, dass ich die Bridge zur Fehler-Ausschliessung raus nehmen kann. Als letztes müssen noch Files hin und her. Messprotokolle, 3D-Zeichnungen, Überwachungsprotokolle usw. Das geht über Workarounds/Transfersystem, habe ich schon Jahr im Einsatz, ist aber etwas umständlich. Wenn ich die strikte physische Netztrennung eh aufgebe, wären synchronisierte Filer schöner und bequemer für die Mitarbeiter. Da wäre die Idee SMB zwischen den Bereichen ganz zu blockieren oder nur zwischen den Filern freizugeben (sofern DFSR überhaupt SMB benötigt, sind ja eigene Protokolle). Die Maschinen kommunzieren mit dem unsicheren Filer und authentifizieren sich mit Lokalen Service-Accounts/NTLM und erhalten Zugriff auf Files die sie betreffen. Die sicheren Clients gegen AD mittels Kerberos. DFSR übernimmt die Synchronisation. Bessere Vorschläge sind natürlich herzlich willkommen!

Salut zusammen, Netzwerk-Segmentation bin ich nicht wirklich der Hirsch. Bis jetzt konnte ich mich immer mit physisch vollständig, virtuell mit VLANS und sonst mit Netmasken durchschlängeln. ;) Nun brauche ich eine Kommunikation zwischen zwei Netzen zwischen Rechner aus Bereich A (Maschinen, allenfalls CAD) zu bestimmten Rechnern aus Bereich B (Rest) die ich mit keinen Work-Arounds bewerkstelligen konnte die ich sonst so einsetze. Ein paar Endgeräte aus Bereich A sind SEHR fragwürdig oder werden es demnächst (XP, 7, 8.1 oder 10 ohne Updates), der Ersatz nicht ohne Einwurf zu grosse Noten möglich oder nicht möglich. Nun sollen nur bestimmte Clients/Server überhaupt miteinander sprechen können und das wiederum nur über definierte Protokolle/Ports (Überwachungstools, allenfalls Files, ERP-Anbindung). Kommunikation möglichst transparent zwischen zwei Netzbereichen im gleichen oder unterschiedlichen IP-Range die Kommunikation soll über eine Firewall, ich möchte also steuern über welche Ports und Protokolle von wo nach wo etwas gehen darf Ticket holen aus Bereich A für die sicheren Clients am DC in Bereich B soll aber gehen. Auch der WSUS soll erreicht werden können im Bereich B. Lösung auf Windows Basis ist tendenziell bevorzugt, Konfiguration möglichst einfach Alle Maschinen die von B nach A in Frage kommen - Ausser der DC (multihome) und vermutlich auch der Filer? - dürften eine zweiten Lan-Port haben für die zusätzliche physische Trennung. Aber ob das "hilft" für DNS? Was ist die sinnvollste Lösung für sowas? Eine Bridge ist ja eher schwierig zum effektiven filtern, aber gilt das auch für eine Bridge unter Windows? Läuft das alles über die Firewall-Rules oder nur Routen? Bevor ich jetzt gross stundenlang austeste kann mir ja vielleicht jemand nen Tipp geben ;) Der ISA/TMG hätte sowas easy peasy gemacht... Aber der ist EOL und möglicherweise auch etwas overkill. Vielen Dank!

Einen gewissen Spielraum habt ihr ja. Wenn ihr es durchsetzen könnt, dass ein Naming-Schema eingehalten wird, dann könnte man doch für das Anlegen eines solchen Projekts (oder wie man so einen Unterordner nennen mag) doch ein kleines auf euch zugeschnittenes Powershell-Modul tippseln. Mit der Funktion im Modul erstellt ihr dann mittels der getätigten Angaben die AD-Gruppen, die entsprechenden Ordner und Unterordner und setzt auch gleich die entsprechenden Berechtigungen. Gerade für solche Fälle wo das ganze ständig wiederkehrend ist, spart das unglaublich Zeit. Wie immer steht und fällt eine solche Automatisierung aber mit dem einhalten eines Systems. Änderungen/Erweiterungen an der Struktur sollten dann auch wieder möglichst automatisiert gemacht bzw. möglichst vermieden werden. Sind Projekte zu unterschiedlich, hat es sich an anderer Stelle bewährt, eine Art Projektbeschriebdatei zu erstellen mit den Einstellungen. Also in diesem Fall ein Modul mit den Funktionen und eines welches die Struktur/den Tree und die Zugrifssrechte beschreibt und mit diesen Infos die entsprechenden Funktionen aufruft und wiederum die Ordner erstellt/Berechtigungen setzt. Das ganze kann man dann mit allerei Überprüfungen und Logs ausschmücken. Halt je nach dem was gefragt ist. Erfahrungsgemäss lohnt es sich, die Logs und Überprüfungen möglichst von Anfang und nicht erst im Nachhinein einzubauen. ;)

Schadcode nachladen: Das war logischerweise auf 3rd Party Tools gemünzt. Sorry Deine Einstellung ist komplett falsch. Präventionsarbeit zu leisten und Mitarbeiter und insbesondere die GL für das Thema zu sensibilisieren gehört zu den Aufgaben eines externen Dienstleisters. Dafür stellen die ja einen ein, weil sie selber keine oder wenig Ahnung haben. Sprich man muss dafür Sorgen, dass die selber merken, dass entsprechende Schulungen für die Mitarbeiter notwendig sind und gewisse Verhaltensregeln aufgestellt werden müssen. Damit diese eben nicht versuchen, Sicherheitsmassnahmen zu umgehen, sondern verstehen wozu die da sind. Genau weil es immer einen kreativen Weg gibt. Ganz ehrlich, schafft man das als Dienstleiter nicht, gehört man selber in eine Kommunikationsschulung. Vor 20 Jahren war das teilweise tatsächlich schwierig die Leute zu Überzeugen, heute ist das wirklich keine Hexerei mehr. Die Überzeugungsarbeit leisten bereits die Medien, man muss nur noch sagen was sie tun sollen oder eben nicht. Das reinste Heimspiel. Jeder hat heute zu Hause viele private Fotos, die er nicht gerne verliert. Selbst die Senioren. Das Problem ist nur, sie wissen manchmal über die einfachsten Verhaltensregeln nicht bescheid. Ansonsten: Für den Umgang mit Chemikalien/Maschinen sind die Leute gewohnt zu unterschreiben, dass Sicherheitsmassnahmen verstanden, befolgt und insbesondere nicht aktiv ausgehebelt/umgangen werden. Das gleiche Prinzip muss man auf die IT anwenden. Inklusive allfälliger Massnahmen. Ansonsten gilt es wie in der Landwirtschaft, die faulen Äpfel werden nicht gesund nur weil um sie herum alles gesunde Äpfel sind. Der Faule muss raus. So einfach ist das.

OK. Also mit der Windows-Firewall ist das ziemlich trivial. Weil halt auch die Log-Einträge zeitlich exakt übereinstimmen. Sprich man kann im gleichen Sekunden/Sekunden-Bruchteil die entsprechenden Pakete mit den Remote-IP's auffinden, welche zur Zeit des NTLM-Eintrages geloggt worden sind. Solange MS die Authentifizierung gegen Lokale Accounts von Nicht-DC-Maschinen erlaubt bzw. das Enforcement auf Nicht-DC's nicht per se zwingend ist, kann man sich mit Nicht-Domain-Accounts behelfen.

Gegen den Physischen Mous-Jiggler hätte ich noch nicht mal so richtig was. Kriegt er Kreaktiv Punkte. Gegen den Rest welcher die IT-Abteilung nicht zu Verfügung stellt schon. WEIL: Genau mit so schwachsinnigen Programmen die oberflächlich einen Nutzen haben, wird später Schadcode nachgeladen. Daher Verbot für jegliche Tools und Umgehungsversuche inkl. Abmahnungen. Da gibts eine 0 Toleranz. So werden oder sollten die MA's geschult werden. Und es funktioniert tatsächlich, weil man täglich in den Zeitungen lesen kann was passiert und nicht nur passieren kann. Optimalerweise hat man AppLocker, dann können sie die Fremdsoftware noch so lange ausprobieren.

Salut zusammen, Bei Windows 11 22H2 wurde das ja standardmässig eingeführt. Siehe: https://learn.microsoft.com/en-us/troubleshoot/windows-client/printing/windows-11-rpc-connection-updates-for-print Im Netz habe ich nun gefühlt 1000 Anleitungen gefunden wie man das Feature rückgängig machen kann, aber keine einzige wie man diese Verbesserung tatsächlich nutzen kann *schulterzuck* Da alls was mit Printer zu tun hat eh Exploit-Anlaufstelle Nummer 1 ist und jede Verbesserung gemacht werden sollte daher die Frage: Kann man auch das Gegenteil machen? Also den Printserver beibringen, dass sie solche Verbindungen akzeptieren? Falls ja welche Server-Versionen unterstützen das? Das ganze natürlich am liebsten auch bei Windows 10 / Server 2022.... Sprich geht das oder nicht? Und falls ja, kennt jemand grad einen Artikel dazu? Ich vermute ist noch ein exklusives W11 Feature, da ich nichts dazu gefunden habe. Aber vielleicht weiss ja jemand mehr. Grüsse und Danke

@testperson: So verstehe ich das auch. Ich scheitere etwas damit was tatsächlich eingestellt werden soll bei den anderen Bits/Zeichen. 28/29 ist ja dann für das enforcement des aktuellen Zeugs. Beide auf 1 und es ist aktiviert. Soweit so gut. Immerhin scheint man - weil eben Standardmässig alle Werte 0 sind - am Standardverhalten nichts zu ändern wenn man einfach die letzten Zeichen für die aktuellen Enforcements auf 1 setzt und ansonsten nur die Erweiterungsbits auf 1 (10) bzw. 2 (20). Betreffend Powershell: Hier sind die verschiedenen Variante gut beschrieben, inkl. Powershell. Einfahc für ältere Werte, aber kann man ja adaptieren: https://techcommunity.microsoft.com/t5/core-infrastructure-and-security/duplicate-spn-errors-active-directory-migration-tools-and-kb/ba-p/258102 Bei manchen habe ich aber das Gefühl, man sollte aus Sicherheitsgründen vom Standard abweichen. Manche sind selbsterklären durch die Beschreibung, andere eher nicht. Aber beurteilen welche Variante nun sicherer ist, fällt mir nur aufgrund der Beschreibung bei manchen einigermassen schwer. Gibt es da Empfehlungen? Als Beispiel Bit bzw. Zeichen 9, das scheint mir z.B. relevant zu sein, da es um Passwörter geht: Was ist den da nun tatsächlich erwünscht? Will man diese Heuristic aufs fUserPwdSupport haben oder nicht? Falls man sie haben will, will man das nur bei AD LDS (0) oder auch bei AD DS (1) haben oder eben nirgends? Wenn ich es richtig interpretiere ist es besser mit. ABER: Warum ist es dann standardmässig bei AD DS nicht aktiviert obwohl es die einstellung schon mindestens 15 Jahre gibt? Aus irgend einem Grund wurde die ja geschaffen und standardmässig für eine der beiden Varianten aktivert und für die andere deaktiviert.

Woher die Anfrage kommt, kannst in der Regel mit Firewall-Auditing herausbekommen. Die exakte Zeit der Logs vergleichen für Allow und/oder Rejected Packets.

Na klar ist es nicht geheim. Das ist eher in Bezug darauf gemeint, das MS-Mitarbeiter einem das nicht mitteilen wollen obwohl es eben eigentlich relativ klar wäre. Darum gehts ja, sie wollen keine Stellung (mehr) beziehen und/oder dürfen das auch nicht mehr. Dass sich einer zu dieser Aussage hinreissen lässt, ist tendenziell selten bis nicht (mehr) gegeben. Und auch klar, aus den Bestimmungen kriegen man alles raus. Auf deren Basis erhält man die ja die ensprechenden Nutzungsrechte und sind allenfalls Pflichten definiert. Nur ist nicht unbedingt sofort klar wo man suchen und wie man es interpretieren muss.

Nun, bei manchen Abo's liegt das Problem halt schlicht und einfach an der Tatsache, dass es nicht vorgesehen ist, Maschinenbasiert zu kaufen. Genauso wie es das anders rum gibt. Auch wenn es an der Rechtsberatung entlangschrammt, konnte ich einem MS Mitarbeiter mal folgende Aussage entlocken: Solange alle Mitarbeiter die in irgendeiner Form direkt oder indirekt mit der Funktion/Geräte/Zugriff zu tun haben auf User-Basis lizenziert sind, sei es Ihnen aus lizenztechnischer Sicht herzlich egal wenn ein rein geräte-basierter Zugriff nebenher läuft. Das Maximalziel sei ja bereits erreicht, jede Person die damit zu tun hat ist lizenziert. Einfaches Beispiel: Ein Multifunktionsdrucker kann auf ein Fileshare scannnen. Nur ein Mitarbeiter darf effektiv scannen. 1. der Scanner steht in der Caffeteria 2. der Scanner in einer Abteilung 3. der Scanner steht im Büro eines Mitarbeiters, andere haben nichts verloren im Büro ist optimalerweise sogar abgeschlossen. Entweder kann das nun je nach räumlicher/phyischer Trennung auf User Basis lizenziert werden oder eben das Gerät selbst. Bei 1. und 2. macht sicher das Gerät Sinn. Wozu allen Mitarbeitern eine CAL kaufen, wenn nur ein User überhaupt Scannen darf. Selbst wenn alle dürften und keiner etwas mit PC's am Hut hat wäres sinnvoller für das Gerät. Bei 3. wäre es übertrieben auch für das Gerät eine zu kaufen wenn der User schon eine hat. Angenommen es gibt die Geräte-CAL aber nicht und das Gerät steht dennoch in der Caffeteria: Jetzt haben wir ein Problem, es darf zwar nur einer Scannen, aber jeder könnte Scannen. Wir müssten folglich jedem Mitarbeiter eine CAL kaufen. oder wir müssen mit geeigneten Massnahmen sicherstellen, dass niemand der nicht darf, eben auch nicht kann. Schlüssel/Keycard/Passwort am Scanner/Scanner in das Büro des Mitarbeiters verschieben etc. Auch das ist für MS in Ordnung. Wenn man dieses Prinzip auf die anderen MS Produkte überträgt und sich nicht selbst belügt/schön redet oder Zugriffsbeschränkungen vernachlässigt, dann ist man Grundsatz korrekt lizenziert. Bei einer rein administrativen E-Mail-Adresse auf welche mehrere Admins Zugriff haben/Meldungen erhalten würde das heissen: Wenn alle die automatisiert Meldungen von Geräten erhalten oder Zugriff auf das Mailkonto haben selber über eine eigene Lizenz verfügen, ist für MS die Maximalforderung aus lizenztechnischer Sicht erfüllt weil auf physischer-User-Basis lizenziert wird. Im Umkehrschluss heisst das aber auch: Man muss wohl oder übel alle Admins lizenzieren auch wenn die Adresse gemeinsam ist. Man bezahlt den Physischen User. Für ein allenfalls gemeinsame Administrativ E-Mail-Adresse bezahlt man dann nicht in dem Sinne für eine Lizenz, sondern für die Dienstleistung Speicherplatz/Management. Im Detail muss man natürlich die Bestimmungen für das entsprechende Produkt lesen, aber generell kann man davon ausgehen, dass wenn es in den Bestimmungen keine Einschränkungen oder allenfalls auch Begünstigungen zu diesem Prinzip gibt, dieses Prinzip auch angewendet werden kann.

Ich präzisiere: Für Lokale Accounts in Maschinen die an eine Domäne gebunden sind und man sich von extern authentifizieren möchte. Diese anfragen werden auch abgeblockt wenn man z.Bsp. auf ein Share zugreifen möchte und enforcement aktiviert ist. Edit: Deine Frage habe ich weiter oben beschrieben, dass ich das weiterhin als Ausnahme haben möchte für die Workarounds. Also NTLM. Stand jetzt, geht das nicht mit Enforcement. Sprich man muss NTLM-Blockieren wieder aufheben. Aber das weisst Du bestimmt oder? Edit2: Und nein man kann - wie auch auch weiter oben beschrieben - keine Ausnahme für das Zielgerät machen sobald gängige Sicherheitsfeatures wie SMB-Signing aktiviert ist. Weil nicht das zugreifende Gerät in der Auswertung erscheint sondern eben das Gerät auf das zugegriffen wird. Auch wenn das nach dem November theoretisch keinen Unterschied mehr macht. Glaube zwar nicht, das dies von MS so gewollt ist, fakt ist es aber. Das lokal ohne Domäne Kerberos "schwierig" ist, versteht sich ja von selbst oder?

Ein wenig frech ist das aber schon... Soviel kostet ja das Original in neu!

Stimmt... Für WMI gibts ja auch fast alles, nur ist das dann wirklich die Kategorie obermühsam da was rauszupfriemeln wenn man nicht täglich damit arbeitet.

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.

Weitergraben hilft... MS - wenn man mal zu den richtigen Leuten durchgestellt wird - hat durchaus sehr fähige Leute. Aber es braucht immer eine gewisse Hartnäckigkeit wenn man nicht auf Anhiebe jemanden schlaues bekommt. Manchmal scheint mir, der FirstLevel bekommt eine Erfolgsprämeie für selber abgeschlossene Fälle oder so...

An die guten Leute ist je länger je schwieriger zu kommen. Wie bei jeder grösseren Firma. Haarsträubend teilweise. Die Preise gehen dafür fleissig nach oben. Eigentlich gibt es nur zwei Möglichkeiten: Telefonisch (äusserst) hartnäckig bleiben, notfalls x-mal anrufen, vorgesetzte verlangen wenn man nicht weiter kommt usw. Zweie: Anfrangen per E-Mail kurz und knapp formulieren mit der Bitte an einen Spezialisten auf diesem Gebiet verwiesen zu werden. Richtig toll sind die Chats. Das sind oft Bots und keine richtigen Leute. :( Mir fällt grad ein: LTSC Produkte sind jetzt in einem speziellen Store, möglicherweise auch die Non-Profit?!? Mein Distri hat einen Store bei MS und da kann ich Produkte kaufen und die kommen dann gleich ins Konto.