Solución de problemas de dos ataques
Resolution
Un ataque de denegación de servicio (dos) es un ataque destinado a cerrar una máquina o un recurso de red, lo que lo hace inaccesible para los usuarios previstos. Por favor, lea más acerca de DoS en ¿Qué es un ataque de denegación de servicio?
Este artículo da una idea de cómo solucionar algunas situaciones debido a los ataques de DoS de Firewall. Este artículo asume que conoce los perfiles de protección de DoS/zonas y comprueba el uso de recursos:
1. Tabla de sesión llena
Esto se puede ver en los casos en que el tráfico de DoS está permitido por las directivas de Firewall. Si el atacante puede encontrar IPS y puertos abiertos mediante barrido IP o técnicas de escaneo de puertos, puede iniciar un ataque de inundación. En el caso de TCP, una respuesta de la víctima conduce a una sesión que se instala en el cortafuegos por 3600 segundos. Más adelante, más de este tipo de paquetes SYN llevarán a la tabla de sesiones llena, causando así que el tráfico legítimo se vea afectado.
Tenga en cuenta que en estos casos, la tasa de ataque de inundación puede o no ser alta.
Permitir bypass asimétrico o desactivar TCP-rechazar-no-SYN puede empeorar la situación, ya que conducirá a cualquier paquete TCP para instalar una sesión en el Firewall si la Directiva y el enrutamiento lo permiten.
Solucionar problemas de la tabla de sesión completa
- En este tipo de casos, la mejor manera sería tomar un volcado de la tabla de la sesión y hojear a través de él. En la mayoría de los casos, una determinada IP de origen o una IP dirigido se destacan. Utilice el comando "Mostrar todas las sesiones" para el mismo
- Compruebe si la IP y el puerto de destino identificados, o el origen del tráfico es válido y debe permitirse a través del cortafuegos. Si es así, podemos restringir las reglas del firewall.
- Sobre todo en estos casos la mitigación es la mejor manera. Debe implementar perfiles de protección de zona y protección de dos para mitigar estos casos. El modo de cookie SYN en la protección SYN FLOOD puede ser muy útil para lidiar con estas situaciones, ya que evitará que Firewall Instale una sesión y enviará un paquete SYN/ACK al atacante. A menos que el atacante responda con un ACK válido, la sesión no se establecerá.
- El umbral del mecanismo de protección contra inundaciones SYN debe sintonizarse con requisitos específicos después de analizar la tasa de conexión normal a la IP de destino.
2. Búfer de paquetes/descriptores de paquetes completos
Esto se puede ver en ataques DoS con alta tasa de paquetes/datos. Puede ser debido a la alta tasa de nuevas conexiones por segundo o alta tasa de paquetes en las sesiones existentes. Incluso si los conexiones están siendo denegados, no impedirá que el búfer esté lleno, ya que los paquetes deben ser tamponados y antes de enviarlos al plan de proceso de procesamiento.
Cómo solucionar problemas:
- Compruebe las fichas ACC e intente utilizar filtros personalizados para ver si hay un tráfico en particular que sea excepcionalmente superior al del otro tráfico. Sin embargo, la ficha ACC no proporciona una buena información contra el ataque continuo. Razón de ser, que toma su feed del Resumen de tráfico, las bases de datos de registro de tráfico y la base de appstats.
Si el ataque está sucediendo a través de una sesión en curso, no habría generado un registro de tráfico todavía.
Si el ataque se compone de nuevas conexiones, la ficha ACC podría no ser capaz de mostrar las sesiones que de todos modos se están consiguiendo errores.
Consejos y trucos: Cómo utilizar el centro de comando de aplicaciones (ACC)consejos y trucos: FAQ ACC pan-os 7,0
Video Tutorial: como usar el centro de comando de aplicaciones (ACC) (ACC)Tips & Trucos: FAQ ACC pan-os 7,0
Compruebe si hay sesiones en vivo con más datos de los habituales. Utilice la opción min-KB en el filtro de sesión como en:
admin @ PA-200 > Mostrar sesión todos los filtros min-KB 5000
--------------------------------------------------------------------------------
IDENTIFICADOR de estado del tipo de solicitud de identificación src [Sport]/Zone/proto (traducido IP [puerto])
Vsys DST [dport]/Zone (traducido IP [puerto])
--------------------------------------------------------------------------------
10216PCOIPflujo activoNS 10.1.1.11 [50002]/Trust/17(10.129.15.24 [61158])
vsys110.101.41.211 [4172]/Untrust(10.101.41.211 [4172])
Lo anterior es sólo un ejemplo, se puede utilizar el valor de min-KB como en cualquier lugar entre 1-1048576, es decir, casi hasta 1G. Esto puede proporcionar una visión de las sesiones con una tasa de tráfico superior. Busca algo sospechoso.
Puede utilizar lo siguiente para buscar sesiones que estén sobreutilizando el búfer:
Identifique las sesiones que utilizan un porcentaje excesivo del búfer de paquetes
Compruebe la tasa de tráfico en vivo en las interfaces y averigüe qué interfaz está recibiendo tráfico excesivo. Utilice Mostrar navegador de estado del sistema para el mismo que se resalta en el siguiente artículo: Cómo comprobar el rendimiento de las interfaces.
Compruebe todos los puertos relevantes según su configuración.
Debe centrarse en los RX-bytes/s o RX-unicast/s o RX-multicast/s. Esta es la velocidad que se muestra en la segunda columna cuando se habilita el seguimiento mediante ' y ' y ' U '.
Después de identificar el puerto en el que se está recibiendo el tráfico de ataque, tendrá que tomar un volcado de paquetes cortos del tráfico que se recibe en ese puerto.
Se recomienda hacer esto en un switch conectado mediante un puerto que refleje el tráfico, ya que las capturas de paquetes podrían ser más intensivas en recursos.
Sin embargo, si no hay otra opción disponible, habilite las capturas en el cortafuegos de Palo Alto Networks con filtro como entrada-interfaz como se identificó anteriormente y ejecute las capturas durante 10-15 segundos.
Detenga las capturas y ábrala con Wireshark. En Wireshark buscar bajo estadísticas-> jerarquía de protocolos o conversaciones . Compruebe la conversación sobre la capa IP, la capa UDP, la capa TCP y compruebe si hay tráfico que tenga un conteo de paquetes alto.
Esto puede ayudar a identificar y aislar al atacante (de confianza o de no confianza). Sobre todo para fuentes de confianza, puede realizar un seguimiento del host afectado y tomar acciones.
Para una fuente no confiable, usted puede pedir ayuda de su ISP para ayudar a prevenir la fuente de ataque.