Optimización de políticas: informes de gestión de reglas


    La subsección de Optimización de políticas en Firewall Analyzer proporciona una vista de todos los informes de optimización de políticas de Firewall. Se puede acceder a esta sección desde el enlace Policy Optimization en la ruta Reports - >> Rule Management.

    Consulte la página Compatibilidad con informes de administración de reglas para ver la lista de dispositivos de firewall.

    En la subsección de optimización de políticas, obtiene una variedad de informes de anomalías de políticas, que lo ayudarán a optimizar el rendimiento de las políticas de firewall.

     Firewall Analyzer ofrece un conjunto exhaustivo de informes de anomalías de políticas de firewall en la sección de optimización de políticas.

    Los informes de anomalías de la política son específicos del dispositivo de firewall, por lo tanto, seleccione un dispositivo en particular. Si el dispositivo no está configurado o asociado a un perfil de información del dispositivo para generar estos informes, se puede configurar desde aquí sobre la marcha. Puede actualizar el informe de anomalías con el enlace Actualizar . Puede programar la generación del informe de anomalías con el enlace Programar . Puede exportar el informe de anomalías visibles en formato PDF con Exportar como: enlace PDF .

     Los informes de optimización de políticas

     Los informes de anomalías de la gestión de reglas son Correlación, Generalización, Agrupación, Redundancia y Sombra . Los informes se mostrarán en formato gráfico y tabular.

     Optimización de políticas

     Clasificación de anomalías

     

     

    1. Anomalía de las sombras 

    • Una regla se sombrea cuando una regla anterior coincide con todos los paquetes que coinciden con esta regla, de modo que la regla sombreada nunca se evaluará. Si se elimina la regla sombreada, la política de seguridad no se verá afectada
    • La regla Rx está sombreada por la regla Ry si Rx sigue a Ry en el orden, y Rx es una coincidencia de subconjunto de Ry y las acciones de Rx y Ry son diferentes
    • Esto puede provocar que se bloquee un tráfico permitido y viceversa. De ahí que sea una anomalía. Es importante descubrir reglas sombreadas y alertar al administrador que podría corregir este error reordenando o eliminando la regla sombreada.

     Ejemplo:

    Fuente Destino Servicio Acción
    10.0.0.1-10.0.0.10 20.0.0.1-20.0.0.10 http, https Permitir
    10.0.0.5 20.0.0.3 http Negar

     En este caso, la segunda regla nunca se verá afectada. Está ensombrecido. Además, la acción es diferente para ambas Reglas.

    2. Anomalía de redundancia

    • Una regla redundante realiza la misma acción en los mismos paquetes que otra regla, de modo que si se elimina la regla redundante, la política de seguridad no se verá afectada.
    • La regla Rx es redundante para la regla Ry si Rx es una coincidencia de subconjunto de Ry y las acciones de Rx y Ry son similares
    • Si se elimina, el efecto de la política resultante no se modificará.
    • La redundancia se considera un error. Es posible que una regla redundante no contribuya a tomar la decisión de filtrado, sin embargo, aumenta el tamaño de la tabla de filtrado y puede aumentar los requisitos de tiempo y espacio de búsqueda. Es importante descubrir reglas redundantes para que el administrador pueda modificar su acción de filtrado. o eliminarlo por completo

     Las reglas de sombra y redundantes son más o menos similares. Si Action difiere, es sombra; de lo contrario, es redundante.

    Caso 1 (R1 es un subconjunto / igual a R2) : El administrador puede eliminar R1
    Caso 2 (R2 es un subconjunto de R1) : El administrador puede eliminar R2

    Ejemplo:

    Fuente Destino Servicio Acción
    10.0.0.1-10.0.0.10 20.0.0.1-20.0.0.10 http, https Permitir
    10.0.0.5 20.0.0.3 http Permitir

     
    3. Anomalía de correlación

    • Dos reglas están correlacionadas si tienen diferentes acciones de filtrado, y la primera regla coincide con algunos paquetes que coinciden con la segunda regla y la segunda regla coincide con algunos paquetes que coinciden con la primera regla.
    • La regla Rx y la regla Ry tienen una anomalía de correlación si Rx y Ry están correlacionados y las acciones de Rx y Ry son diferentes
    • Si se invierte el orden de las dos reglas, se cambiará el efecto de la política resultante

     Ejemplo:

    Fuente Destino Servicio Acción
    10.0.0.5 20.0.0.1-20.0.0.10 http, https Permitir
    10.0.0.1-10.0.0.10 20.0.0.3 http Negar

     En el ejemplo anterior, en la Regla 1, se permite el tráfico HTTP de 10.0.0.5 a 20.0.0.3. Si reordena esto moviendo la segunda hacia arriba y la primera regla hacia abajo, se bloqueará el tráfico HTTP de 10.0.0.5 a 20.0.0.3. El efecto de la política ha cambiado.
    La correlación se considera una advertencia de anomalía y no se requiere sugerencia. Esta anomalía debe ser manejada explícitamente por el administrador del firewall.

    4. Anomalía de generalización: 

    • Una regla es una generalización de otra regla si la primera regla coincide con todos los paquetes que la segunda podría coincidir, pero no al revés.
    • La regla Rx es una generalización de la regla Ry, si Rx sigue a Ry en el orden y Rx es un superconjunto de Ry y las acciones de Rx y Ry son diferentes
    • Si se invierte el orden de las dos reglas, se cambiará el efecto de la política resultante

     Ejemplo:

    Fuente Destino Servicio Acción
    10.0.0.5 20.0.0.3 http Permitir
    10.0.0.1-10.0.0.10 20.0.0.1-20.0.0.10 http, https Negar

     En el ejemplo anterior, la regla 2 es una generalización de la regla 1. Si se invierte el orden de las dos reglas, el efecto de la política resultante cambiará y la regla 1 dejará de ser efectiva, ya que quedará ensombrecida por la regla 2 Como pauta general, si hay una relación de coincidencia inclusiva entre dos reglas, la regla de superconjunto (o general) debe ir después de la regla de subconjunto (o específica).
    La generalización se considera solo una advertencia de anomalía porque al insertar una regla específica se hace una excepción a la regla general. El administrador del cortafuegos debe encargarse de ello.

    5. Agrupación de reglas 

     Esta no es una anomalía estándar. Es uno adicional proporcionado por Firewall Analyzer

    • Se pueden agrupar dos reglas si y solo si las acciones de ambas reglas son las mismas y cualquier componente entre el origen, el destino y el servicio varía entre esas dos reglas y todos los restantes son iguales.
    • Digamos que Rx y Ry tienen el mismo destino, servicio y solo la fuente difiere (la fuente difiere significa que no es un subconjunto ni un superconjunto), entonces la sugerencia es agrupar ambas reglas definiendo un objeto de red para ambas redes de origen y puede redefinir una regla usándola .

     Ejemplo:

    Fuente Destino Servicio Acción
    10.0.0.11-10.0.0.20 20.0.0.1-20.0.0.10 http, https Permitir
    10.0.0.1-10.0.0.10 20.0.0.1-20.0.0.10 http, https Permitir

    El administrador puede crear un objeto de red con algún nombre que diga 'InternalTest' y puede eliminar ambas reglas y volver a crearlo como se muestra a continuación:

    Fuente Destino Servicio Acción
    Prueba interna (o) 10.0.0.1-10.0.0.20  20.0.0.1-20.0.0.10 http, https Permitir

     donde InternalTest - 10.0.0.11-10.0.0.20 y 10.0.0.1-10.0.0.10 o en lugar de crear un nuevo objeto de red, se sugiere agrupar dos reglas con la fuente como '10 .0.0.1-10.0.0.20 '.

     

    Enlaces destacados