Was eine Hostnamen-Zugriffsregel auf jeder Netzwerkschicht bedeuten kann
Ein Dienstname lässt sich auf DNS-, Browser-, Proxy- oder Firewall-Ebene durchsetzen. Wählen Sie die Schicht, die die Identität sieht, die Sie steuern wollen.
Drei Personen verlangen dasselbe mit denselben Worten: den Zugriff auf einen Dienstnamen blockieren. Die eine meint, ein Browser dürfe die Website nicht öffnen, die andere, ein Desktop-Sprachclient dürfe seinen Server nicht erreichen, und die dritte, eine Gruppe von Auftragnehmern dürfe eine bestimmte interne Anwendung nicht nutzen. Der Satz ist identisch, und die Durchsetzungsmechanismen haben fast nichts gemeinsam.
Wählen Sie die Schicht nach der Kennung, die sie tatsächlich sehen kann, und dann nach den Clients, die sie abdeckt. Mit einem Firewall-Befehl zu beginnen, den Sie bereits kennen, ist der Weg, auf dem Regeln am Ende nichts blockieren oder zu viel blockieren.
Ein Name ist keine Identität, die jede Schicht prüfen kann
Netfilter und ähnliche Paketfilter sehen Adressen, Protokolle und Ports. Sie sehen keine Hostnamen, und wenn ein Paket sie erreicht, ist der Name bereits aufgelöst. Eine gegen eine Adresse geschriebene Regel ist eine Regel über diese Adresse, welchen Namen ein Nutzer auch eingegeben hat, um sie zu erreichen.
DNS-Richtlinien sitzen früher im Pfad und sehen die Abfrage, die ein anderes Objekt ist als die folgende Verbindung. Sie regeln die Antworten, die ein kontrollierter Resolver zurückgibt, nicht bereits offene Verbindungen und nicht Clients, die so konfiguriert sind, diesen Resolver zu umgehen. Eine aufgelöste Adresse kann sich auch zwischen der Richtlinienprüfung und der nächsten Anfrage ändern, weshalb eine DNS-Antwort keine dauerhafte Autorisierungsaussage ist.
Höhere Schichten sehen mehr Kontext und decken weniger Clients ab. Dieser Tausch ist das ganze Thema, und er erklärt, warum keine einzelne Zeile der Tabelle jemals die richtige Antwort ist. Wählen Sie die Zeile, die die Kennung sieht, um die es in Ihrer Richtlinie tatsächlich geht. Akzeptieren Sie dann die Abdeckung, die diese Zeile impliziert.
Was jede Schicht identifizieren kann
Lesen Sie die Tabelle von der mittleren Spalte nach außen: Die Kennung, die eine Schicht sehen kann, bestimmt die Richtlinie, die sie ehrlich durchsetzen kann.
| Layer | Identifier it sees | What it cannot see |
|---|---|---|
| Packet filter | address, protocol, port | the name, or which other services share that address |
| DNS policy | the queried name and the answer handed back | connections made by clients that ignore the resolver |
| Managed browser | supported URL patterns on managed profiles | non-browser clients, or unmanaged devices |
| CONNECT proxy | host and port for tunnelled requests | the path inside an encrypted request |
Eine Schicht gehört nur dann zur Richtlinie, wenn die Kennung, die sie sieht, mit der Kennung übereinstimmt, die Sie steuern. Die Tabelle erklärt auch, warum eine auf einer Schicht geschriebene Regel selten auf eine andere übertragbar ist, ohne erneut zu entscheiden, was sie schützt.
Wo die naheliegende Regel scheitert
Eine Adressregel ist genau richtig für einen Dienst mit einer dedizierten Adresse, die Sie kontrollieren, und dieses Eigentum sollte in die Richtlinie geschrieben werden. Sie ist genau falsch für alles hinter einer gemeinsam genutzten Content-Delivery-Adresse, wo dieselbe Regel unzusammenhängende Dienste berührt und eine aufgefrischte DNS-Antwort die Regel nicht in eine Hostnamen-Autorisierung verwandelt.
Eine Richtlinie für verwaltete Browser drückt eine Webeinschränkung direkter aus als eine kopierte Adressliste, gilt aber für die Browser und Profile, die das Verwaltungssystem steuert.
Diese Browserregel tut nichts gegen einen Sprachclient, der UDP an einen anderen Host sendet, und ihre Muster werden von diesem Produkt definiert, nicht von Platzhalterkonventionen, die anderswo entlehnt wurden. Ein CONNECT-Proxy erhält ebenfalls Host und Port für eine getunnelte Anfrage und kann den Pfad innerhalb der verschlüsselten Sitzung nicht lesen. Entwerfen Sie die Regel um das herum, was das Protokoll offenlegt. Schreiben Sie dann auf, was sie unabgedeckt lässt, denn genau diese Lücke ist der Ursprung der nächsten Anfrage.
Wählen Sie nach den Clients, nicht nach dem Befehl
Fragen Sie, welche Clients die Richtlinie abdecken muss und welche sie verfehlen darf. Eine Richtlinie für verwaltete Browser deckt ab, was das Verwaltungssystem erreicht, und endet an der Browsergrenze. Eine Resolver-Richtlinie deckt alles ab, was Ihren Resolver nutzt, eine breitere Menge, und sie fällt offen aus für alle, die ihn nicht nutzen.
Für einen Dienst, den Sie betreiben, ist die Autorisierung in der Anwendung stärker als jede Netzwerkgrenze, weil sie dem Konto folgt und nicht dem Pfad. Eine VPN-Route ist Erreichbarkeit und nichts weiter: Ein Paket an einen Dienst senden zu können, ist keine Erlaubnis, ihn zu nutzen. Wo die entscheidende Kennung ein Nutzer oder eine Kanalberechtigung ist, setzen Sie sie dort durch und behandeln Sie die Netzwerkregel als zweite Schicht.
Schreiben Sie die Regel in Begriffen der Ressource
Eine verteidigungsfähige Richtlinie benennt die Ressource, die Identitäten, die Anwendungen im Geltungsbereich und den Pfad, der sie trägt, einschließlich beider verwendeter Adressfamilien. Sie legt auch fest, was mit gemeinsamer Infrastruktur geschieht, die die Regel beiläufig betrifft.
Diese Formulierung erzeugt eine Entscheidung, die jemand später prüfen kann. Eine Regel, die mit der heutigen aufgelösten Adresse begründet wird, erzeugt einen Vorfall, sobald sich die Adresse das erste Mal ändert, und niemand wird erklären können, warum die Sperre jemals richtig war.