20
Applocker funktioniert nicht sauber
Moin zusammen ,
ich teste gerade Applocker bei uns aus (verteilt per GPO).
Meine Testclients sind vollständig gepatchte Windows 10 & 11 Prof. PCs.
Derzeitige GPO Konfig:
Ergo habe ich "nur" alle ".exe" Files aus dem Download Ordner verweigert.
Am Anfang funktioniert es, ganz normal ohne Probleme.
Nach einer Weile funktioniert es bei mir aus irgendwelchen Gründen nicht mehr.
Im Ereignisprotokoll steht dann:
"*<Dateiname> * darf ausgeführt werden, wäre aber an der Ausführung gehindert worden, wenn die AppLocker-Richtlinie erzwungen wurde."
Und die Regeln sind definitiv NICHT auf den Auditmode eingestellt.
Es gibt sonst NICHTS mit Applocker in unserer Infrastruktur.
Hat jemand eine Idee?
Danke.
ich teste gerade Applocker bei uns aus (verteilt per GPO).
Meine Testclients sind vollständig gepatchte Windows 10 & 11 Prof. PCs.
Derzeitige GPO Konfig:
Am Anfang funktioniert es, ganz normal ohne Probleme.
Nach einer Weile funktioniert es bei mir aus irgendwelchen Gründen nicht mehr.
Im Ereignisprotokoll steht dann:
"*<Dateiname> * darf ausgeführt werden, wäre aber an der Ausführung gehindert worden, wenn die AppLocker-Richtlinie erzwungen wurde."
Und die Regeln sind definitiv NICHT auf den Auditmode eingestellt.
Es gibt sonst NICHTS mit Applocker in unserer Infrastruktur.
Hat jemand eine Idee?
Danke.
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 42885422022
Url: https://administrator.de/contentid/42885422022
Ausgedruckt am: 22.11.2024 um 06:11 Uhr
20 Kommentare
Neuester Kommentar
Moin.
Mach am Client ein elevated command prompt auf und starte
Steht da wirklich nichts von Audit mode?
Mach am Client ein elevated command prompt auf und starte
gpresult /h %temp%\resultat.html & %temp%\resultat.html
in den GPO Settings:
(nochmal, es funktioniert es und nach einer Zeit hört es einfach auf und geht in Audit mode...)
sobald ich den lokalen GPO Cache leere und gpudpdate mache , funktioniert es erstmal wiedr.
Nach einer Weile,funktioniert es wieder nicht
Ganz kurios.
Evtl. anders gefragt:
Wie hast du es konfiguriert? Wie lässt du den Dienst starten?
Mein Verdacht:
Dadurch dass ich über die selbe GPO auch den Dienstag starte, s.o., und alle X Minuten die GPO angewendet wird und somit der Dienst evtl. einen Neustart im Hintergrund hinnehmen muss, dass es ab dann nicht funktioniert?
(nochmal, es funktioniert es und nach einer Zeit hört es einfach auf und geht in Audit mode...)
Nach einer Weile,funktioniert es wieder nicht
Ganz kurios.
Evtl. anders gefragt:
Wie hast du es konfiguriert? Wie lässt du den Dienst starten?
Mein Verdacht:
Dadurch dass ich über die selbe GPO auch den Dienstag starte, s.o., und alle X Minuten die GPO angewendet wird und somit der Dienst evtl. einen Neustart im Hintergrund hinnehmen muss, dass es ab dann nicht funktioniert?
Der Dienst wird nicht über die GPO gestartet, auch nicht neu gestartet. Du legst per GPO nur dessen Startart fest.
Kannst Du bitte im Fehlerzustand das resultat.html anschauen?
Ich habe wie du die Startart des Dienstes in der selben GPO wie die Applockerregeln festgelegt.
Kenne dieses Fehlverhalten leider noch nicht.
Kannst Du bitte im Fehlerzustand das resultat.html anschauen?
Ich habe wie du die Startart des Dienstes in der selben GPO wie die Applockerregeln festgelegt.
Kenne dieses Fehlverhalten leider noch nicht.
Hab mal alles neu gemacht, die einzige Regel zum Verweigern lautet:
%OSDRIVE%\USERS\%SUERPROFILE%\DOWNLOADS\*.exe
ABER es wird auch folgendes blockiert:
Ist mein "Parameter" falsch? Die EXE Files unter Downloads werden übrigens auch blockiert.
%OSDRIVE%\USERS\%SUERPROFILE%\DOWNLOADS\*.exe
ABER es wird auch folgendes blockiert:
%userprofile% löst auf zu c:\users\benutzername, also solltest Du %userprofile%\downloads\*.exe verwenden.
Zitat von @DerWoWusste:
%userprofile% löst auf zu c:\users\benutzername, also solltest Du %userprofile%\downloads\*.exe verwenden.
%userprofile% löst auf zu c:\users\benutzername, also solltest Du %userprofile%\downloads\*.exe verwenden.
hab ich nun mal gemacht:
btw - machst du einen whitelist Ansatz (wäre cooler, aber aufwendiger) oder blacklist wie bei mir?
edit:
leider das gleiche Problem. Gesperrt habe ich, wie oben zu sehen, alle .EXE unter Downloads.
Testweise habe ich was unter Bilder abgelegt, wird blockiert.
die angekommene GPO am Client:
echt merkwürdig, verstehe es nicht...
Mach es mal so, wie ich es schrieb. NICHT c:\users\%userprofile%\downl..., sondern %userprofile%\downloads
Zitat von @DerWoWusste:
Mach es mal so, wie ich es schrieb. NICHT c:\users\%userprofile%\downl..., sondern %userprofile%\downloads
Mach es mal so, wie ich es schrieb. NICHT c:\users\%userprofile%\downl..., sondern %userprofile%\downloads
das gleiche Problem..
Siehe (geblockt sollte %userprofile%\downloads\*.exe => blockiert wird aber mehr)
Darf ich mal raten? Du hast nicht den Pfad, sondern nur den Namen der Regel modifiziert?
1Zitat von @DerWoWusste:
Darf ich mal raten? Du hast nicht den Pfad, sondern nur den Namen der Regel modifiziert?
Darf ich mal raten? Du hast nicht den Pfad, sondern nur den Namen der Regel modifiziert?
du hast (mal wieder) Recht.
Danke.Aber:
Ich kann den Pfad so nicht unter "Pfad eintragen" =>
Ich kann den Pfad so nicht unter "Pfad eintragen"
Stimmt, Applocker kennt nur wenige Variablen, siehe https://learn.microsoft.com/en-us/windows/security/application-security/ ...Dann nutze %osdrive%\users\*\downloads\*.exe
leider wieder das gleiche Problem..
Die GPO am Client ist korrekt angekommen.
Die GPO am Client ist korrekt angekommen.
Schau in der registry nach, ob am Client die richtigen Pfade eingetragen sind, oder nicht:
HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\SrpV2\Exe
HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\SrpV2\Exe
Zitat von @DerWoWusste:
Schau in der registry nach, ob am Client die richtigen Pfade eingetragen sind, oder nicht:
HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\SrpV2\Exe
Schau in der registry nach, ob am Client die richtigen Pfade eingetragen sind, oder nicht:
HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\SrpV2\Exe
ja ist eingetragen.
Und das ist der einzige Eintrag? Wenn ja, vielleicht mal den Client neu starten?
ne, habe nur das relevante gesendet. aber hier die vollständigen:
Ok, dann ist doch klar, was Sache ist. Du hast den Ordner c:\users noch gar nicht freigegeben für Ausführung von exe. Per Default ist alles dicht! Was Du gesetzt hast, sind nur die Standardregeln, die unterhalb von c:\windows sowie im Programmverzeichnis alles erlauben.
PS: Vorsicht mit c:\windows. Darunter gibt es ein paar Verzeichnisse, die der Nutzer beschreiben kann, zum Beispiel das c:\windows\temp. Kopiert er also Dinge dorthin, kann er sie plötzlich ausführen. Alle beschreibbaren orte sollten geblockt werden; die Standardregeln nennt Microsoft selbst "unsicher".
PS: Vorsicht mit c:\windows. Darunter gibt es ein paar Verzeichnisse, die der Nutzer beschreiben kann, zum Beispiel das c:\windows\temp. Kopiert er also Dinge dorthin, kann er sie plötzlich ausführen. Alle beschreibbaren orte sollten geblockt werden; die Standardregeln nennt Microsoft selbst "unsicher".
1Zitat von @DerWoWusste:
Ok, dann ist doch klar, was Sache ist. Du hast den Ordner c:\users noch gar nicht freigegeben für Ausführung von exe. Per Default ist alles dicht! Was Du gesetzt hast, sind nur die Standardregeln, die unterhalb von c:\windows sowie im Programmverzeichnis alles erlauben.
PS: Vorsicht mit c:\windows. Darunter gibt es ein paar Verzeichnisse, die der Nutzer beschreiben kann, zum Beispiel das c:\windows\temp. Kopiert er also Dinge dorthin, kann er sie plötzlich ausführen. Alle beschreibbaren orte sollten geblockt werden; die Standardregeln nennt Microsoft selbst "unsicher".
Ok, dann ist doch klar, was Sache ist. Du hast den Ordner c:\users noch gar nicht freigegeben für Ausführung von exe. Per Default ist alles dicht! Was Du gesetzt hast, sind nur die Standardregeln, die unterhalb von c:\windows sowie im Programmverzeichnis alles erlauben.
PS: Vorsicht mit c:\windows. Darunter gibt es ein paar Verzeichnisse, die der Nutzer beschreiben kann, zum Beispiel das c:\windows\temp. Kopiert er also Dinge dorthin, kann er sie plötzlich ausführen. Alle beschreibbaren orte sollten geblockt werden; die Standardregeln nennt Microsoft selbst "unsicher".
tatsächlich. Mir war bis eben nicht bewusst, dass MS Applocker den Whitelist Ansatz fährt. Danke!!!
(ich habe jetzt %OSDRIVE%\users\ alles erlaubt).
nun wird nur die EXE unter Downloads verboten, alle anderen Pfade mit exe gehen! Danke!!!!
Könntest du mir evtl. paar Standardpfade geben, welche ihr auch im Einsatz habt? (zB das was du oben bereits sagtest).
Danke, DerWoWusste..
Könntest du mir evtl. paar Standardpfade geben, welche ihr auch im Einsatz habt?
Dazu solltest Du besser deine Systeme auf beschreibbare Ordner untersuchen, und zwar so: lade dir von Microsoft accesschk runter und und mach damit auf einer elevated shell malaccesschk.exe VORDEFINIERT\Benutzer c:\Windows\ -w -saccesschk.exe BUILTIN\Users c:\Windows\ -w -sDas Selbe sicherheitshalber auch für "c:\program files" bzw. "c:\program files (x86)" ausführen.
Siehe dazu auch: Application Whitelisting - Umgang mit Systemdateien
Edit: als Pfad bitte für die Programme
bzw.
nutzen, da accesschk bei Leerzeichen im Pfad andernfalls abspackt.
accesschk.exe VORDEFINIERT\Benutzer "%ProgramFiles%" -w -s accesschk.exe VORDEFINIERT\Benutzer "%ProgramFiles(x86)%" -w -s 
