Alto descriptor en chip y uso del búfer de paquetes debido a policy la denegación que resulta en latencia de tráfico y caídas

• Latencia/lentitud observada, en algunos casos pérdida de paquetes para el tráfico que atraviesa a través del Firewall .
• Por lo general, el uso de DataPlane ( DP ) permanece dentro del rango esperado y no hay una gran desviación de la condición de trabajo habitual CPU o "".
• Aumento de flow_policy_deny contadores globales.
• La sesión superior en la ejecución de ingress-backlogs de resource-monitor tiene grp id 2 o grp id 16

> show running resource-monitor ingress-backlogs 
<snip>
-- SLOT: s1, DP: dp0 --
USAGE - ATOMIC: 88% TOTAL: 89%

TOP SESSIONS:
SESS-ID         PCT     GRP-ID  COUNT
2022536315      88%     16      3640

<snip>

• mostrar id de sesión muestra"Mala clave", y su consumo está tomando la mayoría % de on-chip.

> show session id 2022536315

Session      2022536315

            Bad Key: c2s: 'c2s'
            Bad Key: s2c: 's2c'
        index(local):                        : 9270395

• Pico en el descriptor de paquetes en el chip y el uso del búfer de paquetes, ejemplo (de una salida de depuración viva):

> show running resource-monitor second last 5

DP s1dp0:

Resource monitoring sampling data (per second):

CPU load sampling by group:
flow_lookup                    :     3%
flow_fastpath                  :     3%
flow_slowpath                  :     3%
flow_forwarding                :     3%
flow_mgmt                      :     0%
flow_ctrl                      :     3%
nac_result                     :     3%
flow_np                        :     3%
dfa_result                     :     3%
module_internal                :     3%
aho_result                     :     3%
zip_result                     :     3%
pktlog_forwarding              :     9%
lwm                            :     0%
flow_host                      :     3%

CPU load (%) during last 5 seconds:
core   0   1   2   3   4   5   6   7   8   9  10  11  12  13  14  15
       *   0   3   2   2   3   3   3   4   4   2   3   2   3   3   2
       *   0   3   2   2   3   3   3   3   4   2   3   2   3   3   2
       *   0   3   3   2   4   4   3   3   3   2   2   2   3   3   3
       *   0   3   2   2   3   4   3   3   3   2   3   2   3   4   2
       *   0   3   3   2   3   3   3   3   3   2   2   2   3   4   2
core  16  17  18  19  20  21  22  23  24  25  26  27  28  29  30  31
       2   2   2   2   2   3   3   3   3   3   3   3   3   3   3   3
       2   2   2   2   2   3   3   3   3   3   3   3   3   3   3   3
       2   3   2   2   2   3   3   3   2   4   3   3   2   3   3   2
       2   3   2   2   2   3   2   3   2   3   3   3   2   3   3   3
       2   2   2   2   2   2   2   3   3   3   3   3   3   3   3   3
core  32  33  34  35  36  37  38  39  40  41  42  43  44  45  46  47
       3   2   2   2   2   2   3   2   2   2   2   2   3   2   4   9
       3   2   2   2   2   2   2   2   2   2   2   2   3   2   4   9
       3   2   2   3   2   2   2   2   2   2   2   2   3   2   4   9
       3   2   2   2   3   2   2   2   2   2   2   2   3   2   4   9
       3   2   3   2   2   2   3   2   2   2   2   2   3   2   4   9

Resource utilization (%) during last 5 seconds:
session:
  0   0   0   0   0 
packet buffer:
 14  13  13  13  12 
packet descriptor:
  0   0   0   0   0 
packet descriptor (on-chip):
100 100 100 100 100
<snip>

• PAN-OS
• Zona de protección
• DOS Protección

> show running resource-monitor ingress-backlogs 
<snip>
-- SLOT: s1, DP: dp0 --
USAGE - ATOMIC: 88% TOTAL: 89%

