DNS-Sinkhole erklärt: Wie es bösartige Callbacks stoppt
Ein DNS-Sinkhole leitet Malware-Suchanfragen an ein Ziel zur Täuschung um, stoppt Callbacks und deckt infizierte Geräte auf. Erfahren Sie, wie es funktioniert und wo es eingesetzt wird.
Published 2. November 2026
Ein Gast verbindet ein Laptop mit dem WiFi Ihres CafésWiFi, öffnet einen Browser und geht seinen Aufgaben nach. Im Hintergrund versucht Schadsoftware auf diesem Laptop, Kontakt mit ihrem Server aufzunehmen. Sie können nicht auf jedem Besuchergerät Sicherheitssoftware installieren, aber Sie können steuern, wie Ihr Netzwerk die Anfragen dieses Geräts nach Internetzielen beantwortet.
Ein DNS-Sinkhole bietet Ihnen die Möglichkeit, diesen Rückruf zu unterbrechen und untersuchungswürdige Beweise aufzuzeichnen. Die entscheidende Frage ist nicht nur, was blockiert wird. Es geht darum, ob Sie das betroffene Gerät identifizieren, die Anwendung Ihrer Richtlinie nachweisen und den legitimen Zugriff wiederherstellen können, wenn eine Regel fehlerhaft greift.
Inhaltsverzeichnis
- Was ein DNS Sinkhole in einfachen Worten ist
- Wie ein Sinkhole auf eine bösartige Abfrage antwortet
- Der Conficker-Ausbruch, der Sinkholes zum Standard machte
- Wie Sie Sinkhole-Treffer in Hinweise auf infizierte Geräte umwandeln
- Bereitstellungsmodelle für geteilte und Gäste-Netzwerke
- Fehlalarme und wie Sie diese schnell beheben
- Entscheiden Sie, ob ein Sinkhole zu Ihrem Netzwerk passt
Was ein DNS-Sinkhole in einfachen Worten ist
Der infizierte Laptop muss seinen Controller finden, bevor er Anweisungen anfordern kann. Wenn die Schadsoftware einen Domain-Namen verwendet, fordert der Laptop zuerst einen DNS-Resolver auf, diesen Namen in eine IP-Adresse zu übersetzen.
Stellen Sie sich DNS wie ein Telefonbuch vor. Die Domain ist der Name, den Sie nachschlagen, und die IP-Adresse ist die Nummer, die Sie anrufen müssen. Ein schützender Resolver prüft, ob er diese Nummer bereitstellen sollte.
Ein DNS-Sinkhole ersetzt die Antwort für eine als schädlich bekannte Domain durch ein kontrolliertes Ziel oder blockiert die Antwort, sodass das Gerät die Abfrage nicht nutzen kann, um den Angreifer zu erreichen.
Streng genommen bedeutet Sinkholing das Umleiten von Datenverkehr zu einem kontrollierten Endpunkt. Administratoren verwenden den Begriff auch im weiteren Sinne für DNS-Richtlinien, die schädliche Abfragen unterdrücken, ohne ein Ziel anzugeben.
Die Verzeichnis-Analogie hilft dabei, die Namenssuche von der anschließenden Verbindung zu trennen.
DNS-Sperrung ist keine IP-Sperrung
Ein DNS-Sinkhole greift auf den angeforderten Namen zu, bevor das Gerät die Antwort nutzt, um dieses Ziel zu kontaktieren. Eine gewöhnliche Firewall-Regel wertet Pakete aus, häufig anhand ihrer Ziel-IP-Adresse, und kann den initialen Verbindungsversuch ablehnen. Eine Firewall muss nicht auf eine hergestellte Verbindung warten.
Dieser Unterschied ist wichtig, wenn sich legitime und schädliche Dienste eine Hosting-Infrastruktur teilen. Das Blockieren einer gesamten IP-Adresse kann nicht betroffene Dienste beeinträchtigen, während eine DNS-Richtlinie gezielt auf einen bestimmten Hostnamen ausgerichtet werden kann. Kein Ansatz ersetzt den anderen.
Auf geteilten WiFi ist der Resolver nützlich, da der Betreiber keinen administrativen Zugriff auf den Laptop benötigt. Das Stoppen eines Rückrufs beseitigt jedoch nicht die Infektion. Es bietet dem Betreiber die Möglichkeit zur Eindämmung und bei entsprechender Protokollierung einen Ansatzpunkt für Untersuchungen.
Wie ein Sinkhole auf eine schädliche Abfrage antwortet
Eine DNS-Abfrage ist eine Informationsanfrage, keine Verbindung zur angeforderten Website. Die Antwort des Resolvers bestimmt, was das Gerät als Nächstes versuchen kann.
Der grundlegende Pfad trennt das Gerät, die Richtlinienprüfung und das gesteuerte Ziel.
- Das Gerät fordert seine Rückruf-Domain an. Es sendet eine Abfrage an seinen konfigurierten Resolver.
- Der Resolver identifiziert, welche Richtlinie für das ursächliche Netzwerk gilt, z. B. ein Gäste-SSID oder Mitarbeiter-VLAN.
- Der Name wird mit Bedrohungsinformationen und lokalen Regeln abgeglichen, einschließlich Kategorien für Command-and-Control, Phishing und Malware.
- Bei einer Übereinstimmung, die zu einer Blockierung führt, liefert der Resolver eine kontrollierte Adresse, gibt eine Antwort vom Typ „Name existiert nicht“ zurück oder verweigert bzw. unterdrückt die Antwort.
- Das Gerät versucht entweder eine Verbindung zum Köder herzustellen oder kann kein nutzbares Ziel beziehen. Zulässige Namen werden normal aufgelöst.
Bevor ein Gerät eine Website oder App öffnet, fragt es beim DNS nach deren Adresse, und Shield antwortet unter Anwendung der Richtlinie für dieses Netzwerk. Wenn eine Domain blockiert ist, wird die Verbindung zu diesem Ziel gar nicht erst aufgebaut, und das Gerät zeigt stattdessen die geschützte Sperrseite des Kunden an. Diese Benutzererfahrung sollte nicht mit einer Malware verwechselt werden, die einen fehlgeschlagenen Aufruf erneut versucht.
Wählen Sie die Antwort passend zu den benötigten Nachweisen
Sinkhole-Antwortoptionen und was diese jeweils offenbaren
| Antwort | Was das Gerät erlebt | Was Sicherheitsteams erfahren | Wichtigster Kompromiss |
|---|---|---|---|
| Name existiert nicht (NXDOMAIN) | Abfrage schlägt fehl und die Verbindung kommt nie zustande | Dass eine Abfrage versucht und blockiert wurde | Stoppt den Rückruf, liefert jedoch kein nachfolgendes Verbindungsverhalten |
| Sinkhole-Adresse | Abfrage gibt die Adresse eines kontrollierten Servers zurück | Quell-IP, Rückruf-Timing, Wiederholungsmuster und beobachtbares Protokoll | Erfordert einen überwachten Endpunkt und eine sorgfältige Protokollspeicherung |
| Verweigerte oder unterdrückte Antwort | Resolver lehnt die Abfrage ab oder lässt sie unbeantwortet | Wenig über den Versuch selbst hinaus, es sei denn, die Resolver-Protokollierung ist aktiviert | Schnell anzuwenden, aber einige Clients wiederholen die Abfrage aggressiv |
NXDOMAIN löscht keine Quell- oder Zeitstempel-Informationen. Ein Resolver kann beides protokollieren. Was er bei einer fehlgeschlagenen Abfrage nicht erfassen kann, ist die Verbindung, die die Malware im Anschluss hergestellt hätte.
Eine Peer-Review-Bewertung der Sinkhole-Paketerfassung ergab mit einem fortschrittlichen Erfassungskonzept eine fünffache Verbesserung der Erfassung schädlicher Pakete im Vergleich zu einer herkömmlichen Implementierung. Dies ist ein Nachweis für die Erfassungsarchitektur und kein Versprechen, dass jedes Sinkhole dieselbe Verbesserung liefert.
Dieses Video bietet eine weitere Möglichkeit, den Mechanismus nachzuvollziehen.
Die von Ihnen gewählte Antwort bestimmt, welches nachfolgende Verhalten Sie beobachten können. Halten Sie Collector isoliert und gehen Sie nicht davon aus, dass eine Umleitung für jede verschlüsselte Anwendung eine saubere Warnseite erzeugt.
Der Conficker-Ausbruch, der Sinkholes zum Standard machte
Conficker hat gezeigt, wie Sicherheitsteams die Suche von Schadsoftware nach Anweisungen in eine Informationsquelle verwandeln können. Anstatt jeden infizierten Computer zu überprüfen, fingen Forscher die Zieladressen ab, die der Wurm programmgemäß kontaktieren sollte.
Das Conficker-Archiv von CAIDA beschreibt den Ausbruch, der erstmals im November 2008 festgestellt wurde, wobei frühe Varianten ungefähr 250 pseudozufällige Domainnamen pro Tag generierten. Der Wurm kontaktierte die generierten Namen über HTTP, um Anweisungen oder zusätzliche Schadsoftware zu erhalten.
Sicherheitsforscher und Netzwerkbetreiber registrierten ausgewählte Domains, bevor Kriminelle sie nutzen konnten, und leiteten diese Namen dann auf kontrollierte Server um. Infizierte Computer griffen folglich auf eine Infrastruktur zu, die von den Sicherheitsteams betrieben wurde.
Die Abfrage wurde zu einem Messpunkt
Diese Rückrufe halfen den Einsatzkräften, infizierte Systeme zu identifizieren, die Ausbreitung des Wurms einzuschätzen und den Bereinigungsfortschritt zu verfolgen, ohne direkt mit dem kriminellen Befehlsnetzwerk zu kommunizieren. Abfangen bedeutete daher mehr als nur das Verweigern eines Updates. Es zeichnete einen Computer auf, der weiterhin versuchte, ein Update zu erhalten.
- Zur Eingrenzung verhinderten die Verantwortlichen, dass ausgewählte Namen zu einer vom Angreifer gesteuerten Infrastruktur führten.
- Zur Untersuchung identifizierten Callback-Protokolle Systeme, die überprüft werden mussten.
- Zur Verfolgung der Behebung wiesen fortlaufende Callbacks darauf hin, dass die Bereinigung unvollständig war.
Spätere Varianten von Conficker erweiterten den Pool generierter Namen und fügten Peer-to-Peer-Updates hinzu. Sicherheitsteams mussten die Registrierung und Blockierung koordinieren, anstatt sich auf eine kleine, statische Liste zu verlassen.
Die historische Bereitstellung unterschied sich auch von der lokalen Filterrichtlinie einer Organisation. Forscher änderten die Ziele von Domänen, die sie kontrollierten, was sich auf infizierte Computer auswirkte, die diese Namen über gewöhnliches DNS auflösten. Ein Betreiber von Veranstaltungsorten wendet Richtlinien stattdessen in der Regel an seinem eigenen rekursiven Resolver an.
In beiden Fällen war die Abdeckung die Einschränkung. Sicherheitsteams konnten Callbacks zu Namen unter ihrer Kontrolle abfangen, was jedoch nicht bedeutete, dass jeder mögliche Aktualisierungspfad verschwunden war. Conficker etablierte Sinkholing sowohl als Eingrenzungstechnik als auch als Messwerkzeug - nicht als Ersatz für die Reparatur infizierter Computer.
Sinkhole-Treffer in Hinweise auf infizierte Geräte umwandeln
Ein Client, der wiederholt eine blockierte Command-and-Control-Domain (C2) abfragt, erfordert Aufmerksamkeit. Das Muster kann einen nützlichen Anhaltspunkt liefern, selbst wenn Sie keinen Endpunkt-Agenten, keine Payload-Inspektion oder keine detaillierten Firewall-Protokolle haben.
Diese Abhängigkeit ist wichtig: Das Botnet-Verteidigungspapier der University of Arizona erklärt, dass eine effektive DNS-Umleitung die Identifizierung der C2-Infrastruktur des Botnets und die Kooperation des vom Bot genutzten DNS-Betreibers erfordert. Ein Treffer zeigt lediglich, dass eine bestimmte Anfrage auf Ihre Richtlinie gestoßen ist, nicht dass Sie jeden Kommunikationspfad aufgedeckt haben.
Behalten Sie ausreichend Kontext, um den Client zu finden
Erfassen Sie diese Felder gemeinsam, anstatt sie auf unzusammenhängende Dashboards zu verteilen:
- Zeitstempel: Korrelieren Sie das Ereignis mit Netzwerk-Leases und Authentifizierungsdatensätzen.
- SSID oder VLAN: Identifizieren Sie die betroffene Netzwerk- und Richtliniengrenze.
- Client-Kennung: Bewahren Sie eine verweisfähige Gerätereferenz auf, nicht nur die öffentliche Adresse des Standorts.
- Abgefragte Domain: Speichern Sie den genauen Hostnamen, der die Regel ausgelöst hat.
- Richtlinienkategorie: Unterscheiden Sie eine Bedrohungsklassifizierung von einer Inhaltsbeschränkung.
- Antwortaktion: Erfassen Sie, ob der Resolver umgeleitet, abgelehnt oder NXDOMAIN zurückgegeben hat.
Eine öffentliche Quell-IP-Adresse kann viele Gäste hinter demselben Gateway repräsentieren. Um ein einzelnes Gerät zu identifizieren, korrelieren Sie Endpunkt-Beobachtungen mit Resolver- und Netzwerkprotokollen. Stufen Sie nicht den gesamten Standort als infiziert ein, nur weil ein Collector dessen gemeinsam genutzte Adresse sieht.
Untersuchungsregel: Betrachten Sie einen Sinkhole-Treffer als Hinweis mit unterstützendem Kontext und nicht als automatisches Urteil gegen den Gerätebesitzer.
Validieren Sie das Signal und halten Sie die Abdeckung aufrecht
Vergleichen Sie wiederholte Zugriffe mit dem normalen Verhalten in diesem Netzwerk und überprüfen Sie die Klassifizierung anhand aktualisierter Feeds für Bedrohungsinformationen. Generierte Domains, sich schnell änderndes Hosting, festkodierte Adressen und Ausweichkanäle können Lücken hinterlassen. Das Ausbleiben von Zugriffen ist kein Beweis dafür, dass ein Gerät sauber ist.
Der Domain-Status erfordert ebenfalls eine kontinuierliche Überprüfung. Eine akademische Studie aus dem Jahr 2019 über die Deaktivierung böswilliger Domains ergab, dass über 14 % der in den vorangegangenen zehn Monaten deaktivierten Domains anschließend wieder auf den kommerziellen Domainmarkt zurückgekehrt waren.
Überprüfen Sie Regelherkunft, Eigentümerschaft und Klassifizierung regelmäßig. Wenn Sie registrierte Sinkhole-Domänen selbst betreiben, schützen Sie deren DNS-Konfiguration und Verlängerungen. Beschränken Sie den Zugriff auf Protokolle auf Client-Ebene und legen Sie Aufbewahrungsfristen fest, die den lokalen Gesetzen und Ihren Untersuchungsanforderungen entsprechen.
Bereitstellungsmodelle für gemeinsam genutzte Netzwerke und Gastnetzwerke
Ein Sinkhole schützt den DNS-Pfad, den Sie steuern. Der Browser oder die Anwendung eines Gastes wählt möglicherweise stattdessen einen externen verschlüsselten Resolver, sodass Ihre lokale Richtlinie nichts zum Auswerten hat.
Eine technische Analyse von verschlüsseltem DNS erklärt, warum externes DNS-over-HTTPS die herkömmliche DNS-Überwachung umgehen kann. Die Bereitstellungsentscheidung betrifft daher die Resolver-Durchsetzung und das Client-Verhalten und nicht nur die Qualität einer Sperrliste.
Sinkhole-Bereitstellungsmodelle für gemeinsam genutzte Netzwerke
| Modell | Wo die Steuerung sitzt | Bestmögliche Eignung | Haupteinschränkung |
|---|---|---|---|
| Netzwerk-Resolver für Gäste-WiFiWiFi | Resolver, der jedem Client vom Netzwerk übergeben wird | Hotels, Pubs, öffentliches WiFiWiFi | Clients mit eigenem, fest codiertem oder verschlüsseltem Resolver können ihn umgehen |
| Firewall-DNS-Inspektion | Innerhalb einer bestehenden Firewall oder eines Gateways | Büros mit einer etablierten Firewall-Landschaft | Konventionelle DNS-Inspektion erfasst externes DoH über HTTPS nicht |
| Verwaltete Browser- oder Geräterichtlinie | Browser oder Betriebssystem legt den Resolver fest und deaktiviert alternatives DoH | Verwaltete Unternehmens- oder Schulgeräte | Erreicht keine unverwalteten privaten Geräte |
| Cloud Protective DNS | Provider-gehosteter Resolver, auf den das Netzwerk-DNS verweist | Standorte mit mehreren Filialen und große Umgebungen | Hängt von der Verfügbarkeit des Anbieters und dem Zugriff auf Telemetriedaten ab |
Verschlüsselung und Durchsetzung sind getrennte Entscheidungen
Verschlüsseltes DNS verbessert die Vertraulichkeit zwischen Client und Resolver. Es schwächt die Filterung nicht zwangsläufig: Ein zugelassener schützender Resolver kann verschlüsselte Abfragen akzeptieren und dennoch Richtlinien anwenden. Das Sichtbarkeitsproblem entsteht, wenn der Client einen externen Resolver wählt, der Ihre Regeln nicht durchsetzt.
Für verwaltete Geräte können Browser- und Betriebssystemrichtlinien den genehmigten Dienst festlegen. In Gästenetzwerken benötigen Sie eine dokumentierte Position zu alternativem verschlüsseltem DNS, Nutzerdatenschutz und zulässigen Ausnahmen. Das Blockieren des gesamten verschlüsselten Webdatenverkehrs zur Unterbindung von DoH ist keine praktikable allgemeine Strategie.
Platzieren Sie die Steuerung an einer Grenze, die Sie testen können
Verteilen Sie den genehmigten Resolver über die Netzwerkkonfiguration. Beschränken Sie direktes ausgehendes konventionelles DNS auf genehmigte Resolver, wobei sowohl Transportprotokolle als auch beide IP-Familien abgedeckt werden. Transparente Umleitungen können konventionelles DNS erfassen, das woandershin gesendet wird, lösen jedoch beliebig verschlüsseltes DNS nicht transparent.
Nutzen Sie die Netzwerksegmentierung, um Richtlinien für Mitarbeiter, Gäste und Spezialgeräte zu trennen. Eine restriktive Gäste-Regel sollte medizinische Geräte oder Mitarbeiteranwendungen nicht unterbrechen.
- Reguläre Auflösung testen: Bestätigen Sie, dass zugelassene Anwendungen weiterhin funktionieren.
- Bypass-Pfade testen: Überprüfen Sie vom Browser ausgewählte Resolver und andere zugelassene Tunnel.
- Zuordnung testen: Bestätigen Sie, dass eine gesteuerte Richtlinienübereinstimmung für das korrekte Netzwerk und den richtigen Client angezeigt wird.
Eine DNS-Änderung auf Netzwerkebene kann eine Filterung über alle teilnehmenden Geräte hinweg anwenden, ohne dass auf jedem einzelnen Software installiert werden muss. Weisen Sie die Abdeckung durch Tests nach, anstatt davon auszugehen, dass die Verteilung einer Resolver-Adresse jede Anwendung dazu zwingt, diese zu nutzen.
Fehlalarme und wie Sie diese schnell beheben
Eine längere Sperrliste ist nicht automatisch sicherer. Eine pauschale Regel gegen gemeinsame Cloud-Infrastrukturen kann Lieferantenportale, Zahlungs-Workflows oder Lernanwendungen unterbrechen, ohne den Schutz vor der eigentlichen Bedrohung zu verbessern.
Eine Implementierungsstudie zu Sinkholing aus dem Jahr 2025 ergab Fehlalarme, die eine manuelle Verwaltung von Positivlisten und geschultes Personal erforderten. Die betriebliche Verantwortung gehört in den Bereitstellungsplan, nicht nur in die Incident-Warteschlange.
Der Wiederherstellungsprozess sollte gemeinsam genutzte Dienste und eng begrenzte Ausnahmen berücksichtigen.
Stellen Sie den Zugriff wieder her, ohne den Schutz zu entfernen
Starten Sie neue Richtlinien für einen vereinbarten Beobachtungszeitraum im Reinen Protokollierungsmodus. Erfassen Sie den Client, die Kategorie und die übereinstimmende Regel, damit spätere Entscheidungen einen Nachweispfad haben.
Sinkhole-Symptome, wahrscheinliche Ursachen und erste Maßnahmen
| Symptom | Wahrscheinliche Ursache | Erste Maßnahme |
|---|---|---|
| Mitarbeitergerät kann eine Lieferanten-Website nicht erreichen | Gemeinsam genutzte Cloud-Domain nach Kategorie blockiert | Prüfen Sie die protokollierte Kategorie und setzen Sie dann den genauen Host auf die Allowlist, nicht die gesamte Domain |
| Ein Gastgerät löst jede Minute Sinkhole-Treffer aus | Infiziertes Gerät oder aggressive App versucht es erneut | Identifizieren und isolieren Sie den Client und veranlassen Sie anschließend eine Geräteüberprüfung |
| Anstieg blockierter Anfragen nach einer Richtlinienänderung | Breiter Blocklist-Eintrag oder Wildcard-Regel | Setzen Sie die letzte Änderung zurück und überprüfen Sie deren SSID- oder VLAN-Umfang |
| Apps funktionieren, aber ein SSID zeigt keine Blockierungen an | Clients verwenden möglicherweise verschlüsseltes DNS außerhalb des Resolvers | Führen Sie einen kontrollierten Richtlinientest durch und überprüfen Sie die Resolver-Konfiguration sowie die ausgehenden DNS-Pfade |
Ein leerer Bericht allein ist kein Beleg für eine Umgehung. Das Netzwerk hat möglicherweise einfach keine passenden Anfragen erzeugt.
Messen Sie verhinderte schädliche Verbindungen, die Falsch-Positiv-Rate, die Bearbeitungszeit von Einsprüchen und Ausnahmen pro Standort. Das reine Volumen blockierter Abfragen kann allein schon deshalb steigen, weil eine Anwendung wiederholt Versuche unternimmt.
Bestätigen Sie vor dem Aktivieren einer Regel:
- Klassifizierung: Die Bedrohungskategorie der Domain wird unterstützt.
- Gemeinsame Nutzung: Geschäftsanwendungen greifen nicht auf denselben Host oder dieselbe übergeordnete Domain zu.
- Rückgängigmachung: Die vorherige Richtlinie und das Wiederherstellungsverfahren sind dokumentiert.
- Umfang: Das/die vorgesehene SSID oder VLAN ist explizit angegeben.
- Zuständigkeit: Eine benannte Person bearbeitet Ausnahmeanfragen und überprüft deren Ablaufdatum.
Entscheiden Sie, ob ein Sinkhole zu Ihrem Netzwerk passt
Beginnen Sie bei einem kleinen Büro mit verwalteten Endpunkten mit DNS-Protokollierung und Endpunkt-Richtlinien. Möglicherweise verfügen Sie bereits über die Gerätesteuerung, die für die direkte Untersuchung verdächtiger Anfragen erforderlich ist. Vermeiden Sie daher die Einrichtung eines Collectors, den Sie nicht warten können.
Priorisieren Sie bei Gäste-, öffentlichen oder Studenten-Netzwerken die Durchsetzung von Grenzen und die Zuordnung von Clients. Unverwaltete Geräte machen Kontrollen auf Resolver-Ebene nützlich, ein Betreiber benötigt jedoch weiterhin eine sichere Möglichkeit, ein Gerät zu untersuchen oder einzudämmen, ohne dessen Eigentümer voreilig zu beschuldigen.
Passen Sie das Betriebsmodell an die Infrastruktur an
Eine Organisation mit mehreren Standorten profitiert von zentral verwalteten Resolver-Richtlinien, netzwerkspezifischen Ausnahmen und einem konsolidierten Reporting. Vergleichen Sie Dienste anhand der von ihnen nachgewiesenen Daten und der Steuerungsmöglichkeiten, die Sie testen können - nicht nur anhand der Anzahl der Kategorien.
Wählen Sie ein Sinkhole, wenn Sie den gesamten Prozess steuern können: Richtlinie, Abdeckung, Untersuchung, Ausnahmen und Wiederherstellung.
Beginnen Sie mit einer begrenzten Bereitstellung:
- Ermitteln Sie den Resolver-Pfad. Identifizieren Sie, welchen Resolver jedes Netzwerk verwendet und wo alternatives DNS oder Tunnels die Richtlinie umgehen könnten.
- Führen Sie einen dokumentierten Beobachtungszeitraum durch, in dem nur protokolliert wird. Zeichnen Sie übereinstimmende Anfragen mit deren Client, Kategorie und Netzwerk auf und überprüfen Sie anschließend berechtigte Anwendungsabhängigkeiten.
- Aktivieren Sie zuerst Blockierungen mit hoher Zuverlässigkeit. Beginnen Sie mit bestätigten C2- und Malware-Zielen, bewahren Sie einen schriftlichen Wiederherstellungsplan auf und weisen Sie einen Verantwortlichen für Ausnahmen zu.
Trennen Sie die Endpunkt-Behebung von der Eingrenzung auf Netzwerkebene. Ein blockierter Callback ist eine erfolgreiche Intervention, aber das Gerät muss dennoch untersucht werden. Ihre Bereitstellung ist bereit, wenn die Mitarbeiter sowohl eine kontrollierte Blockierung als auch eine sichere Wiederherstellung des legitimen Zugriffs demonstrieren können.
Purple Shield bietet schützendes DNS mit netzwerkspezifischen Richtlinien und Berichten, sodass Sie die Blockierung schädlicher Domains zusammen mit den für die Verwaltung erforderlichen Nachweisen bewerten können. Besuchen Sie Purple Shield, um eine kostenlose 30-Tage-Testversion zu vereinbaren, leiten Sie das DNS Ihres Netzwerks auf Shield um und testen Sie die Filterung in Ihrem Live-Netzwerk ohne neue Hardware oder Geräte-Agenten.