wznutzer

Habe ich noch nicht darüber nachgedacht. Im laufenden Betrieb tatsächlich nur die Sammlungen (User hinzufügen, entfernen) und das so 2 - 3 x im Monat. D. h. Deine Überlegung wäre in die Richtung, dass ich evtl. zwei OUs habe, in einer werden die User als Admins hinzugefügt und in einer anderen entfernt und ich verschiebe die VMs dann je nach Bedarf hin und her?

Hallo und guten Morgen, ich bin mir unsicher, wie ich folgendes Szenario beurteilen soll: Es gibt eine RDS-Bereitstellung mit Broker, Gateway und Session-Hosts. Auf dem Server mit dem Broker wird die Bereitstellung verwaltet. D. h. da sind im Servermanager alle Server der Bereitstellung hinzugefügt. Das Gateway ist in einem separaten Netzwerksegment. Ein Session-Host ist ebenfalls in einem separaten VLAN, weil dieser von den Nutzern her einem besonderen Kompromittierungsrisiko ausgesetzt ist. Das alles funktioniert, die Firewall-Regeln sind entsprechend gesetzt. Um die Bereitstellung zu verwalten gibt es einen User, der auf allen beteiligten Servern Adminrechte haben muss. Und genau da bin ich mir nun nicht sicher, ob das ein Risiko ist, weil es so einen Benutzer gibt, der über die VLANs hinweg Adminrechte hat und die Anmeldung auch über die VLANs hinweg genutzt wird. Damit eine solche Bereitstellung funktioniert müssen folgende Freigaben konfiguriert werden: WinRM: Broker -> Gateway, Session-Hosts RPC: Broker -> Gateway, Session-Hosts RPC: Session-Hosts -> Broker RDP: Gateway -> Session-Hosts, Broker Port 5504: Gateway -> Broker (WebAccess) Also, sollte das Gateway kompromittiert werden und die Zugangsdaten herausgefunden werden, kann man sich vom Gateway aus per RDP mit dem Broker und allen Session-Hosts verbinden und die meisten Session-Hosts stehen im allgemeinen LAN und sind nicht separiert. Habe ich einen Denkfehler oder gibt es da eine Art "best practices"? Ergänzung Lt. früheren Tests, kann man das Passwort im Klartext mit Mimikatz auslesen, wenn man sich interaktiv (per RDP) an einem Server anmeldet. Erfolgt die Anmeldung per WinRM sollte (Theorie) nur das Ticket/Hash ausgelesen werden können. D. h. ich müsste dann nur dafür sorgen, dass der Verwaltungsuser zwar Adminrechte überall hat, aber mich mit diesem niemals per RDP anmelden? Liege ich da falsch? Vielen Dank

Falls es für irgendjemand von Interesse ist. Es gibt eine neue Version vom RDCman.exe. Das scheint die Skalierung mit 4K Monitoren besser zu sein.

Meinst Du tatsächlich deaktivieren oder priorisieren? Ich habe mir angewöhnt zu priorisieren. https://learn.microsoft.com/en-us/troubleshoot/windows-server/networking/configure-ipv6-in-windows

Das ist mein subjektiver Eindruck, der sich aus dem Lesen von vielen Kommentaren/Posts über die Zeit ergeben hat. Hier eher nicht, aber in anderen Foren. Ja

Guten Tag zusammen, ich frage mich das schon länger, aber durch die Meldung von Veeam mit dem Score von 9.9, plagt mich jetzt die Neugier. Wie vermutlich alle hier wissen, kann der Mount Service von Veeam zur Remote-Code-Ausführung genutzt werden. Große Umgebungen werden sowieso separate Verwaltungsnetze für alles mögliche haben, während bei kleinen halt fast alles im gleichen Netz ist. Ich bin ein Fan der Windows-Firewall und nutze diese recht intensiv mal lokal oder auch per GPO. Dafür wird man dann schon mal als "der der es halt nicht besser kann" angesehen. Aber es tut halt auch gar nicht weh, z. B. RDP, WinRM oder eben halt auch die Veeam-Dienste per Windows-Firewall nur für die gewünschten Endpunkte freizugeben. Ist das in großen Umgebungen schlicht nicht zu handeln oder tatsächlich technisch schlecht, weil evtl. irgendwie umgehbar? Danke schon mal für die Meinungen...

