Comprendiendo el flujo de paquetes con la arquitectura SPACE de Cato

Este artículo explica el flujo de paquetes para los motores de seguridad en el PoP basado en la arquitectura Single Pass Cloud Engine de Cato (SPACE).

Visión general

La arquitectura SPACE de Cato examina y procesa los flujos de tráfico con un único servicio. Este servicio incluye múltiples motores de red 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 la concatenación de servicios. El único pase para un flujo minimiza la latencia y mejora el rendimiento general de la red. Cada PoP puede realizar estas decisiones de red y seguridad usando todos los servicios y motores SPACE de Cato.

Los motores de seguridad y red tienen acceso completo a los datos para el flujo de tráfico y simultáneamente evalúan y comparten 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 información. Cuando un motor diferente identifica el dispositivo como macOS, entonces el firewall bloquea el flujo de acuerdo con la acción de la regla.

Resumen de Servicios de Red 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 del paquete.

  • 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 enrute y prioridad de QoS

    • IPS/SAM - Protecciones IPS y Monitoreo de Actividad Sospechosa (SAM)

    • Control de Aplicaciones - Identificación de aplicaciones para la política de Control de Aplicaciones

      • Control de Aplicaciones gen2 - Reglas para aplicaciones basadas en acceso: permitir o bloquear

      • App Control gen3 - Reglas para aplicaciones basadas en acciones granulares: subir, 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 - Escaneo de Anti-Malware y Anti-Malware de próxima generación de archivos adjuntos para malware

  • Datos de flujo de tráfico y protocolos

    • Identificación de aplicaciones - Se utilizan varios criterios para identificar la aplicación específica para políticas de seguridad o de red

    • Sistema operativo (OS) para el dispositivo, por ejemplo, con la política Device Posture o Client Connectivity

    • Tipo de cliente - Tipo de aplicaciones cliente que se ejecutan en el sistema operativo que creó este flujo de red (por ejemplo, Chrome)

    • URLF - Filtrado de URL para categorías de Cato basado en la URL de la página web

    • File_type - Para CASB y DLP, archivo adjunto en la dirección de carga o descarga

Flujo de paquetes TCP con SPACE

Este es un ejemplo de un flujo HTTP típico con los siguientes elementos:

  • Línea de tiempo - Diferentes fases del flujo de tráfico

  • Campos disponibles - Datos disponibles para la fase específica de la línea de tiempo

  • 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 del ejemplo de flujo TCP.

Ejemplo de identificación de aplicaciones desde 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

    Source - 10.10.2.107
    Source port - 55477
    Dest IP - 3.68.124.168
    Dest port - 443
    Protocol - TCP
    DNS response - 3.68.124.168 - slack.com  (respuesta opcional)

    Esta es la información de flujo de tráfico disponible basada en este paquete inicial de muestra:

    • 5 tupla - 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 nombre de dominio 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 la aplicación incluye: tcp

    El motor espera información adicional del handshake TLS antes de poder completar la identificación de la aplicación Slack.

  2. tls_handshake

    "Encabezado TLS"
    "sni_host": "slack.com"
    "razón del bypass de inspección predefinida": "ninguna"
    "ja3_formatted_str": "771,4865-4866-4867-49195-49199-49196-4920…"

    Esta es la información de flujo de tráfico disponible basada en este handshake TLS de muestra:

    • Encabezado TLS y puerto del servidor 443 - coincide con el protocolo TLS

    • SNI es slack.com - coincide con la identificación de la aplicación Slack de Cato

      El SNI también se envía a la URLF, y coincide con las categorías Información Empresarial, Computación y Tecnología, Social

    • Tipo de cliente es JA3 - clasifica al cliente como un navegador basado en la huella digital TLS

    • Inspección TLS o acción de bypass - basada en el tipo de cliente y la identificación de la aplicación

    • La identificación de la aplicación incluye: tcp, tls, slack

  3. HTTP

    "url" : "upload.slack.com:
    "host_name" : "slack.com"
    "Content-Type" : "application/pdf"
    "Content-Disposition" : form-data; name="file"; filename="sample-data.pdf"
    "Content-Length" : "52765"

    En este flujo de muestra, la siguiente información está disponible basada en los datos HTTP:

    • La identificación de la aplicación incluye: tcp, tls, http, slack

    • La inspección TLS descifra el flujo e identifica que el nombre de host del servidor Slack es slack.com

    • Encabezado HTTP - coincide con el protocolo HTTP

      Este es un ejemplo común donde 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

    • Content-Type, Content-Disposition, Content-Length - proporcionan 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 arrendatario 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 propio archivo"

    Por ejemplo, la política DLP aplica que no se puede utilizar información de tarjeta de crédito en mensajes de Slack.

    • La identificación de la aplicación está completada 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 y motores de Cato que analizan y actúan sobre el flujo de tráfico.

Políticas de firewall y red

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 necesitan datos adicionales del flujo de tráfico para que el motor evalúe el flujo. Esto significa que la fase en la que 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 del firewall, consulte Mejores Prácticas para Políticas de Firewall de Internet y WAN.

Ejemplo de primer paquete para regla de red simple y regla de firewall compleja

Este ejemplo muestra cómo los motores PoP evalúan un flujo de tráfico de manera diferente para una regla de red simple que utiliza 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.

Ejemplo de regla de red

La siguiente regla de red es para tráfico con el Origen como 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 de 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.

