Freigeben über

Antivirenoptimierung für Windows-Container

Die Informationen auf dieser Seite gelten für:

  • Windows 10, Versionen 1607 und höher
  • Windows Server 2016 und höhere Versionen
  • Antivirenprodukte (AV), die auf dem Host ausgeführt werden

In diesem Thema werden Optimierungen beschrieben, die AV-Produkte verwenden können, um redundante Überprüfungen von Windows-Containerdateien zu vermeiden und die Containerstartzeit zu verbessern.

Containerübersicht

Das Windows-Containerfeature wurde entwickelt, um die Verteilung und Bereitstellung von Anwendungen zu vereinfachen. Weitere Informationen finden Sie in der Einführung zu Windows-Containern.

Container werden aus einer beliebigen Anzahl von Paketebenen erstellt. Das Windows-Basisbetriebssystempaket bildet die erste Ebene.

Jeder Container verfügt über ein isoliertes Volume, das das Systemvolume für diesen Container darstellt. Ein Containerisolationsfilter (wcifs.sys) stellt eine virtuelle Überlagerung von Paketebenen auf dieses Containervolume bereit. Die Überlagerung wird mithilfe von Platzhaltern (Analysepunkte) erreicht. Das Volume wird mit Platzhaltern versehen, bevor der Container zuerst auf den übergeordneten Pfad zugreift. Lesevorgänge von Platzhalterdateien werden an die Sicherungspaketdatei weitergeleitet. Auf diese Weise können mehrere Containervolumes auf denselben zugrunde liegenden Paketdateidatenstrom zugreifen.

Wenn ein Container eine Datei ändert, führt der Isolationsfilter das Kopieren beim Schreiben durch und ersetzt den Platzhalter durch den Inhalt der Paketdatei. Dadurch wird die "Verknüpfung" mit der Paketdatei für diesen bestimmten Container unterbrochen.

Leseumleitung

Lesevorgänge aus einer Platzhalterdatei werden vom Isolationsfilter auf die entsprechende Paketebene umgeleitet. Die Umleitung erfolgt auf Filterebene. Da sich der Filter unterhalb des AV-Bereichs befindet, sehen AV-Filter die Leseumleitung nicht. AV wird auch nicht sehen, dass das Öffnen von Paketdateien ausgeführt wird, um die Umleitung einzurichten.

Ein AV-Filter verfügt über eine vollständige Ansicht aller Vorgänge auf dem Containersystemvolume. Es werden Vorgänge für Platzhalterdateien sowie Dateiänderungen oder neue Dateizusätze angezeigt.

Problem mit redundanter Überprüfung

Abhängig von den gleichen Paketebenen werden wahrscheinlich viele Container vorhanden sein. Derselbe Datenstrom einer bestimmten Paketdatei stellt die Daten für Platzhalter auf mehreren Containersystemvolumes bereit. Daher besteht das Potenzial für redundante AV-Scans derselben Daten in jedem Container. Dies hat unnötige negative Auswirkungen auf die Leistung von Containern. Dies ist eine Signifikationskosten, da davon ausgegangen wird, dass Container schnell gestartet werden und möglicherweise kurzlebig sind.

Um redundante Überprüfungen für Container zu vermeiden, wird empfohlen, das Verhalten eines AV-Produkts wie unten beschrieben zu ändern. Es liegt beim AV-Produkt, den Risiko-/Ertragsvorteil für seine Kunden für diesen Ansatz zu bestimmen. Weitere Informationen hierzu finden Sie im Abschnitt Vorteile und Risiken unten auf dieser Seite.

1. Paketinstallation

Während der Paketinstallation legen die Verwaltungstools Dateien im Paket unter dem Ebenenstamm an. Der AV-Filter sollte die Dateien weiterhin überprüfen, während sie im Paketstamm platziert werden und dies normalerweise wäre. Dadurch wird sichergestellt, dass alle Dateien in den Ebenen zunächst in Bezug auf Schadsoftware sauber werden.