Hast Du Filestream aktiv? Das ist ein weiterer Punkt in der Combobox der beim manuellen Vergleichen beachtet werden müsste. Soweit ich weiß, siehst du beim Shrink die Werte des PFS (Page Free Space), das ist etwas anderes, als Du mit dbcc updateusage aktualisierst. PFS sagt dem SQL-Server wo welche Seiten frei sind. Das lässt sich, meine ich, nur mit dbcc checkdb (ohne physical_only) "korrigieren", wenn da etwas durcheinander ist.

Was siehst Du genau bei verkleinern -> Dateien? Also bei aktuell zugeordnet und frei, getrennt nach Daten und Log? Der verfügbare Speicherplatz ist nicht gleich dem, der beim Verkleinern frei wird.

Guten Tag, installiert man einen RDP-Sessionhost gibt es dann automatisch den Ordner "C:\Windows\application compatibility scripts" und bei der Benutzeranmeldung wird UsrLogon.cmd aus "c:\Windows\System32" aufgerufen. Ich habe das schon seit Ewigkeiten per GPO deaktiviert. Ich war der Meinung ich brauche das nicht. Ich habe mir die Script angeschaut. Darin sind ein paar wilde Verweise auf andere Script die aber gar nicht existieren. Nun plagt mich die Neugier, braucht man das für irgendwas? Grüße und Danke

Ich hätte ein wenig anders geschaut . ldp.exe starten Binden => OK Ansicht => Struktur ==> als Basis DN deine Domäne dann links zur OU navigieren rechte Maustaste ==> schwer (heißt beim deutschen OS so) ==> Sicherheitsbeschreibung

In Deinem Fall, weiß ich das nicht. Aber mal schauen, tut ja nicht weh.

Du könntest Dir die Berechtigungen der OU mal mit ldp.exe anschauen.

Ich kann das Problem bestätigen, allerdings schon seit dem Upgrade auf 24H2, nicht erst seit einem Update. Zurück zu 23H2 und die Verbindungsabbrüche sind weg. Neuinstallation bringt nichts und die Abbrüche sind auch bei rein lokalem Zugriff mit einer lokalen VM da. Nicht aber mit der Hyper-V Console, sondern nur mit mstsc, RDCman, Devolutions RD Manager. Lösung habe ich leider keine, außer zurück zu 23H2. Aber die Erkenntnis, dass es mit der Realtek-NIC des Dock deutlich öfters vorkommt, als mit der eingebauten Intel-NIC.

Entdeckt nicht gerade, das versuche ich schon seit längerem umzusetzen. Aber ich lerne dazu was es so alles gibt. Deswegen unterhalte ich mich doch so gerne hier.

Will ich gar nicht widersprechen, sondern zustimmen. Da ich (meine ich jedenfalls) schon ein Fundament mit Applocker usw. habe, wollte ich das Dach noch etwas verzieren. Aber ich lerne auch gerne beim Fundament dazu.

Wow, was es alles gibt. Wenn man jetzt daraus etwas lernen will, schaltet man alles ab und wenn das nicht möglich ist, müsste man sich zu "kritischen" RDP-Servern von von separaten VMs aus verbinden zu denen man dann wiederum nichts von den RDP-Optionen aktiv hat. Alles kompliziert heutzutage.

Meinst Du das pauschal, weil es ja auch keine 100%-Sicherheit gibt, oder ein konkretes Szenario? Eine Antwort zur Sicherheit gibt es ja immer nur in Verbindung mit der Frage "Sicherheit, wovor?"

