wznutzer

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." }

Ergänzung: Damit ich nicht dumm bleiben muss, habe ich mal nachgelesen. Hyper-V kann inzwischen wohl paralleles Scheduling. D. h. wie @mwiederkehr geschrieben hat, den vCPUs nacheinander Rechenzeit geben. Allerdings verteilt der Scheduler innerhalb der VM trotzdem auf alle vCPUs. Das geht aber nur begrenzt, denn der Scheduler in den VMs verteilt die Aufgaben trotzdem auf alle vCPUs. Je nach Auslastung führt das dann zu vielem wechseln auf der CPU und auch dann wieder zu Wartezeiten, was dann der erwähnte Overhead ist.

Oh nein, Missverständnis, nicht die VM. Ich meine die Beratungssätze der Systemhäuser in der Gegend, die liegen je nach Junior, Senior, Architekt usw. bei bis zu 180€/Stunde. Das wusste ich nicht. Bedeutet das, dass die VM auch Rechenzeit zugeteilt bekommen würde, wenn diese z. B. 4 vCPUs zugewiesen hat, aber gerade nur 1 Core "frei" ist.

Das denke ich auch, aber für so einen Unsinn zahle ich halt keine 180€/Stunde. Blödsinn mache ich grundsätzlich selber und das kostenlos .

Ist es bei Hyper-V nicht so, dass die VM auch dann die Anzahl zugewiesener vCPUs belegt, auch wenn die Arbeit von einer vCPU erledigt werden könnte? Aber darum geht es mir eigentlich gar nicht. Sondern um die Aussage, dass die AD-DB beschädigt wird, wenn der DC zu wenig Ressourcen hat. Das kann ja dann auch bei 4 vCPUs passieren, wenn man nur genügend User hat.

Aus dem Grund, dass sonst die AD-DB beschädigt wird? Zwei Gründe: In der Cloud kostet jeder Kern extra und wenn ich lokal einen hohen Wert beim Performance-Counter "CPU Wait Time per Dispatch" habe und noch kein neuer oder weiterer Host in Sicht ist. Die Idee war, was man nicht braucht und nicht schadet, lässt man weg.

Hallo und guten Abend, ich muss mal dumm fragen. Meine DCs langweilen sich im Prinzip immer. Sie haben 2 vCPUs und 4 GB RAM. Wenn ich denen nur 1 vCPU gebe, merke ich gar nichts, außer bei der Installation von Updates, das geht spür- und messbar länger. Nun sagt mir ein Consultant, dass ich mir dadurch die AD-DB kaputt machen könnte, wenn der DC darin irgendwas schreiben will und diese eine vCPU durch etwas anderes ausgelastet ist. Man muss mindestens 2 vCPUs vergeben. Microsoft sagt 1.000 Nutzer pro Kern (ich habe 100): https://learn.microsoft.com/de-de/windows-server/administration/performance-tuning/role/active-directory-server/capacity-planning-for-active-directory-domain-services Das ist doch Unsinn, mit welcher Anzahl Kerne betreibt Ihr eure DCs? Grüße und einen schönen Abend

Ich muss da nochmals nachfragen. Lt der MS Doku ist Smart-Lockout standardmäßig aktiv und ab P1 kann man die Parameter verändern. Ich verstehe nicht, wie man nun erfolgreiche Brute-Force Attacken durchführen kann. Klar kann man immer mal Glück haben, aber die Erfolgsquote soll bei der Sache mit fasthttp ja immerhin fast 10% gewesen sein.

Irgendwie machen wir das alles interessenhalber. Ich freue mich immer, wenn ich mich hier austauschen kann.

Nun. weil ich gerne eine Doku habe in der die festen IPs stehen und ich da nicht in einer GPO nachschauen will. Deswegen sollen sich die Regeln davon abhängig bilden. Wahrscheinlich wäre es noch besser die Doku aus dem AD generieren zu lassen. Das mache ich vielleicht, wenn ich groß bin und nicht der Nebenher-Admin . Das ist prima, genau das werde ich nutzen, danke. Die Standard-Regeln würde ich z. B. von einer frischen W11 Installation nehmen und ausdünnen. Kann man ja einfach per Copy & Paste in eine GPO kopieren. Oder rollt es sich bei dem Gedanken einem die Fußzehnägel auf .