TOP SESSIONS:
SESS-ID         PCT     GRP-ID  COUNT
2022536315      88%     16      3640

<snip>

> show session id 2022536315

Session      2022536315

            Bad Key: c2s: 'c2s'
            Bad Key: s2c: 's2c'
        index(local):                        : 9270395

• Si un paquete entrante no coincide con una sesión existente, se somete a slowpath.
• Si el paquete hace juego una denegación policy en la ruta lenta (con el registro de sesión habilitado), el paquete se cae y se crea una entrada del registro de tráfico, pero no se instala una sesión.
• El siguiente paquete con las mismas 6 tuplas iría a través de la misma trayectoria que el paquete anterior.
• slowpath, como su nombre indica, puede tomar un mayor número de ciclos de procesamiento, porque es en este paso que se realizan todas las tareas asociadas con el establecimiento de una sesión.
• El tiempo que se tarda en completar la ruta lenta depende de la configuración y del patrón Firewall de tráfico.
• Por ejemplo, si hay un gran número de directivas nat o de seguridad, el tiempo que se tarda en completar slowpath sería mayor.
• Todos los paquetes con las mismas 6 tuplas se someten o ATOMIC el procesamiento de paquetes serie en el orden entrante(uno a la vez).
• Como estos paquetes tienen que ser procesados en serie, no se pueden enviar a diversos núcleos o subprocesos para el procesamiento paralelo.
• Como los paquetes están esperando ser procesados por el DP CPU , dependiendo de la velocidad entrante de los paquetes y el tiempo tomado para completar la ruta lenta para cada paquete, puede haber acumulación de paquetes.
• Si hay una velocidad/cantidad significativa de tal mismo tráfico de 6 tuplas golpeando el Firewall , siendo negado en slowpath, los descriptores en el chip y eventualmente los buffers de paquetes se pueden llenar.
• En este punto usted comenzaría a ver los problemas de tráfico.

• Una vez que usted ha determinado que la policy negación es significativamente alta o es más alta de lo habitual, el siguiente paso es identificar la fuente de este tráfico.
• Si "Registro en el final de la sesión" se habilita en la policy denegación del tráfico, el tráfico "ofensivo" se puede encontrar filtrando los registros de tráfico para policy -deny.

• Antes de pasar a las técnicas de mitigación, debemos asegurarnos de que el tráfico que se supone que se permite está permitido por las políticas de seguridad.
• Si es necesario permitir el tráfico, cree la seguridad policy necesaria. Una vez permitido el tráfico, se instalaría una sesión y el tráfico no se somete a la ruta lenta.
• Si no se conoce el patrón de tráfico en la red, se puede crear una seguridad policy para permitir el tráfico de alto volumen como syslog de las zonas internas/de confianza (aplique los perfiles de seguridad según sea necesario).

• Si se conocen las IPs exactas de los hosts que causan el problema, crear un DoS policy con la acción "Denegar" ayudará.
• Las reglas DoS policy son específicas (zona de origen/destino, IP, puerto de servicio) y pueden reemplazar una seguridad similar policy con la denegación de acciones.
• Puesto que las directivas DoS se evalúan antes de la búsqueda de seguridad policy y no tienen un gran número de entradas, los paquetes se bloquean antes, ahorrando así los firewall recursos.

• Creación de un DoS clasificado policy con la acción "Proteger"
• A clasificado DoS policy se puede aplicar con la acción "Protect" y la dirección coincide con "source-ip only"o "src-dest-ip-both".

• Una vez alcanzado el umbral configurado, el DoS policy crearía una tabla de ip-block del DoS, que comenzaría a caer los paquetes sin ser sometido a la ruta lenta.
• En los dispositivos que tienen un procesador de descarga, la tabla de bloques se instalaría en la descarga hardware para reducir aún más la carga en el archivo DP CPU .
• Para obtener más información: Supervisar la lista de bloqueos y los perfiles y reglas de protección Policy doS

