Protocolos en claro y cifrados desde el perímetro

Un protocolo en claro manda su contenido tal cual: quien tenga acceso a un punto del camino (un conmutador, un enlace, un equipo comprometido) lo puede leer. Entre los de uso común están HTTP en el puerto 80, FTP, el SNMP en sus versiones 1 y 2c, que lleva su «comunidad» sin protegerla, y el DNS tradicional. Cada uno tiene un sustituto cifrado, y la columna cifrado de la tabla dice si la conversación observada lo usa.

El riesgo crece con lo que el protocolo lleva. Una consulta de nombres en claro revela destinos; una sesión de administración en claro puede revelar las credenciales con que se administra un equipo de red.

Consulta conversaciones filtrando por cifrado. Entre las conversaciones de administración hay una que va sin cifrar entre un puesto de TI y un conmutador de la planta.

No todo lo que va en claro pesa igual. Dentro de una zona de gestión, con acceso controlado, el riesgo es otro que cuando el tráfico sale a Internet y pasa por redes que la empresa no controla. Por eso la primera lectura es cruzar dos columnas: cifrado y zona_destino.

La conversación oportunista es otra categoría: el cifrado se negocia si el otro extremo lo ofrece, y si no, sigue en claro. No cuenta aquí como «sin cifrar», pero se anota para revisar la política del servidor de correo.

Cuenta las conversaciones que no van cifradas y cuyo destino es Internet.

Una conversación en claro hacia el exterior tiene dos preguntas obvias: qué lleva y a quién. Lo primero lo dice el protocolo y el origen: un servidor de facturas que sube archivos con un protocolo de transferencia de archivos en claro lleva, probablemente, documentos de la empresa. Lo segundo es el destino, y es la dirección que se le entrega al dueño del proceso para preguntarle si es un proveedor con el que existe un acuerdo.

Consulta conversaciones y mira la conversación de srv-facturas-01.

Cuando una conversación va cifrada con TLS, el contenido queda protegido, pero el cifrado no borra la conversación. Se siguen viendo las direcciones de origen y de destino, el puerto, el momento, la duración y el volumen. En TLS 1.3 el certificado del servidor ya viaja cifrado, pero el nombre que el cliente pide suele verse en el primer mensaje del saludo (RFC 8446). Con eso se hace casi todo el trabajo de un defensor del perímetro: quién habla con quién, cuánto y cuándo.

Quien quiere ver el contenido necesita estar en uno de los extremos o inspeccionar el tráfico con un componente autorizado, que es tema de la sala de inspección de TLS del módulo de proxy.

La lista de protocolos en claro suele ser larga y no se arregla de una vez. Se ordena por qué lleva y hasta dónde llega: primero lo que sale del perímetro o lleva credenciales de administración, después lo interno con datos de negocio, al final lo que casi no lleva nada. Cada cambio necesita un sustituto cifrado y un dueño que lo acepte, y se pasa por el proceso de cambios.

Mira de nuevo conversaciones y piensa qué filas llevan administración o datos de negocio.