Den Task hätte ich per GPO verteilt. Meinst Du das Powershell-Script direkt bei der Anmeldung ausführen zu lassen? Läuft das nicht im Userkontext, der dann evtl. keine lokalen Adminrechte hat? Oder meinst Du die Regeln direkt wie gewünscht per GPO zu verteilen? Der Ansatz war deswegen so, weil ich erstens die IP Adressen sowieso in der Liste pflege die dann automatisch verwendet wird und zweitens ich mich nicht um die Default-Regeln kümmern muss die Windows gerne mal anlegt, weil es immer alle aktiven Regeln verändert. Bei der GPO Lösung bräuchte ich die Variante in der Art: mach alle vorhandenen Regeln platt und füge die lt. GPO hinzu. Außerdem müsste ich bei Änderung der IP Liste an zwei Stellen Änderungen vornehmen. Meinst Du es wäre besser den lokalen Merge der Regeln zu deaktivieren (das würde das Plattmachen erledigen) und die Regeln zentral per GPO auszurollen? Evtl. aufbauend auf den Regeln die mir eine frische Windows-Installation zeigt?

Guten Tag, ich weiß nicht, ob man das Mikrosegmentierung nennen kann. Hier haben wir uns schon mal darüber unterhalten: https://www.mcseboard.de/topic/227410-mikrosegmentierung-sollte-man-machen-oder-nicht/ Ich habe mir ein Powershellscript gebastelt, dass eine IP-Liste von einem Netzwerkpfad einliest und alle aktiven Firewall-Regeln durchgeht und diese IPs als Remote-Adressen einträgt, eingehend. Die Idee dahinter ist, dass ich die Kommunikation der Clients untereinander so einschränken will, dass diese nur von vordefinierten Clients Verbindungen annehmen. Das Script könnte man als Task immer wieder automatisch laufen lassen. Die Umgebung ist nicht so groß und die IP Liste gibt es sowieso schon (Ausnahme oder Reservierungen vom DHCP). Ist das sinnlos oder eine tief hängende Frucht?

MFA Fatigue: https://www.bleepingcomputer.com/news/security/mfa-fatigue-hackers-new-favorite-tactic-in-high-profile-breaches/ Sachen gibt’s.

Nutzt Ihr MFA von nicht vertrauenswürdigen Standorten?

Tatsächlich kenne ich die Karte im Microsoft-Authenticator nicht. Firmenname und Login, mehr sehe ich nicht und der Dialog ist auch modal, die App wartet mit der nächsten Meldung bis ich auf die aktuelle reagiert habe. Dann muss der Angreifer einen Zeitpunkt erwischen, zu dem ich mich anmelde und dann noch zufällig die Nummer stimmen. Spätestens bei der zweiten Abfrage wäre ich stutzig. Aber ich vergesse immer wieder, dass das ja Massenabfragen sind und nicht ein ganz bestimmter Account erobert werden soll, sondern „nur“ irgendwelche und irgendwer gibt dann 30x die gleiche Nummer in den Prompt ein und wundert sich, dass sein Login nicht geht. D. h. wir können nur die Leute sensibilisieren, dass alle Ungereimtheiten beim Login-Prozess gemeldet werden und Conditional-Access nutzen. Z. B., dass sich die Empfangsdame nur von vertrauenswürdigen Standorten aus anmelden darf. Kann man im Tenant eine Regel konfigurieren, dass man nach X Anmeldeversuchen Y Sekunden bis zur nächsten Eingabe warten muss? Ich finde nichts derartiges.

Hallo zusammen, ich frage mich, wie man die Aussage begründen kann, dass MFA das Durchprobieren nicht eliminieren kann? Die reine Meldung, die man nur bestätigen konnte (im Authenticator), auch versehentlich, gibt es ja nur noch in Verbindung mit dem RDS-Gateway. https://www.heise.de/news/Grossflaechige-Brute-Force-Angriffe-auf-M365-vorsichtshalber-Log-ins-checken-10252167.html Grüße und noch einen schönen Nachmittag

Vielleicht läuft es auf das klassische „es kommt darauf an“ raus. Ich habe eine kleine unabhängige Cloudumgebung. Die hat einen Jumphost. Der ist per RDP von einer meiner IPs erreichbar. Vom internen Netzwerk aus dürfen wiederum nur 3 VMs auf diese externe IP zugreifen. Der Jumphost hat nicht das Standardzertifikat. Um die Paranoia zu streicheln ist noch das mit der FIPS Verschlüsselung aktiv. Aber Du hast mit Sicherheit recht, wenn man sagt, dass es pauschal zu unterlassen ist, außer man hat ein paar gute Gründe es trotzdem zu tun. Ich hoffe meine sind gut genug :-).

Da würde ich gerne einhaken. Warum sollte ich den Zugriff auf einen RDP-Port (3389) nicht aus einem von mir kontrolliertem Netzwerk, über das Internet, erlauben. Letztendlich macht es doch dann keinen Unterschied, ob ich das auch lokal mache.

Jetzt wird es hell. Der Default Security Descriptor .

Ich glaube ich würde es verstehen, wenn ich wüsste was der DefaultSD ist .