Guten Tag, leider muss ich mal ein wenig die Ahnungslosigkeit raushängen lassen. Ich stelle eine RDP-Verbindung von Rechner "A" zu Rechner "B" her. Gibt es ein Risiko, dass Rechner "A" in irgendeiner Weise kompromittiert werden könne, wenn auf Rechner "B" eine Malware laufen würde? Ich meine jetzt nicht die Sicherheitslücke, die noch nicht gepatcht ist. Der Admin eines bekannten Unternehmens meinte, dass er aus genau diesem Grund nur TeamViewer verwendet. Tatsächlich bin ich bisher davon ausgegangen, dass da nichts passieren kann, wenn ich z. B. von den lokalen Ressourcen nur die Zwischenablage "mitnehme". Klar, dann landen alle Informationen aus genau dieser beim Remote-PC oder umgekehrt, aber auch das könnte man abschalten. Ich meine auch nicht, dass die Anmeldeinformationen des Accounts dann leicht mit mimikatz & Co. ausgelesen werden können und solche Dinge. Da würde dann ja der Restricted Admin Mode oder Credential Guard helfen. Ich meine, ob es derzeit ein bekanntes Risiko gibt, dass der die Verbindung initiierende Rechner einem Risiko bei einer RDP-Verbindung ausgesetzt ist. Danke und Grüße

Noch überlege ich, was ich damit anfangen soll. Klar, jemanden mit Ahnung halte ich so kaum auf, aber Rechnung.pdf.bat funktioniert halt auch nicht. Im Prinzip ist es doch so, dass man damit das breit gestreute "Türenrütteln" ein wenig abwehren kann und das für lau. Ja, das würde per Mail nicht durchgehen und auch der Download funktioniert nicht, aber einen Schaden anrichten tut es auch nicht.

Ich will nicht ausschließen, dass die Paranoia bei mir getreichelt werden will. Der konkrete Anlass ist eher so ein: "Da könnte etwas sein, an was ich nicht gedacht habe, nicht weiß und wenn es nicht schadet (Powershell zu verbieten), nützt es vielleicht ." Würde man das in Typ 2 beschriebene nicht verhindern? https://learn.microsoft.com/en-us/defender-endpoint/malware/fileless-threats Dann fasse ich das mal so zusammen, dass das isolierte Einschränken von Powershell jetzt nicht so der Bringer ist. Man aber sehr wohl einen Effekt mit Applocker und den bei Microsoft beschriebenen zusätzlichen Einschränkungen (um die Blockaden nicht zu umgehen) erzielen kann.

Microsoft schreibt auch was dazu: https://learn.microsoft.com/en-us/windows/security/application-security/application-control/app-control-for-business/design/applications-that-can-bypass-appcontrol Das soll darauf abzielen, dass die Regel, nicht wie im Medium-Artikel beschrieben, umgangen werden können. Bin mal gespannt, ob dann noch alles funktioniert. Bei den User-Rechten finde ich keinen Ansatz, weil der User bereits nur das darf was er auch muss, zusätzlich zu weiteren Dingen, dass z. B. der Autostart der User automatisiert „aufgeräumt“ wird.

Danke für deine Einschätzung @cj_berlin. Ich muss noch ein wenig darüber nachdenken. Vor allem über den Einsatz von WDAC in Verbindung mit Applocker. Ich habe leider eine Info nicht angegeben. Bei den betroffenen Rechnern, handelt es sich um Remote Desktop Session Hosts. Ich glaube, ich muss noch ein wenig darüber nachdenken. Der Support macht tatsächlich gar nie eine Eingabeaufforderung auf. Der verlinkte Artikel macht mir einen Strich durch die Rechnung. Wenn man sich auf die Rechte konzentriert, in welche Richtung muss man laufen wenn ich den einzelnen Server bzw. PC im Auge habe? Drumherum versuche ich natürlich gar keine unberechtigten Zugriffe zuzulassen. D. h. im gedachten Szenario gehe ich davon aus, dass es der Angreifer bereits auf das System geschafft hat oder ein legitimer User etwas versehentlich oder auch absichtlich ausführt.

