Moment, die IT-Richtlinien Ihres Unternehmens hindern Sie daran, Ihre Arbeit zu erledigen?
@Greg: Es schmerzt mich zu sehen, wie diese Mentalität unter dem Deckmantel einer technischen Antwort aufrechterhalten wird. Wir sollten die Zusammenarbeit mit Ihrem Systemadministrator fördern, nicht gegen ihn arbeiten. Höchstwahrscheinlich ist dies lediglich das Ergebnis einer Standardeinstellung in Kaspersky, kombiniert mit einer etwas ungewöhnlichen Praxis von Visual Studio, und da der Systemadministrator nun Bescheid weiß, versucht er, eine praktikable Lösung zu finden.
Wenn Ihr Systemadministrator jedoch nicht aktiv nach einer alternativen Lösung sucht, dann macht er seine Arbeit nicht richtig. Das ist ein meldepflichtiges Problem. Natürlich spielt die Politik Ihres Büros eine große Rolle dabei, wer in einem Streit zwischen Entwicklern und Systemadministratoren gewinnt - sogar einige Vorgesetzte geraten in Panik, wenn der Systemadministrator die Karte "Unternehmenssicherheit" ausspielt!
Als Systemadministrator ist es mir auch unangenehm, willkürlich zuzulassen, dass *.tmp.exec.cmd auszuführende Dateien nicht angekreuzt -- Local Settings\Temp ist überraschend einfach von vielen Orten aus anzuschreiben und bietet eine Vielzahl von ( bekannte Software einfügen ) ausnutzen, kann die Ausführung ermöglichen.
Allerdings habe ich als Entwickler vor kurzem das gleiche Problem erlebt und würde gerne eine Lösung finden.
Mit beiden Hüten auf dem Kopf (und ein bisschen Googeln) schaue ich mir also die Kaspersky-Richtlinien/Ereignisse in Bezug auf unsere Client-Rechner an und kann feststellen, dass die Build-Ereignis-Batch-Dateien die Input/Output redirection Regel im Application Activity Analyser. Ich vermute also, dass es ein Problem mit der Art und Weise ist, wie Visual Studio die Ausgabe von Ihren Build-Ereignissen erfasst.
Ein Großteil der folgenden Ausführungen wird ein Brain-Dump der Dinge sein, die ich versucht habe, um dieses Problem zu umgehen, mit unterschiedlichem Erfolg. Ich führe auch CruiseControl.NET auf ein paar separaten Build-Maschinen (das ist, wo ich zum ersten Mal das Problem bemerkt), so werde ich auf eine Tangente zu brechen, um diese zu decken.
Ich glaube, dass ein kürzlich durchgeführtes Kaspersky-Update die Standardaktion von Zulassen/Auffordern auf Quarantäne geändert hat, oder dass die Definitionen für dieses Problem jetzt übereifrig sind.
Die Kaspersky-Dokumentation ist (bestenfalls) etwas dürftig, vor allem in Bezug auf die Komponente Proaktiver Schutz und darauf, worauf sie eigentlich überprüft wird.
Neben dem bereits erwähnten Ausschluss von Platzhaltern sehe ich vier mögliche Lösungen für dieses Problem:
- Ändern der AAA-Einstellungen in Kaspersky, um die I/O-Umleitung als prompte Aktivität zuzulassen
- Fügen Sie die Ausschlussregel für
*.tmp.exec.cmd sondern nur darauf beschränken, dass sie nicht der Komponente Proaktive Verteidigung für den Bedrohungstyp unterliegen RootShell
- Deaktivieren der Prüfung auf E/A-Umleitung
- Hinzufügen eines Ausschlusses der "vertrauenswürdigen Zone" für
%WINDIR%\Microsoft.NET\Framework\*\MSBuild.exe (und Framework64) mit Do not restrict application activity
Option Nr. 1 könnte ausreichend sein, da sie dem Endbenutzer die Kontrolle überlässt (wenn er als zuverlässig genug angesehen wird, um die Entscheidung zu treffen), kann aber den CC.NET-Erstellungsprozess blockieren, während er auf eine Antwort wartet.
Option 2 könnte einen ausreichenden Vorteil bieten, so dass der Systemadministrator eher bereit ist, die Regel aufzunehmen. Möglicherweise können Sie die Regel auch mit dem temporären Pfad qualifizieren, z. B. %TEMP%\*.tmp.exec.cmd um die Bedenken weiter zu verringern. Für die Dienstsitzung scheinen die Umgebungsvariablen jedoch nicht geladen zu werden (zumindest scheint die Regel nicht ausgelöst zu werden), so dass Sie dies umgehen müssen, indem Sie CC.NET unter einem bekannten Domänendienstkonto ausführen und eine weitere Regel hinzufügen, die den temporären Speicherort ausdrücklich angibt.
Option Nr. 3 riecht genauso stark wie die Wildcard-Ausnahme, wenn nicht noch schlimmer. Aber ist die E/A-Umleitung wirklich so eine große Sache? Sollte die Möglichkeit, die Ausgabe eines Prozesses an einen anderen weiterzuleiten, so streng kontrolliert werden? Kaspersky scheint das zu glauben, aber ich bin mir da nicht so sicher. Sicherlich wären viele Automatisierungs-/Scheduler-ähnliche Anwendungen davon nachteilig betroffen?
Als Systemadministrator bevorzuge ich die Option Nr. 4. Wenn ich die richtige Kombination von Einstellungen finden kann, so dass MSBuild seine Arbeit machen kann, aber alles andere trotzdem abgedeckt ist, muss das doch der richtige Weg sein, oder?
Leider nicht, denn der Prozess MSBuild.exe erzeugt einen Prozess cmd.exe, der die *.tmp.exec.cmd Dateien, und Kaspersky prüft die Datei im Kontext des Prozesses cmd.exe. Das bedeutet, dass die Regel für vertrauenswürdige Anwendungen für cmd.exe definiert werden muss, mit Do not control application activity . Dies scheint schlimmer zu sein als der Platzhalterausschluss für *.tmp.exec.cmd denn das würde bedeuten, dass alle Batchdateien vom Test ausgeschlossen werden, und nicht nur die Teilmenge.
Ich komme also auf eine Kombination der Optionen 1 und 2 zurück. Ich füge Ausschlussregeln hinzu für %TEMP%\*.tmp.Exec.cmd , %USERPROFILE%\Local Settings\Temp\*.tmp.Exec.cmd y %USERPROFILE%\AppData\Local\Temp\*.tmp.Exec.cmd (wenn %TEMP% nicht definiert ist, wird die %USERPROFILE% -basierten Pfad sollte unter XP bzw. W7 zum Ziel führen). Ich ändere auch die Standardaktion für I/O redirection à Prompt Wenn es sich also um eine übermäßig aggressive neue Regel/Definition handelt, können alle anderen Programme, die davon betroffen sein könnten, explizit von meinen Endbenutzern kontrolliert werden (oder zumindest könnte es sie so erschrecken, dass sie mich danach fragen).
Was CC.NET anbelangt, so gibt es zwei Möglichkeiten: Entweder installiere ich CC.NET auf aktuellen Servern, auf denen Kaspersky Server Edition läuft (das das AAA-Modul nicht enthält), oder ich installiere CC.NET absichtlich auf einer Workstation (z. B. wenn ich mit Hilfe von Unit-Tests usw. automatisch prüfen möchte, ob meine Anwendung unter W2K/WXP/W7 funktioniert) und konfiguriere den CC.NET-Dienst so, dass er unter meinem dedizierten Domänenkonto läuft, svc-ccnet und fügen Sie dann feste Ausschlussregeln zu unserer Kaspersky-Richtlinie für C:\Documents and Settings\svc-ccnet\Local Settings\Temp\*.tmp.Exec.cmd y C:\Users\svc-ccnet\AppData\Local\Temp\*.tmp.Exec.cmd mit einem Bedrohungstyp von RootShell und die Komponente auf Proactive Defense . Auf Drängen könnte ich die CC.NET-Geräte zu einer anderen KAV-Gruppe hinzufügen, wodurch die AAA-Beschränkung gelockert wird.
Ich hoffe, das hilft (eigentlich hoffe ich, dass jemand kommt und sagt: "Sie haben etwas ganz Einfaches übersehen" und dann erklärt, was das ist!!).
TL;DR-Version: Ich habe in KAV folgende Möglichkeiten gefunden, um diese Auswirkungen zu verhindern oder zu verringern. Bitten Sie Ihren Systemadministrator, die Option zu wählen, mit der er sich am wohlsten fühlt:
- Setzen Sie die Aktion für die E/A-Umleitung in den Einstellungen des Application Activity Analyzer der Richtlinie auf Zulassen oder Auffordern
- Deaktivieren Sie die Option E/A-Umleitung in den Einstellungen des Application Activity Analyzer der Richtlinie
- hinzufügen
%COMSPEC% zur Liste der vertrauenswürdigen Anwendungen der Richtlinie hinzufügen, indem Sie die Option "Anwendungsaktivität nicht kontrollieren" aktivieren.
- hinzufügen
%TEMP%\*.tmp.exec.cmd zu den Ausschlussregeln der Richtlinie, unter Verwendung des Bedrohungstyps RootShell und die Komponente Proactive Defense
Ich bevorzuge die Nummer 4; andere mögen davon abweichen.
