Qué puede significar una regla de acceso por nombre de host en cada capa de red
Un nombre de servicio puede aplicarse a nivel de DNS, navegador, proxy o cortafuegos. Elija la capa que ve la identidad que quiere gobernar.
Tres personas piden lo mismo con las mismas palabras: bloquear el acceso a un nombre de servicio. Una se refiere a que un navegador no debe abrir el sitio, otra a que un cliente de voz de escritorio no debe llegar a su servidor, y la tercera a que un grupo de contratistas no debe usar una aplicación interna concreta. La frase es idéntica, y los mecanismos de aplicación no tienen casi nada en común.
Elija la capa por el identificador que realmente puede ver, y después por los clientes que cubre. Empezar por un comando de cortafuegos que ya conoce es como las reglas acaban sin bloquear nada, o bloqueando demasiado.
Un nombre no es una identidad que cada capa pueda comprobar
Netfilter y los filtros de paquetes similares ven direcciones, protocolos y puertos. No ven nombres de host, y cuando un paquete les llega el nombre ya se ha resuelto. Una regla escrita contra una dirección es una regla sobre esa dirección, sea cual sea el nombre que un usuario escribiera para llegar a ella.
La política de DNS se sitúa antes en la ruta y ve la consulta, que es un objeto distinto de la conexión que sigue. Gobierna las respuestas que devuelve un resolutor controlado, no las conexiones que ya estaban abiertas, ni los clientes configurados para eludir ese resolutor. Una dirección resuelta también puede cambiar entre la revisión de la política y la siguiente petición, por lo que una respuesta DNS no es una declaración de autorización duradera.
Las capas superiores ven más contexto y cubren menos clientes. Ese intercambio es todo el asunto, y explica por qué ninguna fila de la tabla es nunca la respuesta correcta. Elija la fila que ve el identificador del que trata realmente su política. Luego acepte la cobertura que esa fila implica.
Qué puede identificar cada capa
Lea la tabla desde la columna central hacia fuera: el identificador que una capa puede ver dicta la política que puede aplicar con honestidad.
| 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 |
Una capa pertenece a la política solo cuando el identificador que ve coincide con el identificador que usted gobierna. La tabla también explica por qué una regla escrita en una capa rara vez se traslada a otra sin decidir de nuevo qué protege.
Dónde falla la regla obvia
Una regla de dirección es exactamente correcta para un servicio con una dirección dedicada que usted controla, y esa propiedad debería escribirse en la política. Es exactamente incorrecta para cualquier cosa detrás de una dirección compartida de entrega de contenido, donde la misma regla toca servicios no relacionados y una respuesta DNS actualizada no convierte la regla en autorización por nombre de host.
Una política de navegador gestionado expresa una restricción web más directamente que una lista de direcciones copiada, pero se aplica a los navegadores y perfiles que gobierna el sistema de gestión.
Esa regla de navegador no hace nada con un cliente de voz que envía UDP a otro host, y sus patrones los define ese producto y no convenciones de comodines tomadas de otro sitio. Un proxy CONNECT también recibe un host y un puerto para una petición tunelizada, y no puede leer la ruta dentro de la sesión cifrada. Diseñe la regla en torno a lo que expone el protocolo. Después anote qué deja sin cubrir, porque ese hueco es de donde vendrá la siguiente petición.
Elija por los clientes, no por el comando
Pregunte qué clientes debe cubrir la política y cuáles puede dejar fuera. Una política de navegador gestionado cubre lo que alcanza el sistema de gestión y se detiene en la frontera del navegador. Una política de resolutor cubre todo lo que usa su resolutor, que es un conjunto más amplio, y falla en abierto para quien no lo hace.
Para un servicio que usted opera, la autorización en la aplicación es más fuerte que cualquier frontera de red, porque sigue a la cuenta y no a la ruta. Una ruta VPN es accesibilidad y nada más: poder enviar un paquete a un servicio no es permiso para usarlo. Donde el identificador que importa es un usuario o un permiso de canal, aplíquelo allí y trate la regla de red como una segunda capa.
Escriba la regla en términos del recurso
Una política defendible nombra el recurso, las identidades, las aplicaciones en el ámbito y la ruta que las transporta, incluidas ambas familias de direcciones en uso. También declara qué ocurre con la infraestructura compartida que la regla afectará de forma incidental.
Esa formulación produce una decisión que alguien puede auditar más adelante. Una regla justificada por la dirección resuelta de hoy produce un incidente la primera vez que la dirección cambie, y nadie podrá explicar por qué el bloqueo fue alguna vez correcto.