Ich kann einen Denkfehler meinerseits nicht ausschließen . Aber mir ist klar, dass das Wartungsaufwand zur Folge hat. Die Systeme, die ich im Blick habe, haben Applocker aktiv. Die Verzeichnisse, auf die ein User Schreibrechte hat, sind in den Regeln berücksichtigt. Das sollte die Variante über ein separates Programm abdecken. Das liese sich nicht ausführen. Darüberhinaus habe ich Fileless Malware bzw. Fileless Threats im Sinn. Ganz allgemein, warum sollte der User etwas ausführen dürfen, was er nicht braucht. Warum Applocker und nicht WDAC? Klar, WDAC scheint besser zu sein, aber auch wartungsaufwändiger als Applocker. Im Prinzip geht es darum, so viele Steine wie möglich in den Weg eines möglichen Angreifers zu legen. In dem Wissen, dass der einzelne Stein evtl. nichts nützt.

Hallo und guten Tag, während es für die Eingabeaufforderung recht einfach ist, diese für Benutzer zu deaktivieren, gibt es ein explizites Recht für die Powershell nicht. Ich überlege, was es für Möglichkeiten gibt und welche ich nehmen soll. Über die Berechtigungen für das Dateisystem. Über die Benutzerkonfiguration die Option "Angegebene Windows-Anwendungen nicht ausführen". Die entsprechende GPO hänge ich dann an die User-OU. Eine GPO die SRP für Powershell konfiguriert. Derzeit tendiere ich zur Lösung über die Berechtigungen über das Dateisystem. Wie macht Ihr das oder gar nicht? Grüße

Ich wollte nur kurz notieren, dass es auch ohne dsrevoke geht. Ich kann nichts dazu sagen, ob dsrevoke gut ist oder schlecht. Ich habe es nach nochmaligem Überlegen mit Powershell umgesetzt. Man kann das z. B. so machen: ################################################ # authentifizierten Benutzern Rechte auf OU nehmen ################################################ # Definition des Principal $AuthUsersPrincipal = "NT-AUTORITÄT\Authentifizierte Benutzer" # Definition der zu entziehenden Rechte: ListObject = 128, ListChildren = 4 $rights2Remove = [System.DirectoryServices.ActiveDirectoryRights]::ListChildren -bor [System.DirectoryServices.ActiveDirectoryRights]::ListObject ################################# # HauptOU ################################# # ACL OU auslesen $PathAclHauptOU = "AD:$PathHauptOU" $aclHauptOU = Get-Acl -Path $PathAclHauptOU # Durch die einzelnen ACEs (Access Control Entries) der OU iterieren # und prüfen, ob diese vom gewünschten Principal sind. # Falls ja, entfernen wir nur die gewünschten Rechte aus der ACE. $modified = $false foreach($ace in $aclHauptOU.Access) { if(($ace.IdentityReference -eq $AuthUsersPrincipal) -and ($ace.AccessControlType -eq [System.Security.AccessControl.AccessControlType]::Allow)) { # Prüfen, ob in diesem ACE mindestens eines der zu entfernenden Rechte enthalten ist if(($ace.ActiveDirectoryRights -band $rights2Remove) -ne 0) { # Aktuellen ACE entfernen $aclHauptOU.RemoveAccessRuleSpecific($ace) # Berechnung der verbleibenden Rechte (alle Bits, die NICHT in $rights2Remove gesetzt sind) $remainingRights = $ace.ActiveDirectoryRights -band (-bnot $rights2Remove) # Falls noch weitere Rechte übrig bleiben, ein neues ACE mit diesen Rechten erstellen if($remainingRights -ne 0) { $newACE = New-Object System.DirectoryServices.ActiveDirectoryAccessRule ( $ace.IdentityReference, $remainingRights, $ace.AccessControlType, $ace.InheritanceType, $ace.ObjectType ) # neues (bereinigtes) ACE hinzufügen $aclHauptOU.AddAccessRule($newACE) } $modified = $true } } } # Geänderte ACL nur setzen, wenn wirklich etwas entfernt bzw. geändert wurde if($modified) { Set-Acl -Path $PathAclHauptOU -AclObject $aclHauptOU } else { Write-Host "Keine zu entfernenden Rechte für '$AuthUsersPrincipal' gefunden oder bereits entfernt." }