2. Containerstart und -ausführung

Für die Echtzeitüberprüfung eines Containervolumes sollten AVs so scannen, dass Redundanz vermieden wird. Platzhalterdateien müssen besonders berücksichtigt werden. Dateien, die durch den Container geändert wurden, oder neue Dateien, die im Container erstellt wurden, werden nicht umgeleitet, sodass redundante Überprüfungen kein Problem darstellen.

Um redundante Scans zu vermeiden, muss der AV-Filter zunächst Containervolumes und Platzhalter auf diesen Volumes identifizieren. Aus verschiedenen Gründen gibt es keine direkte Möglichkeit für einen AV-Filter, abzufragen, ob ein Volume ein Containervolume ist oder ob eine bestimmte Datei eine Platzhalterdatei ist. Der Isolationsfilter blendet den Platzhalterreparsepunkt aus Anwendungskompatibilitätsgründen aus (einige Anwendungen verhalten sich nicht ordnungsgemäß, wenn sie wissen, dass sie auf Analysepunkte zugreifen). Außerdem ist ein Volume nur ein Containervolume, während ein Container ausgeführt wird. Der Container wird möglicherweise beendet, und das Volume bleibt möglicherweise erneut bereitgestellt. Stattdessen muss der AV-Filter beim Voraberstellung das Dateiobjekt abfragen, um zu bestimmen, ob es im Kontext eines Containers geöffnet wird. Anschließend kann er den Platzhalterstatus anfügen und ecp anfügen und empfangen, wenn die Erstellung abgeschlossen ist.

Die folgenden Änderungen sind im AV-Produkt erforderlich:

  • Fügen Sie während der Voraberstellung auf einem Containervolume ein ECP an das Create CallbackData (CallbackData erstellen) an, das die Platzhalterinformationen empfängt. Diese Erstellungen können durch Abfragen der SILO-Parameter aus dem Dateiobjekt mithilfe von IoGetSiloParameters identifiziert werden. Beachten Sie, dass der Filter die Größe in der WCIFS_REDIRECTION_ECP_CONTEXT-Struktur angeben muss. Alle anderen Felder sind out-Felder, die festgelegt sind, wenn das ECP bestätigt wird.

  • Untersuchen Sie beim Erstellen nach dem Erstellen die ECP-Umleitungsflags, wenn der ECP bestätigt wird. Die Flags geben an, ob das geöffnete von der Paketebene oder vom Grundstamm (neue oder geänderte Dateien) gewartet wurde. Flags geben auch an, ob die Paketebene registriert ist und ob sie remote ist.

    • Bei Geöffneten, die von einer Remoteebene aus gewartet werden, sollte AV die Überprüfung der Datei überspringen. Dies wird durch die Umleitungsflags angegeben: WCIFS_REDIRECTION_FLAGS_CREATE_SERVICED_FROM_LAYER && WCIFS_REDIRECTION_FLAGS_CREATE_SERVICED_FROM_REMOTE_LAYER

      Es kann davon ausgegangen werden, dass Remoteebenen auf dem Remotehost gescannt wurden. Hyper-V-Containerpakete sind remote für die Hilfsprogramm-VM, die den Container hostet. Diese Pakete werden normal auf dem Hyper-V-Host überprüft, wenn die Hilfsprogramm-VM über den SMB-Loopback darauf zugreift.

      Da VolumeGUID und FileId nicht auf remote angewendet werden, werden diese Felder nicht festgelegt.

    • Bei Geöffneten, die von einer registrierten Ebene aus bedient werden, sollte AV die Überprüfung der Datei überspringen. Dies wird durch die Umleitungsflags angegeben: WCIFS_REDIRECTION_FLAGS_CREATE_SERVICED_FROM_LAYER && WCIFS_REDIRECTION_FLAGS_CREATE_SERVICED_FROM_REGISTERED_LAYER

      Die registrierte Ebene sollte während der Paketinstallation und nach dem Signaturupdate asynchron überprüft werden.

      Hinweis

      Registrierte Ebenen können vom System in Zukunft möglicherweise nicht mehr identifiziert werden. In diesem Fall müssen Dateien auf lokaler Ebene einzeln identifiziert werden, wie im letzten Aufzählungszeichen beschrieben.

    • Bei Geöffneten, die von einer lokalen Paketebene aus bedient werden, sollte AV die bereitgestellte VolumeGUID und FileId der Ebenendatei verwenden, um zu bestimmen, ob die Datei gescannt werden muss. Dies erfordert wahrscheinlich, dass AV einen Cache mit gescannten Dateien erstellt, die nach Volume-GUID und FileId indiziert sind. Dies wird durch das Umleitungsflag angegeben: WCIFS_REDIRECTION_FLAGS_CREATE_SERVICED_FROM_LAYER

    • Bei neuen/geänderten Dateien im Scratchspeicherort sollte das AV-Produkt die Dateien überprüfen und die normale Korrektur durchführen. Dies wird durch das Umleitungsflag angegeben: WCIFS_REDIRECTION_FLAGS_CREATE_SERVICED_FROM_SCRATCH

      Da in diesem Fall keine Ebenendatei vorhanden ist, werden VolumeGUID und FileId nicht festgelegt.

    • Speichern Sie "Diese Datei wird von der Ebene aus gewartet" nicht als permanenter Marker im Streamkontext. Eine Datei, die ursprünglich über den Ebenenstamm gewartet wird, kann nach der Erstellung geändert werden. In diesem Fall kann eine nachfolgende Erstellung für dieselbe Datei darauf hinweisen, dass die Erstellung vom Containervolume aus gewartet wird. Der AV-Filter muss verstehen, dass dies passieren kann.