Ejemplo de regla de firewall WAN

La siguiente regla de firewall WAN permite el tráfico que tiene el mismo Origen que el rango de IP para la regla de red anterior, y para usuarios que son miembros del grupo de usuarios de I+D. 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, aplicaciones de Azure y servicios para el flujo. Después de que el motor finaliza la evaluación y el flujo cumple con todos los criterios, entonces el motor permite el flujo. El PoP también aplica la decisión de enrutamiento basada en el primer paquete.

Filtrado de URL y categorías de Cato

El servicio de filtrado de URL 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 sitio web para determinar sus categorías, como contenido para adultos, juegos de azar, redes sociales o medios de transmisión.

Para más información sobre las categorías, consulte Trabajando con Categorías.

Inspección TLS

El motor de Inspección TLS está involucrado durante la fase tls_handshake 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 es completamente analizado, y se aplica la acción de la política de Inspección TLS (inspeccionar o ignorar 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 de firewall o IPS correcta al usuario final.

IPS

El motor IPS sigue funcionando durante la vida útil 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 IPS como actuando como una lupa, esperando constantemente actualizaciones del tráfico y proporcionando continuamente información al motor que se vio en el flujo.

El siguiente ejemplo muestra diferente información que está 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 la suite 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 acción en el flujo de tráfico en esa fase.

Protección DNS

La Protección DNS es parte del motor IPS y se ejecuta en el flujo DNS para la solicitud y respuesta (sin ninguna conexión al transporte, por ejemplo, TCP o UDP).

Durante la solicitud DNS, el nombre del dominio se analiza y evalúa para la reputación del dominio y feeds estáticos. Luego durante la respuesta DNS, la IP resuelta y el contenido se analizan en busca de contenido potencialmente malicioso. La política de Protección DNS se aplica a cualquier contenido coincidente (bloquear o permitir el flujo de tráfico).

Control de Apps

El motor de Control de Apps inspecciona el tráfico y aplica las acciones de la política de Control de Aplicaciones, y se evalúa en cada nueva transacción HTTP (solicitud y respuesta).

Para apps gen2, se requieren TLS y proxy HTTP para completar la identificación de la app.

Para reglas que incluyen requisitos de seguridad y cumplimiento:

  • Basado en datos contextuales de otros motores de networking y seguridad, el motor de Control de Apps puede evaluar estos requisitos durante la fase de inspección_tls

  • También es posible que el motor pueda obtener esta información del SNI, y no requiera TLS o identificación completa de Apps (DPI de capa 7) para evaluar la app

DLP

El motor DLP inspecciona el contenido del flujo de tráfico y es una extensión del motor de Control de Apps. Cuando la política especifica un tipo de archivo o tamaño de archivo, entonces el motor necesita inspeccionar los metadatos de la app 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 de archivos soportados para inspección de contenido.

  2. Luego se finaliza la identificación de la app 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 NG Anti-Malware de SentinelOne escanean archivos adjuntos en el tráfico entrante (descarga de archivos) para malware conocido y desconocido. El file_type se basa en la respuesta HTTP o la solicitud para el tráfico FTP.

Solo se escanean 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 permisos configurada en la Aplicación de Gestión Cato - estos archivos pueden descargarse.

    2. La lista de bloqueos gestionada por el equipo de seguridad de Cato - estos archivos se bloquean.

  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 apropiada de la política de Anti-Malware se aplica al archivo.

FAQ para Políticas y Motores de Cato

¿Aplicar el Filtrado de URL al tráfico WAN?

No, el Filtrado de URL es solo para el tráfico de Internet y no se aplica al tráfico de cuenta a través de la WAN.

¿Cuál es la diferencia entre la configuración de Restricción Geográfica para políticas de firewall vs IPS?

La configuración de Dispositivo en los firewalls de WAN e Internet le 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 de Restricción Geográfica en la política IPS define tráfico restringido que es o bien la fuente o el destino. Sin embargo, IPS es una política global para toda la cuenta, y no puede aplicar la configuración de restricción geográfica para sitios u objetos específicos.

Detalles del Flujo TCP de Muestra

  1. Línea de tiempo - Primer paquete

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

    2. Motor de Cato - Firewall, Red, IPS/SAM

    3. Datos de flujo de tráfico - Identificación de Apps, Clase de Cliente, SO

  2. Línea de tiempo - negociación_tls

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

    2. Motor de Cato - IPS/SAM, Control de Apps gen2, TLSi, Firewall, Red

    3. Datos de flujo de tráfico - Identificación de Apps, Clase de Cliente, Filtro de URL

  3. Línea de tiempo - cabeceras_HTTP

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

    2. Motor de Cato - Control de Apps gen3, IPS/SAM

    3. Datos de flujo de tráfico - Tipo de archivo (carga), SO

  4. Línea de tiempo - cuerpo_HTTP

    1. Campos disponibles - solicitud_HTTP, cuerpo_HTTP

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

    3. Datos de flujo de tráfico - Tipo de archivo (carga), Identificación de Apps

  5. Línea de tiempo - respuesta_HTTP

    1. Campos disponibles - cabeceras_de_respuesta_HTTP, cuerpo_de_respuesta_HTTP

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

    3. Datos de flujo de tráfico - Tipo de archivo (descarga), Identificación de Apps

¿Fue útil este artículo?

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

0 comentarios