• Los umbrales para el objeto DoS clasificado cambiarían en función del patrón de tráfico del cliente y la red, es posible que los valores predeterminados no sean aplicables a todos los entornos.
• Para slowpath negar ataques solamente "source-ip only" o "src-dest-ip-both" funcionaría, el uso de "solo destination-ip" no ayuda.
• Para las zonas orientadas a Internet, ya que las ips de origen podrían ser potencialmente enormes, firewall el no tiene la capacidad de almacenar contadores para cada dirección posible en IP Internet.
• Consulte: Perfiles doS clasificados vs agregados

• Packet Buffer Protection ( PBP ) es una característica disponible a partir de PAN-OS 8.0.
• PBP es preferible, ya que es automático y se activa en función de la utilización real de los recursos, en comparación con DoS policy que se desencadena en las conexiones preconfiguradas por segundo umbral
• PBP protege el firewall agotamiento del búfer de trayectoria lenta y vía rápida (sesión existente).
• Firewall supervisa automáticamente a los abusadores del búfer.
• Después de alcanzar el umbral de activación configurado (predeterminado 50%), el firewall comienza a caer el tráfico ofensivo ( RED ).
• Si la utilización del búfer está por encima del 80% (este umbral está codificado internamente y no es configurable) durante una duración del tiempo de retención de bloque, se crea una entrada de tabla de dos bloques.
• Refiera: Protección del búfer de paquetes

Contadores relacionados con DoS a través SNMP de (parte PAN-COMMON-MIB de):
 

Refiera a la mirada detallada en el CLI "show running resource-monitor ingress-backlogs" para más detalles sobre el comando.

¿Por qué vemos 'Bad Key' al ejecutar el id <id> </id> de sesión de demostración de la sesión obtenido de los atrasos de entrada?
Puesto que en esta etapa la sesión SESS-ID aún no está instalada, el valor bajo es un valor interno tag y no el id de sesión real.
En este caso specifc de denegación de ruta lenta, si examina cuidadosamente los valores en SESS-ID , el valor es mucho mayor que el rango de índice de sesión. (Lo cual por sí mismo es una pista.
Por lo tanto, cuando usted utiliza el id de la sesión de la demostración <idx>puesto que el valor no es un id de sesión real usted ve 'Mala clave'.

¿Por qué necesitamos ATOMIC o procesamiento de paquetes en serie (a la vez)?</idx>

• Cada etapa de procesamiento de paquetes tiene requisitos diferentes en términos de si se debe someter al procesamiento de paquetes serie (uno a la vez en el orden entrante) o al procesamiento paralelo de paquetes para una tupla/sesión 6 determinada.
• El objetivo del procesamiento de paquetes serie es evitar que varios núcleos/subprocesos realicen la misma operación o accedan/escriban en los mismos datos.
• Por ejemplo, si recibimos una ráfaga de nuevo tráfico que debe pertenecer a la misma sesión, no queremos que varios núcleos/subprocesos realicen la instalación de la sesión, por lo tanto no procesamos los paquetes en paralelo, sino que los sometemos al procesamiento en serie.

• Como se explicó anteriormente, puesto que las mismas 6 tuplas niegan el tráfico está sujeto al procesamiento en serie, es posible que la mayoría de los núcleos estén esperando a que se procese el trabajo/los paquetes.
• Por lo tanto, el CPU uso sería bajo, pero los recursos del búfer de paquetes y del descriptor en el chip podrían llenarse.

• A cada flow_fastpath de grupo, flow_slowpath, etc., se le asigna un id de grupo (grp id)
• grp id 2 y 16 representan slowpath/ flow_slowpath
• En modelos más hardware antiguos (Por ejemplo: PA-3000 , PA-5000 etc.) y en el caso de modelos más antiguos de PA-7000 la serie se vería NPC grp id 2
• En los modelos más nuevos hardware (Por ejemplo, PA-5200 , ) y en el caso de los modelos más nuevos de la serie se vería PA-3200 PA-7000 NPC grp id 16