bvdo

FYI: leider nein. 11.7 installiert, Edge Update initiiert und: Ereignis: Der Selbstschutz hat eine Aktion mit Ressourcen des Programms blockiert Programmname: MicrosoftEdgeUpdate.exe Programmpfad: C:\Program Files (x86)\Microsoft\EdgeUpdate Programm-PID: 5788 Programmfunktion: Öffnen eines Prozesses Objekt: C:\Program Files (x86)\Kaspersky Lab\Kaspersky Endpoint Security for Windows\avpui.exe Benutzername: NT-AUTORITÄT\SYSTEM Benutzertyp: Nicht definiert Komponente: Schutz

Moin, wir sind in der Tat noch auf 11.4. Ich interpretiere Deine Antwort jetzt also als “vermutlich Fehlalarm” und teste mal die 11.7, danke für den Hinweis. Gruß aus DO

Guten Morgen allerseits! Uns fallen in den lokalen Kaspersky-Logs diverse Einträge auf der Form Programm: Microsoft Edge Update Aktion: Beenden eines Prozesses Objekt: C:\Program Files (x86)\Kaspersky Lab\Kaspersky Endpoint Security for Windows\avp.exe Ergebnis: Verboten Benutzer: *** Komponente: Schutz Edge ist dabei ein Beispiel, aber auch Google Chrome Update oder Adobe Genuine Software Service generieren ähnliche Einträge. Wenn ich die Einträge richtig lese, versuchen diese Programme also avp.exe zu beenden. Insofern wäre es natürlich nur folgerichtig, wenn der Selbstschutz dies unterbindet. Irritierenderweise finde ich im Web keine Hinweise dazu, wieso eigentlich diese Prozesse versuchen, Kaspersky-Prozesse zu beenden (oder ich bin zu doof zum suchen?). Auch im Security-Log von Windows finde ich da nichts bzgl Process Creation/Termination, die wir protokollieren. Ich würde diese Ereignisse gerne besser verstehen, hat jemand hier im Forum schon einmal genauer diesbezüglich nachgeforscht und kann mich in die richtige Richtung schubsen? Interessierte Grüße aus Dortmund

Hmm, gerade einen anderen Test unternommen: das Öffnen des Schlosses bei wirkt sich für die Objekttypen Trojaner, Viren und Würmer augenscheinlich gar nicht auf das aus, was der Revisionsverlauf der Richtlinie (und in der Folge dann wohl auch der Richtlinienvergleich) “sehen”: Revisionsverlauf: Richtlinienvergleich: ???

Nein, beide Richtlinien sind jeweils in der Gruppe definiert, in der sie gültig sind. Die unterschiedlichen Vererbungseinstellungen dürften historisch bedingt sein, da die Richtlinien aus unterschiedlichen früheren KSC-Versionen konvertiert sind. Diese Konvertierung mag dann natürlich auch Unterschiede zwischen den Richtlinien erklären, an denen sich mit der Version eventuell Defaults geändert haben, z.B. bei Benachrichtigungsoptionen. Es erklärt jedoch m. E. nicht die Unterschiede in obigem Screenshot, die ja Einstellungen im Ergebnis des Richtlinienvergleichs anders darstellen als in der GUI zur Konfiguration der Richtlinie. Nicht sonderlich vertrauenerweckend, finde ich… Was das Update angeht: ja, das kann ich natürlich demnächst machen, verspreche mir allerdings nicht sonderlich viel davon. Immerhin dürfte die Funktionalität des Richtlinienvergleichs ja relativ statisch sein und in den Change Logs ist mir auch nichts diesbezüglich aufgefallen.

Guten Tag allerseits! Wir haben verschiedene Richtlinien für Admins und für Standardclients. Wenn ich diese beiden im Security Center miteinander vergleiche (Kontextmenü → Richtlinie mit anderer Richtlinie vergleichen) erhalte ich im Block “Abweichende Einstellungen” Unterschiede, die ich in der Konfiguration der beiden Richtlinien nicht wiederfinde. Es handelt sich um den Bereich “Allgemeine Einstellungen” → “Ausnahmen” → “Typen des erkannten Objekts”. Laut Richtlinienvergleich sind hier in der einen Richtlinie Änderungen erlaubt und in der anderen nicht, siehe Screenshot: In der Konfiguration jedoch sind in beiden Richtlinien die “Vorhängeschlösser” geschlossen und Änderungen somit nicht erlaubt. Es handelt sich um KSC 13.0.0.11247 mit Verwaltungsplugin 11.6.0. Ist eine vergleichbare Inkonsistenz schon mal jemandem aufgefallen? Welche der beiden Informationen ist die korrekte? Wenn ich eine längere Liste von Abweichungen habe, würde ich mich gerne auf die Ergebnisse des Richtlinienvergleichs verlassen können. Im Moment habe ich da einige Zweifel. Ich freue mich über Kommentare, beste Grüße aus Dortmund

Guten Morgen! Wir hatten hier ein ähnliches Problem, das m.E. im Zusammenhang mit dem OpenSSL-Patch für den netagent 13.0.0.11247 ( CVE-2021-3450 vermute ich mal?) steht. Dieser Patch wurde am 12.5. automatisch auf den KES-Clients installiert, nicht jedoch auf dem KSC. Daraufhin meinte das KSC, unsere sämtlichen Clients als nicht mehr lizenziert ansehen zu müssen. Clients wurden dann automatisch neu gefunden und in “nicht zugeordnete” Geräte gelistet, jeder Client wurde somit zweimal mit gleichem Namen gefunden. Daraufhin habe ich die alten Objekte aus unseren Gruppen gelöscht und die neu gefundenen Objekte in die Gruppen verschoben. Die Aufgabe zur erneuten Verteilung des Lizenzschlüssels auf diese neu gefundenen Clients wurde auf dem KSC dann zwar als “erfolgreich abgeschlossen” gemeldet, änderte jedoch nichts am Zustand der Clients. Rollback der KES-Version (11.4.0.233 → 11.1.1.126): Schlüssel liess sich wieder installieren. (Edit: nur KES zurückgefahren, netagent blieb dabei auf 13.0.0.11247) Anschliessendes erneutes Upgrade auf 11.4.0.233 funktionierte, Clients “bleiben” lizenziert. Status derzeit: der Patch ist für das KSC nach wie vor nicht installiert, obwohl er unter “Erweitert” → “Programmverwaltung” → “Software-Updates” auf “genehmigt” gesetzt ist. Fragen: führt die Nichtinstallation auf dem KSC womöglich dazu, dass wir dasselbe Problem bald wieder bekommen (Kommunikation der netagents auf Clients und KSC eventuell gestört wegen verschiedener Patch Level OpenSSL)? wie kann ich den Patch auf dem KSC ggfs manuell installieren? Google bzw. die Kaspersky-Websites haben irgendwie wenig konkretes zu dem Patch oder ich bin zu blöd zum suchen…Grüße Christian