Este artículo explica el flujo de paquetes para los motores de seguridad en el PoP basado en la arquitectura de Cato de Motor de Nube de Paso Único (SPACE).
"Visión general"
La arquitectura SPACE de Cato examina y procesa los flujos de tráfico con un solo servicio. Este servicio incluye múltiples motores de redes y seguridad que analizan y procesan simultáneamente los flujos de tráfico. Esta arquitectura evita las limitaciones de combinar múltiples soluciones puntuales con encadenamiento de servicios. El pase único para un flujo minimiza la latencia y mejora el rendimiento general de la red. Cada PoP puede realizar estas decisiones de redes y seguridad utilizando todos los servicios y motores SPACE de Cato.
Los motores de seguridad y redes tienen acceso completo a los datos para el flujo de tráfico y evalúan y comparten simultáneamente datos entre sí con un contexto compartido. Los motores operan en paralelo, no hay prioridad para que un motor evalúe el tráfico sobre otro. Los motores están ubicados en cada PoP y pueden compartir datos sin esperar información de un motor en una ubicación física diferente.
Por ejemplo, una regla de firewall bloquea dispositivos macOS, sin embargo, el motor de firewall no puede obtener estos datos del primer paquete y espera más datos. Cuando un motor diferente identifica el dispositivo como macOS, el firewall bloquea el flujo de acuerdo a la acción de la regla.
Resumen de Servicios de Redes y Seguridad SPACE
Esta sección enumera los servicios de red y seguridad y motores en el PoP que se aplican a las diferentes fases del flujo de paquetes.
Políticas y motores de Cato
Firewall - Política de firewall para firewalls de Internet y WAN
Red - Política de Reglas de Red para enrutamiento y prioridad QoS
IPS/SAM - Protecciones IPS y Monitoreo de Actividades Sospechosas (SAM)
Control de Apps - Identificación de aplicaciones para la política de Control de Aplicaciones
Control de Apps gen2 - Reglas para aplicaciones basadas en acceso: permitir o bloquear
Control de Apps gen3 - Reglas para aplicaciones basadas en acciones granulares: cargar, descargar, etc.
TLSi - Inspección TLS para tráfico HTTPS y cifrado
DLP - Inspección de contenido para la política de Protección contra Pérdida de Datos (DLP)
AM/NGAM - Anti-Malware y Escaneo Next-Gen Anti-Malware de archivos adjuntos en busca de malware
Datos de flujo de tráfico y protocolos
Identificación de Apps - Se utilizan varios criterios para identificar la aplicación específica para políticas de seguridad o de redes
OS - Sistema operativo para el dispositivo, por ejemplo, con la política de Estado del Dispositivo o Conectividad del Cliente
Clase de cliente - Tipo de aplicaciones cliente que se ejecutan sobre el sistema operativo que creó este flujo de red (por ejemplo, Chrome)
URLF - Filtrado de URLs para categorías de Cato basadas en la URL del sitio web
Tipo_de_archivo - Para CASB y DLP, archivo adjunto en la dirección de carga o descarga
Flujo de Paquete TCP con SPACE
Este es un ejemplo de un flujo HTTP típico con los siguientes elementos:
Cronología - Diferentes fases del flujo de tráfico
Campos disponibles - Datos que están disponibles para la fase específica de la cronología
Motor Cato - Motor SPACE que es capaz de analizar el flujo y luego tomar la acción apropiada (bloquear o permitir)
Datos de flujo de tráfico - Para cada fase, datos que se utilizan para evaluar el flujo de tráfico
Puede ver una lista de los detalles a continuación, Detalles de Flujo TCP de Ejemplo.
Identificación de App de Ejemplo de un Flujo de Tráfico
Este es un ejemplo de un flujo de tráfico para una regla que incluye la aplicación Slack, y muestra qué información está disponible en cada etapa.
Primer paquete - TCP
Origen - 10.10.2.107 Puerto de origen - 55477 IP de destino - 3.68.124.168 Puerto de destino - 443 Protocolo - TCP Respuesta DNS - 3.68.124.168 - slack.com (respuesta opcional)Esta es la información de flujo de tráfico disponible basada en este primer paquete de ejemplo:
5 tuplas - no puede identificar que el tráfico está conectado a la aplicación Slack
Respuesta DNS - Basado en flujos anteriores, los motores ya saben que el dname para esta IP de destino es slack.com
ASN - basado en la IP de destino, el motor de Seguridad puede identificar el ASN
La identificación de aplicaciones incluye: tcp
El motor espera información adicional del apretón de manos TLS antes de poder completar la identificación de la app Slack.
apretón_de_manos_tls
"Encabezado TLS" "sni_host": "slack.com" "razón de omisión de inspección predefinida": "ninguna" "cadena_ja3_formateada": "771,4865-4866-4867-49195-49199-49196-4920…"Esta es la información de flujo de tráfico disponible basada en este apretón_de_manos_tls de ejemplo:
Encabezado TLS y puerto del servidor 443 - coincide con el protocolo TLS
SNI es slack.com - coincide con la identificación de la app Slack de Cato
El SNI también se envía al URLF, y coincide con las categorías Información de Negocios, Computadoras y Tecnología, Social
La Clase de Cliente es JA3 - clasifica al cliente como un navegador basado en el análisis de las huellas dactilares TLS
Inspección o acción de omisión TLS - basada en la Clase de Cliente y la identificación de la aplicación
La identificación de aplicaciones incluye: tcp, tls, slack
HTTP
"url" : "upload.slack.com: "nombre_host" : "slack.com" "Tipo de archivo" : "application/pdf" "Disposición del contenido" : form-data; nombre="file"; nombre_archivo="sample-data.pdf" "Longitud del contenido" : "52765"En este flujo de ejemplo, la siguiente información está disponible basada en los datos HTTP:
La identificación de aplicaciones incluye: tcp, tls, http, slack
La Inspección TLS descifra el flujo e identifica que el nombre_host del servidor Slack es slack.com
Encabezado HTTP - coincide con el protocolo HTTP
Este es un ejemplo común donde el HTTP_host coincide con el SNI, y no hay cambio para la identificación de la aplicación
URL - el prefijo de carga proporciona más granularidad y puede coincidir con la acción de carga en la política de Control de Aplicaciones
Tipo de archivo, Disposición del contenido, Longitud del contenido - proporciona información sobre el nombre del archivo, tamaño y tipo
Acciones de la política de Control de Aplicaciones:
Aplicar una política que solo use el inquilino corporativo de Slack
Control de archivos basado en el tipo de archivo
Anti-Malware y NG Anti-Malware solo escanean archivos en la dirección de descarga.
Cuerpo HTTP
"Carga útil del cuerpo HTTP" : "El Archivo en sí"Por ejemplo, la política DLP aplica que no se pueden usar datos de tarjetas de crédito en los mensajes de Slack.
La identificación de la app se completa para la aplicación Slack. Se identifica como tráfico que pertenece a la Categoría social.
Cuando el contenido del archivo está listo, estos motores analizan el contenido del archivo:
El motor DLP escanea contenido basado en la política de Control de Datos
Anti-Malware y NG Anti-Malware escanean archivos en la dirección de descarga
Políticas y Motores de Cato
Esta sección explica la política de seguridad de Cato y los motores que analizan y actúan sobre el flujo de tráfico.
Políticas de Firewall y Redes
El Firewall WAN, el Firewall de Internet y las políticas de Reglas de Red a menudo pueden evaluar un flujo de tráfico en el primer paquete. Por ejemplo, reglas que se basan en datos de la 5-tupla. Sin embargo, para reglas que coinciden con aplicaciones específicas, como Azure o Slack, se requieren datos adicionales del flujo de tráfico para que el motor evalúe el flujo. Esto significa que la fase en la cual el motor evalúa el flujo depende de la configuración para la regla específica.
Para más información sobre los tipos de reglas de firewall, vea Políticas de Firewall de Internet y WAN – Mejores Prácticas.
Ejemplo de Primer Paquete para Regla de Red Simple y Regla de Firewall Compleja
Este ejemplo muestra cómo los motores del PoP evalúan de manera diferente un flujo de tráfico para una regla de red simple que usa direcciones IP y puertos, y una regla de firewall compleja para aplicaciones Azure. El motor de red puede evaluar el flujo basado en el primer paquete, pero el PoP espera los datos adicionales para que el motor de firewall finalice su análisis.
Regla de Red de Ejemplo
La siguiente regla de red es para tráfico donde la Fuente es un rango de IP con el rango de puertos 8000 - 8010, y el tráfico sale a través de la ubicación del PoP en Londres.
El motor de red puede evaluar la decisión de enrutamiento para el flujo de tráfico basado en la 5-tupla.
Regla de Firewall WAN de Ejemplo
La siguiente regla de firewall WAN permite el tráfico que es del mismo Fuente que el rango de IP para la regla de red anterior, y para usuarios que son miembros del grupo de usuarios RnD. Además, la regla es para aplicaciones Azure para servicios HTTP(S), TLS, FTP y TFTP.
El motor de firewall no puede evaluar el tráfico en el primer paquete, porque necesita confirmar la identidad del usuario, las aplicaciones Azure y los servicios para el flujo. Después de que el motor termina la evaluación y el flujo cumple con todos los criterios, el motor permite el flujo. El PoP también aplica la decisión de enrutamiento basada en el primer paquete.
Filtrado de URLs y Categorías de Cato
El servicio de filtrado de URLs funciona analizando la URL de un sitio web y comparándola con una base de datos de sitios web maliciosos o inapropiados conocidos o sospechosos. Este servicio también puede analizar el contenido del propio sitio web para determinar sus categorías, como contenido para adultos, apuestas, redes sociales o medios de transmisión.
Para más información sobre categorías, ver Trabajando con Categorías.
Inspección de TLS
El motor de Inspección TLS está involucrado durante la fase de apretón_de_manos_tls del flujo de paquetes. La decisión de inspeccionar o no el flujo es irreversible y se lleva a cabo en dos etapas:
Etapa 1 - La primera carga útil del paquete client_hello da una indicación inicial si el motor de Inspección TLS inspeccionará este flujo de tráfico
Etapa 2 - El client_hello se analiza completamente, y se aplica la acción de política de Inspección TLS (inspeccionar o omitir el flujo)
Para flujos HTTPS, es posible que haya una decisión de bloquear el paquete basada en la etapa 1. Sin embargo, el motor continúa comunicándose y estableciendo una conexión TLS para presentar la página de bloqueo del firewall o IPS correcta al usuario final.
IPS
El motor IPS sigue funcionando durante el tiempo de vida del flujo de tráfico. Inspecciona elementos específicos que están disponibles en diferentes etapas y actúa sobre el contenido que coincide positivamente con una protección IPS. Puedes pensar en el IPS como actuando como una lupa, esperando constantemente actualizaciones del tráfico y proporcionando continuamente información al motor que se observó en el flujo.
El siguiente ejemplo muestra diferente información disponible en diferentes etapas del flujo:
El protocolo para el flujo es HTTP
Basado en el payload, hay TLS
Hay un client_hello que utiliza el conjunto de cifrado TLS 1.3 TLS_AES_256_GCM_SHA384
Diferentes protecciones IPS podrían coincidir con cualquiera de los elementos anteriores y luego tomar medidas sobre el flujo de tráfico en esa fase.
Protección DNS
La Protección DNS es parte del motor IPS y se ejecuta sobre el flujo DNS para la solicitud y respuesta (sin ninguna conexión con el transporte, por ejemplo TCP o UDP).
Durante la solicitud DNS, se analiza y evalúa el nombre de dominio para verificar su reputación y fuentes estáticas. Luego, durante la respuesta DNS, se analizan la IP resuelta y el contenido para detectar potencialmente contenido malicioso. La política de Protección DNS se aplica a cualquier contenido coincidente (bloquear o permitir el flujo de tráfico).
Control de Aplicaciones
El motor de Control de Aplicaciones inspecciona el tráfico y aplica las acciones para la política de Control de Aplicaciones, y se evalúa en cada nueva transacción HTTP (solicitud y respuesta).
Para aplicaciones gen2, se requieren TLS y proxy HTTP para completar la identificación de la aplicación.
Para reglas que incluyen requisitos de seguridad y cumplimiento:
Basado en datos contextuales de otros motores de red y seguridad, el motor de Control de Aplicaciones puede evaluar estos requisitos durante la fase de inspección_tls
También es posible que el motor obtenga esta información del SNI y no requiera TLS o identificación completa de la aplicación (inspección DPI de capa 7) para evaluar la aplicación
DLP
El motor DLP inspecciona el contenido del flujo de tráfico y es una extensión del motor de Control de Aplicaciones. Cuando la política especifica un tipo de archivo o tamaño de archivo, el motor necesita inspeccionar los metadatos de la aplicación y el payload para estas características del archivo:
El motor evalúa el tipo de archivo y verifica si coincide con la lista soportada de archivos para inspección de contenido.
Luego se finaliza la identificación de la aplicación gen3 para identificar las firmas de contenido específicas para los campos que almacenan el contenido y los datos que se inspeccionan.
Se inspecciona el contenido y se verifica si coincide con el perfil de contenido definido.
Anti-Malware y NG Anti-Malware
Los motores Anti-Malware y SentinelOne NG Anti-Malware escanean los archivos adjuntos en el tráfico entrante (descarga de archivos) para detectar malware conocido y desconocido. El tipo_de_archivo se basa en la respuesta HTTP o la solicitud para el tráfico FTP.
Solo se escanean las aplicaciones y servicios HTTP, HTTPS y FTP.
El motor verifica si la aplicación coincide con una regla en la política de Anti-Malware.
El archivo se compara con estas listas de archivos:
La Lista de Permitidos configurada en la Aplicación de Gestión de Cato: estos archivos están permitidos para descargar.
La lista de bloqueo gestionada por el equipo de Seguridad de Cato: estos archivos están bloqueados.
Los archivos son escaneados por los motores Anti-Malware y NG Anti-Malware, y se devuelve el veredicto: malicioso, sospechoso o benigno.
La acción adecuada para la política de Anti-Malware se aplica al archivo.
Preguntas Frecuentes sobre Políticas y Motores de Cato
¿El Filtrado de URLs se aplica al tráfico WAN?
No, el Filtrado de URLs es solo para tráfico de Internet y no se aplica al tráfico de cuenta sobre la WAN.
¿Cuál es la diferencia entre la configuración de Restricción Geo para el cortafuegos vs. las políticas IPS?
La configuración de Dispositivo en los cortafuegos WAN e Internet te permite definir el país de origen para las reglas granulares. Sin embargo, no hay control sobre el país de destino.
La pestaña Restricción Geo en la política IPS define el tráfico restringido que es ya sea el origen o el destino. Sin embargo, IPS es una política global para toda la cuenta y no puedes aplicar la configuración de restricción geo a sitios o objetos específicos.
Detalles del Ejemplo de Flujo TCP
Cronología - Primer paquete
Campos disponibles - 5-tuple, nombre de host (dname)
Motor Cato - Cortafuegos, Red, IPS/SAM
Datos de flujo de tráfico - Identificación de Aplicación, Clase de Cliente, OS
Cronología - handshake_tls
Campos disponibles - cipher_suite, nombre de host (SNI)
Motor Cato - IPS/SAM, App Control gen2, TLSi, Cortafuegos, Red
Datos de flujo de tráfico - Identificación de Aplicación, Clase de Cliente, URLF
Cronología - cabeceras_HTTP
Campos disponibles - headers, URL, nombre de host (cabecera del host)
Motor Cato - App Control gen3, IPS/SAM
Datos de flujo de tráfico - Tipo_de_Archivo (upload), OS
Cronología - cuerpo_HTTP
Campos disponibles - solicitud_HTTP, cuerpo_HTTP
Motor Cato - App Control gen3, DLP, IPS/SAM
Datos de flujo de tráfico - Tipo_de_Archivo (upload), Identificación de Aplicación
Cronología - respuesta_HTTP
Campos disponibles - cabeceras_respuesta_HTTP, cuerpo_respuesta_HTTP
Motor Cato - AM/NGAM, App Control gen3, DLP, IPS/SAM
Datos de flujo de tráfico - Tipo_de_Archivo (download), Identificación de Aplicación