In vielen Tenants, die ich betreue, führt Network Protection in Defender for Endpoint noch immer ein Schattendasein. Das ist schade, denn kaum eine andere Schutzschicht wirkt so gut gegen aktuelle Bedrohungen aus dem Web und wird zugleich so selten genutzt. Richtig spannend wird es, wenn man Network Protection konsequent per Intune auf die Windows-Clients bringt. Dann sind neben Edge auch Chrome, Firefox und andere Browser abgesichert. Im Folgenden beschreibe ich, wie ich Network Protection über Intune im Block-Modus aktiviere, Webfilter fein abgestuft einrichte und Ausnahmen oder Blocklisten gezielt pflege.

Network Protection arbeitet unabhängig vom Browser auf Netzwerkebene

Network Protection gehört zur Plattform Microsoft Defender for Endpoint. Verfügbar ist sie ab Plan 1, wirklich sinnvoll einsetzen lässt sie sich aber erst ab Plan 2, weil erst dort die volle Verwaltung und die Berichte dazukommen. Klassische Web-Content-Filter-Lösungen setzen meist im Browser an, Network Protection dagegen direkt auf Netzwerkebene. Welcher Browser verwendet wird, spielt deshalb keine Rolle. Surfen Nutzende mit einem alternativen Browser, greift der Schutz trotzdem und blockiert riskante oder bösartige Seiten zuverlässig. Rein browserbasierte Plug-ins können das nicht leisten. Mit den ASR-Regeln ist Network Protection zwar nicht identisch, sie ist aber ein wichtiger Baustein, wenn man die Angriffsfläche insgesamt verkleinern will.

Intune schaltet Network Protection am besten zuerst im Audit-Modus ein

Die meisten Unternehmen sind gut beraten, Network Protection zunächst im Audit-Modus zu testen. Das erledigt ihr über die Profile unter Intune → Endpoint security → Antivirus oder Attack surface reduction. Dort gibt es die Einstellung „Enable Network Protection“. Im Audit-Modus protokolliert Defender die Zugriffsversuche, blockiert sie aber nicht. Fehlalarme und unerwünschte Nebenwirkungen in der eigenen Umgebung fallen so frühzeitig auf. Den Block-Modus würde ich erst einschalten, wenn die Reports unauffällig sind. Mehrfach habe ich in Projekten erlebt, dass interne Web- oder SaaS-Anwendungen plötzlich gesperrt waren, weil sie ungewöhnliche Domains ansprechen. In solchen Fällen zahlt sich die Vorarbeit im Audit-Modus aus.

Ein typisches Intune-Profil könnte etwa so aussehen:

{
  "@odata.type": "#microsoft.graph.windowsDefenderNetworkProtectionConfiguration",
  "networkProtection": "block"
}

Zu beachten ist, dass Vorgehen und verfügbare Optionen vom gewählten Profil (Antivirus oder ASR) und von der Windows-Version abhängen (Windows 10/11 Enterprise, E3/E5-Lizenz). Fehlt auf dem Gerät der Defender-for-Endpoint-Client (MDE), lässt sich die Funktion nicht zuverlässig verwalten.

Aus Erfahrung rate ich dringend, parallel den Manipulationsschutz (Tamper Protection) zu aktivieren. Andernfalls kann man Network Protection lokal wieder abschalten – ein Risiko, das viele unterschätzen.

Der Web-Content-Filter steuert ganze Kategorien pro Gerätegruppe

Ist Network Protection einmal aktiv, lohnt es sich, die Web-Content-Filter-Optionen in Defender for Endpoint genauer anzusehen. Im Defender-Portal wähle ich unter Einstellungen → Endpoints → Web content filtering gezielt Kategorien wie „Adult Content“, „Phishing“, „Uncategorized“ oder „Social Networking“ aus und lege fest, ob sie blockiert oder nur überwacht werden. Angenehm ist, dass die Zuweisung pro Gerätegruppe geschieht, etwa nach Standort, Abteilung oder Risikoprofil. Aus den Reports geht hervor, welche Seiten gesperrt wurden und ob Nutzende tatsächlich riskante Inhalte aufrufen wollten. So lassen sich die eigenen Annahmen gut überprüfen.

Für manche Zielgruppen betreibe ich den Web-Content-Filter bewusst im „Warnmodus“, während ich in Hochrisikobereichen konsequent sperre. Welche Auswirkungen das hat, lässt sich im Portal sehr gut nachvollziehen.

Eigene Indikatoren regeln Ausnahmen und gezielte Sperren

Nicht jede gesperrte Seite ist bösartig, und umgekehrt ist nicht jede wichtige Seite automatisch freigegeben. Im Defender-Portal könnt ihr für Defender for Endpoint unter Einstellungen → Endpoints → Indicators eine Allow- oder Blocklist für einzelne URLs und Domains pflegen. Diese Listen wirken unabhängig von den Kategorien des Web-Content-Filters. Sie eignen sich deshalb ideal für Ausnahmen, zum Beispiel für SaaS-Partner oder spezielle Testumgebungen, aber ebenso für gezielte Sperren. Einzelheiten beschreibt Microsoft hier: Defender for Endpoint: Indikatoren für IPs und Domains.

In der Praxis entsteht der größte Nutzen erst, wenn Kategorien, Audit-Modus und eigene Allow-/Blocklists zusammenspielen. Diese Möglichkeiten reizen die wenigsten Umgebungen auch nur annähernd aus.

Defender prüft jede Anfrage in einer festen Reihenfolge

Damit klarer wird, wie Network Protection, Web-Content-Filter und Indikatoren zusammenwirken, habe ich eine kleine Übersicht gezeichnet. Sie zeigt, wie Defender eine Internetanfrage abarbeitet:

flowchart TD
    U["User öffnet Website"] --> NP["Network Protection prüft Ziel"]
    NP --> IND["Indikatoren (URL/Domain)"]
    IND --> WCF["Web-Content-Filter Kategorien"]
    WCF --> ACT["Aktion: Blockieren/Erlauben/Audit"]

Abbildung: Reihenfolge der Prüfungen beim Aufruf einer Website mit aktivierter Network Protection.

Network Protection entfaltet ihre Wirkung erst im Verbund mit weiteren Schutzschichten

Wer Network Protection per Intune im Block-Modus ausrollt, bekommt eine Schutzebene, die browserunabhängig arbeitet, sich zentral steuern lässt und sauber mit Berichten, Allow-/Blocklists und dem Web-Content-Filter zusammenspielt. Vor allem in stark regulierten oder dezentral organisierten Umgebungen ist das Insellösungen deutlich überlegen. Den Audit-Modus solltet ihr vor dem Sperren allerdings wirklich nutzen und die Reports regelmäßig durchsehen, denn irgendeine Überraschung gibt es immer. Wirklich dicht wird die Verteidigung am Endpunkt erst, wenn ASR-Regeln und Manipulationsschutz hinzukommen.

Mehr zur Verkleinerung der Angriffsfläche findet ihr in meinem Artikel ASR-Regeln in Defender for Endpoint mit Intune ausrollen.