Fundamentos de la política de seguridad
Resolution
Fundamentos de la política de seguridad
Tabla de contenidos
- Resumen
- Dos tipos de políticas de seguridad
- Sesiones
- Topología
- Servicio "aplicación predeterminada"
- Observación de las normas
- Políticas de seguridad basadas en usuarios
- Políticas de seguridad con direcciones IP NAT
- Categorías de URL en las políticas de seguridad
- Dependencias de las aplicaciones y cambios de uso
- Descifrado y la identificación de la aplicación
- Regla de limpieza
- Consejos de seguridad de la política
- Documentos relacionados
Resumen
Este documento describe los fundamentos de las políticas de seguridad en el firewall de Palo Alto Networks.
Todo el tráfico atraviesa el dataplane del firewall Palo Alto Networks se compara con una política de seguridad. No incluye tráfico origina de la interfaz de administración de servidor de seguridad, porque, por defecto, este tráfico no pasa por el dataplane del firewall. Las políticas de seguridad del servidor de seguridad pueden definirse utilizando varios criterios como zonas, aplicaciones, direcciones IP, puertos, usuarios y perfiles de cadera. Los administradores de Firewall pueden definir políticas de seguridad para permitir o denegar el tráfico, a partir de la zona como un criterio amplio, a continuación, ajuste las políticas con opciones más detalladas tales como puertos, aplicaciones y perfiles de cadera.
Dos tipos de seguridad policies
El firewall tiene dos clases de políticas de seguridad:
- Las políticas de seguridad explícitos son definidos por el usuario y visible en interfaz CLI y la interfaz de usuario Web.
- Las políticas de seguridad implícito son reglas que no son visibles para el usuario a través de interfaz Web-UI o interfaz CLI. La siguiente sección discute las políticas de seguridad implícito en Palo Alto Networks firewalls.
Políticas de seguridad implícita
De forma predeterminada, el firewall implícitamente permite tráfico intrazona (origen y destino en la misma zona) e implícitamente niega tráfico de la inter-zona (entre zonas). Tráfico permitido o negado por las políticas implícitas no se loguean en el firewall por defecto, así que no hay registros se pueden encontrar para este tráfico. Para ser registrado por el firewall, el tráfico tiene que coincidir con una política de seguridad explícitamente configurado en el cortafuegos. Sin embargo, para propósitos de solución de problemas, el comportamiento predeterminado se puede cambiar. Consulte: Cómo ver el tráfico de las directivas de seguridad predeterminadas en los registros de tráfico.
Sesiones
El cortafuegos de Palo Alto Networks es un cortafuegos con estado, lo que significa que todo el tráfico que pasa a través del cortafuegos se compara con una sesión y que cada sesión se compara con una directiva de seguridad.
Una sesión consta de dos flujos. El cliente de flujo (flujo de c2s) de servidor y el servidor de flujo de cliente (s2c flujo). El extremo donde inicia el tráfico siempre es el cliente, y el extremo donde está destinado el tráfico es el servidor. Para la definición de las políticas de seguridad, sólo el c2s flujo de dirección deben ser considerados. Definir políticas que permitan o denegar el tráfico de la zona de origen a la zona de destino, es decir, en la dirección de c2s. El flujo de retorno, s2c, no requiere una nueva regla. La evaluación de la política de seguridad en el firewall se produce secuencialmente de arriba a abajo en la lista, por lo que tráfico que empareja la primera regla más cercano en la lista se aplica a la sesión.
Aquí está un ejemplo de cómo identificar los flujos en una sesión de CLI:
> Mostrar id de sesión 107224
Sesión 107224
flujo de C2S:
Fuente: 172.23.123.5 [prueba]
Horario de verano: 172.23.123.1
Proto: 50
deporte: 37018 dport: 37413
Estado: tipo activo: TUNN
usuario fuente: desconocido
usuario de DST : desconocido
flujo s2c:
Fuente: 172.23.123.1 [prueba]
Horario de verano: 172.23.123.5
Proto: 50
deporte: 37750 dport: 50073
Estado: tipo activo: TUNN
usuario fuente: desconocido
usuario de DST : desconocido
Topología
En este documento, la siguiente topología aplica para casos de políticas de seguridad de uso:
Servicio "aplicación predeterminada"
En el ejemplo siguiente, las políticas de seguridad permitirán y denegar el tráfico que coincide con los criterios siguientes.
- Regla A: todas las aplicaciones iniciadas desde la zona de confianza en IP subred 192.168.1.0/24 destinado a la zona Untrust debe ser en cualquier puerto de origen y de destino.
- Regla B: las aplicaciones, DNS, debe permitir la navegación por Internet, el tráfico FTP iniciado desde la zona de confianza de la IP 192.168.1.3 destinada a la zona Untrust.
- Las aplicaciones debe limitarse a utilizar sólo en los puertos de "aplicación predeterminada". Por ejemplo, el uso de DNS, de forma predeterminada, utiliza destino puerto 53. Así que se debe permitir la aplicación DNS sólo en este puerto. Usando esta aplicación en los restantes puertos de destino debe ser negado.
- Regla C: deben bloquear todas las demás aplicaciones de 192.168.1.3 a la zona Untrust.
- Regla D: debe bloquearse todo el tráfico iniciado desde la zona Untrust a cualquier zona.
La columna de servicio de las políticas de seguridad define los puertos de origen y de destino donde se debe permitir el tráfico. Las cuatro opciones son:
- Default dela aplicación: para permitir tráfico en los puertos de destino predeterminados.
Consulte el siguiente documento para obtener más detalles acerca de cómo encontrar los puertos de destino predeterminados utilizados por varias aplicaciones:
consulte: Cómo ver los puertos predeterminados de la aplicación para una aplicación. - Cualquier: para permitir el tráfico en cualquier puerto fuente y destino.
- Servicios predefinidos: servicios que ya están definidos en el firewall.
- Servicios personalizados: los administradores pueden definir los servicios según sus requerimientos de puerto de aplicación.
El ejemplo muestra las reglas que se crean para que coincida con los criterios anteriores.
Al confiar los cambios de configuración anteriores, aparecen las siguientes advertencias de sombra:
A continuación se discuten el impacto de las advertencias de la sombra y consejos para evitarlos.
Observación de las normas
En el ejemplo anterior, la dirección IP 192.168.1.3 pertenece a la zona de confianza y cae en la subred 192.168.1.0/24. Puesto que el firewall hace una búsqueda de políticas de seguridad de arriba a abajo, todo el tráfico de IP 192.168.1.3 regla A y se aplicará al período de sesiones. Aunque el tráfico también satisface los criterios de la regla B y C de la regla, estas normas no se aplicarán a este tráfico porque es sombra regla A regla de B y C. de la regla
Para evitar los efectos de sombreado, norma B y C de la regla deben preceder A la regla, como se muestra a continuación. Ahora el tráfico de partidos contra la normativa correcta y previene "advertencias de la sombra" durante la confirmación.
Políticas de seguridad basadas en usuarios
En el ejemplo anterior, las políticas se escriben basados en direcciones IP. De la misma manera, usuarios LDAP, grupos LDAP y los usuarios definidos localmente en los servidores de seguridad también pueden ser utilizados en las políticas de seguridad. Consulte los siguientes documentos para obtener más información sobre cómo configurar ID de usuario y agregar los usuarios a las políticas de seguridad:
Cómo agregar grupos a la política de seguridad
Políticas de seguridad con direcciones IP NATed
Esta sección explica cómo escribir las políticas de seguridad cuando una traducción de direcciones IP está implicado y también cómo utilizar categorías de URL en las políticas de seguridad para el control de varios sitios Web.
En el ejemplo siguiente, se definen las políticas de seguridad para que coincida con los siguientes criterios:
IP pública 192.0.2.1 en la zona Untrust se traduce a IP privada 10.1.1.2 del servidor Web en la zona DMZ.
- Tráfico entrante de la zona Untrust a servidor Web 10.1.1.2 en la zona DMZ se debe permitir en el puerto 25, 443 y 8080 solo.
- Todos los usuarios de la zona de confianza deben negársele el acceso a sitios web de categoría "Adultos y la pornografía" en la zona Untrust.
- Se debe permitir todo el otro tráfico de la zona Trust con la zona Untrust.
Las reglas a continuación muestran la configuración para satisfacer los criterios anteriores.
Todo el tráfico destinado al servidor Web de la zona Untrust tendrá una IP pública destino de 192.0.2.1, perteneciente a la zona Untrust. Puesto que el tráfico es originario de la zona Untrust y destinado a una IP en la zona Untrust, este tráfico es permitido por una regla implícita que permite el mismo tráfico de la zona. Después de la búsqueda de políticas de seguridad, el firewall hace una búsqueda de política NAT y determina que la IP pública del servidor Web debe se traducen en privado IP 10.1.1.2, situado en la zona DMZ. En esta etapa, el firewall tiene la zona de destino final (DMZ), pero la traducción real de la IP 10.1.1.2 de 192.0.2.1 no sucede todavía. Después de determinar la información de la zona de destino final para el tráfico de NAT post, el Firewall realiza una segunda búsqueda de directivas de seguridad para encontrar una política que permita el tráfico destinado a la zona de destino final, DMZ. Así, X de la regla anterior se configura para permitir el tráfico de correos NAT. Cuenta que X regla DMZ (zona Post-NAT) como la zona de destino y el 192.0.2.1 (Pre-NAT IP) como la dirección IP de destino. En el ejemplo anterior, un servicio de "Web-server_Ports" está configurado para permitir el puerto de destino 25, 443 y 8080. Para obtener más información, consulte: Cómo configurar una directiva para utilizar un rango de puertos.
Categorías de URL en las políticas de seguridad
En el ejemplo anterior, la regla Y está configurado para bloquear sitios web categoría adultos utilizando la opción de la categoría de URL presente en las políticas de seguridad. Aplicación de navegación por la web debe mencionarse explícitamente en las políticas cuando se utiliza la opción de la categoría de URL en las políticas de seguridad. De lo contrario, tráfico irrelevante con concuerden con esta regla. Otra forma de control de sitios web basado en categorías de URL es utilizar perfiles de filtrado de URL.
Dependencias de las aplicaciones y cambios de uso
Esta sección habla de "dependencia de la aplicación" y describe lo que sucede en la sesión cuando el id de aplicación cambia en medio de una sesión.
En el ejemplo siguiente, se definen las políticas de seguridad para permitir y denegar el tráfico que coincide con los criterios siguientes.
- Aplicaciones Gotomeeting, se debe permitir el Youtube de la zona de confianza a la zona Untrust.
- Aplicaciones Facebook, se debe permitir Gmail-base de la zona de huéspedes a la zona Untrust.
- Aplicaciones SSL y navegación por la Web deben ser bloqueado para los usuarios de la zona de invitados.
El ejemplo muestra las reglas que se crean para que coincida con los criterios anteriores.
Mientras que cometer la configuración cambia, pueden verse las siguientes advertencias de dependencia de uso.
Aplicaciones como Gotomeeting y YouTube son identificados inicialmente como SSL, navegación web y Citrix. Más paquetes para estas sesiones paso a través del cortafuegos, más información para identificar la aplicación está disponible para el servidor de seguridad. El firewall entonces cambia de puesto la aplicación a las respectivas aplicaciones como Gotomeeting y Youtube.
Cada vez que ocurre un cambio de uso, el firewall hace una nueva búsqueda de política de seguridad para encontrar la regla más que la nueva aplicación. Así que en el caso anterior, SSL y navegación por la web se llaman las aplicaciones dependientes de Gotomeeting y YouTube, así estas aplicaciones también se deben permitir en las políticas de seguridad. Si la aplicación del tráfico cambia en el medio de la sesión, una segunda búsqueda de directiva de seguridad reempareja el tráfico contra las directivas de seguridad para encontrar la nueva Directiva coincidente más cercana.
En el ejemplo anterior, una nueva política de seguridad, "Regla de dependencia Apps" se crea para permitir que el SSL y la navegación por la web. Tráfico de YouTube inicialmente coincide con esta regla y una vez ocurre el cambio de uso, una segunda búsqueda de política de seguridad contra el artículo 10.
Desde pan-os 5,0, las aplicaciones para algunos protocolos pueden ser permitidas sin la necesidad de permitir explícitamente sus dependencias (vea: Cómo comprobar si una aplicación necesita haber permitido explícitamente aplicaciones de dependencia). En el ejemplo anterior, Facebook y gmail-base son este tipo de aplicaciones que dependen de SSL y navegación por la web y no necesita sus aplicaciones dependencia expresamente autorizadas.
Descifrado y la identificación de la aplicación
Ciertas aplicaciones como Vimeo, que utilizan SSL y se cifran, pueden identificarse por el firewall sin descifrado de SSL. Sin embargo, aplicaciones como YouTube, que hacen uso de SSL, necesitan ser descifrados por el firewall para su identificación. Puesto que se cifran las conexiones SSL, el firewall no tiene ninguna visibilidad en este tráfico con el fin de la identifican. La hace de servidor de seguridad utiliza el campo Nombre común presente en el certificado para la identificación de la aplicación. Esto se intercambia en texto durante el proceso de handshake SSL.
Sitios web como Vimeo utiliza el nombre de la URL de la página web como un nombre común y así no necesita descifrado de SSL para ser configurado. Algunos sitios web como YouTube usa un certificado con nombre comodín como el nombre común. En el caso de YouTube, *. google.com. Así que no es posible utilizar esta información para la identificación de la aplicación, y descifrado de SSL debe configurarse para obtener visibilidad en la dirección URL de la Página Web. Consulte el siguiente documento sobre cómo implementar y probar el descifrado SSL
Regla de limpieza
Algunos entornos requieren todo el tráfico denegado y permitido por el firewall. De forma predeterminada, se registra sólo el tráfico que está explícitamente permitido por el firewall. Para registrar el tráfico que está permitido por las reglas implícitas del cortafuegos, consulte:
Cualquier/cualquiera/negar seguridad regla cambios comportamiento predeterminado
Cómo ver el tráfico de las políticas de seguridad predeterminada en los registros de tráfico
Consejos de seguridad de la política
Los siguientes criterios está marcada por el firewall en el mismo orden para que coincida con el tráfico contra una política de seguridad.
- Dirección de origen y destino
- Puertos de origen y destino
- Aplicaciones
- ID de usuario
- Categoría de la URL
- Zonas de origen y de destino
En el ejemplo anterior de configuración, cuando la aplicación "navegación por Internet" en el puerto TCP 80 de la zona Trust con la zona Untrust atraviesa el cortafuegos, una búsqueda de seguridad se realiza de la siguiente manera:
- Dirección de origen/destino - regla puesto que A, B y C tienen "alguna" fuente y direcciones de destino, el tráfico coincide con todas estas reglas.
- Puertos de origen y destino - regla puesto que A, B y C tienen "cualquiera" de los servicios, el tráfico coincide con todas estas reglas.
- Aplicaciones - como regla A y B tienen aplicaciones "navegación en la web", el tráfico coincide con estas reglas.
- ID-usuario - no es aplicable aquí.
- Categoría de URL - no es aplicable aquí.
- Zonas de origen y de destino - ya que el tráfico es entre confianza y Untrust, regla A se elige para este tráfico.
La forma óptima de configurar políticas de seguridad es minimizar el uso de "cualquier" y ser específico con los valores, siempre que sea posible. Esto reduce las búsquedas de política de seguridad innecesarios realizadas por el equipo de Palo Alto Networks.
Documentos relacionados
¿Hay un límite al número de perfiles de seguridad y políticas por el dispositivo?
Cómo identificar las políticas sin usar en un dispositivo de redes de Palo Alto
A prueba cual política de seguridad se aplica a un flujo de tráfico.
¿Por qué son reglas negar aplicaciones permitiendo algunos paquetes?
¿Por qué "No aplicable" aparece en los registros de tráfico?
Cómo identificar las políticas sin usar en un dispositivo de redes de Palo Alto
Cómo funciona la sesión revancha
Cómo uso predeterminado en los cambios de la base de reglas es comparable el tráfico de manera
Cómo programar acciones de política
Administración de directivas de seguridad con Panorama
Sesión Registro mejores prácticas
Propietario: sdurga