Entendiendo el Flujo de Paquetes con la Arquitectura Cato SPACE

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).

Descripció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

SPACE_Flow.png

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.

  1. 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.

  2. 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

  3. 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.

  4. 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.

Simple_network.png

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.

Azure_FW.png

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 sobre categorías, vea Trabajando con Categorías.

Inspección 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:

  1. 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

  2. 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:

  1. El motor evalúa el tipo de archivo y verifica si coincide con la lista soportada de archivos para inspección de contenido.

  2. 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.

  3. 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.

  1. El motor verifica si la aplicación coincide con una regla en la política de Anti-Malware.

  2. El archivo se compara con estas listas de archivos:

    1. La Lista de Permitidos configurada en la Aplicación de Gestión de Cato: estos archivos están permitidos para descargar.

    2. La lista de bloqueo gestionada por el equipo de Seguridad de Cato: estos archivos están bloqueados.

  3. Los archivos son escaneados por los motores Anti-Malware y NG Anti-Malware, y se devuelve el veredicto: malicioso, sospechoso o benigno.

  4. 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

  1. Cronología - Primer paquete

    1. Campos disponibles - 5-tuple, nombre de host (dname)

    2. Motor Cato - Cortafuegos, Red, IPS/SAM

    3. Datos de flujo de tráfico - Identificación de Aplicación, Clase de Cliente, OS

  2. Cronología - handshake_tls

    1. Campos disponibles - cipher_suite, nombre de host (SNI)

    2. Motor Cato - IPS/SAM, App Control gen2, TLSi, Cortafuegos, Red

    3. Datos de flujo de tráfico - Identificación de Aplicación, Clase de Cliente, URLF

  3. Cronología - cabeceras_HTTP

    1. Campos disponibles - headers, URL, nombre de host (cabecera del host)

    2. Motor Cato - App Control gen3, IPS/SAM

    3. Datos de flujo de tráfico - Tipo_de_Archivo (upload), OS

  4. Cronología - cuerpo_HTTP

    1. Campos disponibles - solicitud_HTTP, cuerpo_HTTP

    2. Motor Cato - App Control gen3, DLP, IPS/SAM

    3. Datos de flujo de tráfico - Tipo_de_Archivo (upload), Identificación de Aplicación

  5. Cronología - respuesta_HTTP

    1. Campos disponibles - cabeceras_respuesta_HTTP, cuerpo_respuesta_HTTP

    2. Motor Cato - AM/NGAM, App Control gen3, DLP, IPS/SAM

    3. Datos de flujo de tráfico - Tipo_de_Archivo (download), Identificación de Aplicación

¿Fue útil este artículo?

Usuarios a los que les pareció útil: 11 de 12

0 comentarios