Verwenden Sie nicht den LayerRootLocations-Registrierungsschlüssel

In der Vergangenheit wurde empfohlen, den LayerRootLocations Registrierungsschlüssel zu verwenden, um den Speicherort des Basisimages abzurufen. AV-Produkte sollten diesen Registrierungsschlüssel nicht mehr verwenden. Verwenden Sie stattdessen den in diesem Thema empfohlenen Ansatz, um redundante Überprüfungen zu vermeiden.

Der Registrierungsspeicherort, der zum Registrieren von Paketebenen verwendet wurde:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Virtualization\LayerRootLocations

Nutzen und Risiken

Berücksichtigen Sie die folgenden Vorteile und Risiken bei der Verwendung dieser neuen Optimierungen für AV-Produkte.

Vorteile

  • Keine Auswirkungen auf die Start- oder Ausführungszeit des Containers (auch nicht für den ersten Container).
  • Vermeidet das Scannen desselben Inhalts in mehreren Containern.
  • Funktioniert für Windows Server-Container. Für Hyper-V Container funktioniert dies für die Pakete, erfordert jedoch zusätzlichen Aufwand für die Ausführung von Container.

Risiken

Wenn ein Container in der Zeit zwischen der Signaturaktualisierung und der nächsten geplanten proaktiven Anti-Malware-Überprüfung gestartet wird, werden die im Container ausgeführten Dateien nicht in Bezug auf die neuesten Anti-Malware-Signaturen überprüft. Um dieses Risiko zu minimieren, konnte das AV-Produkt Scans auf umgeleitete Dateien nur überspringen, wenn seit der letzten proaktiven Überprüfung kein Signaturupdate vorhanden ist. Dies würde die Beeinträchtigung der Containerleistung begrenzen, bis eine proaktive Überprüfung mit den neuesten Signaturen abgeschlossen ist. Optional kann das AV-Produkt in dieser Situation eine proaktive Überprüfung auslösen, sodass nachfolgende Containerstarts effizienter sind.