Onboarding FAQ - Web Application Firewall - Centro de documentación de Alibaba Cloud

Este artículo enumera los problemas comunes que puede encontrar al incorporar sitios web a Web Application Firewall (WAF) 3.0.

Descripción general

Funciones previas a la incorporación y consultas de configuración
Problemas que puede encontrar durante la incorporación
Problemas que puede encontrar después de la incorporación

¿Cuál es la diferencia entre una dirección IP de origen y una dirección IP back-to-origin en WAF?

IP back-to-origin de WAF: es el rango de direcciones IP que WAF utiliza para reenviar el tráfico protegido a su servidor de origen. Alibaba Cloud asigna estas direcciones, las cuales identifican a WAF como el origen cuando se hacen solicitudes a su servidor.
- El rango de direcciones IP back-to-origin suele ser un conjunto fijo de direcciones IP.
- Desde la perspectiva del servidor de origen, WAF intercepta y reenvía todas las solicitudes de los clientes. La dirección IP real del cliente se registra en un campo de encabezado HTTP, como X-Forwarded-For, o en un encabezado personalizado.
IP de origen: es la dirección IP pública del servidor de backend que aloja realmente su negocio, o bien la dirección IP que se resuelve desde su dominio. Es el destino que finalmente recibe las solicitudes y devuelve las respuestas cuando los usuarios acceden al sitio web.
- Una IP de origen puede ser una sola dirección IP o varias direcciones IP (con compatibilidad con balanceo de carga).
- La IP de origen es la dirección de servicio real de su sitio web. Puede estar desplegada en Alibaba Cloud ECS, SLB, OSS u otro proveedor de nube.

¿Un mismo dominio puede usar simultáneamente la incorporación de productos de nube y la incorporación por CNAME?

No se recomienda. Cada dominio solo admite un modo de incorporación: ya sea mediante productos de nube o por CNAME. Incorporar el mismo dominio dos veces genera conflictos de reenvío y deshabilita la protección. Si necesita cambiar un dominio que WAF ya protege mediante incorporación por CNAME hacia la incorporación de productos de nube, primero elimine la configuración de incorporación por CNAME de ese dominio y, después, vuelva a incorporarlo en el modo de producto de nube.

¿WAF protege varias direcciones IP de servidores de origen bajo un solo dominio?

Sí. Puede configurar hasta 20 direcciones IP de origen para un solo dominio de WAF.

¿WAF comprueba el estado de los servidores de origen?

WAF habilita las comprobaciones de estado de forma predeterminada. El servicio verifica la accesibilidad de todas las direcciones IP de origen. Si una IP de origen deja de responder, WAF reenvía las solicitudes a otras direcciones IP de origen que estén disponibles.

Cuando una IP de origen deja de responder, WAF establece automáticamente un periodo de silencio para esa dirección. Una vez que termina dicho periodo, es posible que se sigan reenviando nuevas solicitudes a esa IP con fines de prueba.

¿Una IP exclusiva en WAF mitiga los ataques DDoS?

Una IP exclusiva evita que un ataque DDoS de gran volumen contra un dominio deje inaccesibles todos los demás dominios incorporados. Para obtener más información, consulte Value of exclusive IP addresses.

¿WAF se puede integrar con CDN o Anti-DDoS Proxy?

WAF es totalmente compatible con los servicios CDN y Anti-DDoS Proxy. Cuando se usan en conjunto, configure la dirección CNAME de WAF como origen de Anti-DDoS Proxy o de CDN. De esta manera, el tráfico se reenvía a través de Anti-DDoS Proxy o CDN hacia WAF y, posteriormente, desde WAF hasta el servidor de origen. Esto proporciona una seguridad integral para su origen. Para obtener más información, consulte Protect a website service by using Anti-DDoS Proxy and WAF y Protect a CDN-accelerated domain with WAF.

¿WAF admite el uso de arquitecturas CDN + Anti-DDoS Proxy + WAF entre cuentas?

Sí. Puede utilizar CDN, Anti-DDoS Proxy y WAF en distintas cuentas de Alibaba Cloud para construir una arquitectura de seguridad contra ataques DDoS y ataques a aplicaciones web.

¿Cómo garantiza WAF la seguridad de los certificados y las claves privadas cargadas? ¿WAF descifra el tráfico HTTPS y registra el contenido de las solicitudes?

Para proteger el tráfico HTTPS, Alibaba Cloud WAF requiere que cargue el certificado SSL y la clave privada correspondientes. Esto permite descifrar el tráfico HTTPS y detectar firmas de ataque. Utilizamos un Key Server dedicado para almacenar y gestionar los certificados y las claves. Este Key Server se basa en Alibaba Cloud Key Management Service (KMS), lo cual garantiza la seguridad, la integridad y la disponibilidad de sus datos conforme a los requisitos normativos y de protección clasificada. Para obtener detalles sobre KMS, consulte What is Key Management Service?.

WAF usa el certificado SSL y la clave privada que usted cargó únicamente para descifrar el tráfico HTTPS y detectarlo en tiempo real. Solo registramos las partes de las solicitudes que contienen firmas de ataque (payloads) para generar informes de ataques y análisis estadísticos. No registramos el contenido completo de las solicitudes ni de las respuestas sin su autorización.

Alibaba Cloud WAF ha obtenido múltiples certificaciones internacionales reconocidas, entre ellas ISO 9001, ISO 20000, ISO 22301, ISO 27001, ISO 27017, ISO 27018, ISO 27701, ISO 29151, BS 10012, CSA STAR, Classified Protection Level 3, SOC 1/2/3, C5, HK Finance, OSPAR y PCI DSS. Al ser un producto estándar de Alibaba Cloud, WAF cuenta con las mismas calificaciones de cumplimiento de seguridad que la plataforma de Alibaba Cloud a nivel de plataforma en la nube.

Mi sitio web está protegido por WAF, pero no aparece en la lista de dominios

Es posible que el registro ICP de su dominio haya caducado. Esto incumple los requisitos de incorporación y provoca que WAF lo elimine automáticamente. Debe completar el registro ICP del dominio y volver a incorporarlo a WAF. Para obtener información sobre el registro ICP de Alibaba Cloud, consulte ICP filing process.

Importante

Antes de incorporar su sitio web a una instancia de WAF en China continental, asegúrese de que el dominio cuente con un registro ICP válido. Para cumplir con las leyes y normativas aplicables, las instancias de WAF en China continental eliminan periódicamente los dominios cuyo registro ICP ha caducado.

¿Cómo obtiene WAF la dirección IP de origen del cliente y cómo registra la IP del cliente mediante un encabezado personalizado?

Obtener la IP de origen del cliente desde un encabezado personalizado: si su sitio web tiene otros servicios de proxy de capa 7 antes de WAF (como Anti-DDoS Proxy o CDN), utilice un encabezado personalizado para transportar la IP del cliente. Esto evita que los atacantes falsifiquen el campo XFF para evadir las reglas de detección de WAF y mejora la seguridad del negocio. Coloque la IP de origen del cliente en un campo de encabezado personalizado (por ejemplo, X-Client-IP o X-Real-IP) y configure WAF para que lea dicho campo. WAF usará el valor del campo de encabezado especificado como la IP de origen del cliente. Si configura varios campos de encabezado, WAF intentará leer la IP del cliente en ellos de forma secuencial.

Registrar la IP del cliente en un encabezado personalizado: al agregar un sitio web a WAF, habilite el marcado de tráfico para que WAF escriba la IP del cliente en un encabezado personalizado dentro de la solicitud del cliente. Así, el servidor de backend podrá leer la IP del cliente desde el campo de encabezado especificado en la solicitud back-to-origin. Este método resulta útil cuando el servidor de backend necesita obtener la IP del cliente desde un encabezado personalizado específico para analizar el negocio.

¿Cuál es la diferencia entre Anti-DDoS y WAF Protection en una instancia de ALB? ¿Debería habilitar ambas funciones?

Web Application Firewall (WAF) y la protección Anti-DDoS son dos funciones de seguridad independientes y complementarias. A continuación se describen sus diferencias principales:

WAF: protege principalmente contra amenazas de la capa de aplicación (L7), como SQL injection, ataques de cross-site scripting (XSS) y ataques CC. Para habilitar esta protección, actualice la instancia de ALB a "ALB WAF Enhanced Edition". Esta acción genera cargos adicionales. Para obtener más información, consulte Enable WAF protection for an ALB instance.
Protección Anti-DDoS: protege principalmente contra ataques volumétricos en las capas de red y de transporte (L3/L4). Las instancias de ALB proporcionan protección básica Anti-DDoS gratuita de forma predeterminada. Si el tráfico de ataque supera el umbral de blackhole, compre y asocie una EIP de Anti-DDoS (Enhanced). Para obtener más información, consulte Associate an Anti-DDoS (Enhanced) EIP with an ALB instance.

Configure estas funciones según los riesgos de seguridad a los que se enfrenta su aplicación. Si busca una defensa integral en profundidad tanto en la capa de red como en la de aplicación, habilite ambas funciones de protección.

¿WAF admite la incorporación para el protocolo TCP de capa 4?

WAF permite habilitar la protección para el tráfico de los protocolos HTTP y HTTPS que escuchan los puertos de CLB de capa 4 (TCP) y de las instancias de ECS. Sin embargo, no admite el reenvío ni la protección del tráfico en puertos que utilizan otros protocolos distintos de HTTP o HTTPS.

Como firewall de aplicaciones web, WAF protege principalmente el tráfico web, es decir, el tráfico HTTP y HTTPS. Por lo tanto, cuando el tráfico que supervisa un puerto de CLB de capa 4 (TCP) o de una instancia de ECS es tráfico web, WAF proporciona protección de reenvío. No obstante, si la instancia de producto de nube de capa 4 maneja tráfico de otros protocolos de capa de aplicación (como FTP o SMTP), WAF no puede reenviar dicho tráfico.

¿Cómo exportar de forma masiva la lista de información de dominios incorporados mediante CNAME?

Llame a la API DescribeInstance para obtener el ID de su instancia de WAF y, a continuación, llame a la API DescribeDomains para consultar la lista de todos los dominios incorporados mediante CNAME.

Durante la incorporación por CNAME, ¿cómo aplica WAF el balanceo de carga a un origen de tipo dominio (como un CNAME)?

En el modo de incorporación por CNAME, cuando su origen tiene varias direcciones de servidor, seleccione distintas opciones de Load Balancing Algorithm para que WAF reenvíe las solicitudes back-to-origin a los servidores correspondientes y logre el balanceo de carga.

Cuando Server Address se establece en Domain Name (Such as CNAME) y la resolución de este dominio devuelve varias direcciones IP, WAF distribuye las solicitudes de los clientes entre dichas direcciones IP resueltas. Si introduce varios dominios, WAF expande todos los resultados de resolución y aplica el balanceo de carga entre ellos.

Sin embargo, si introduce un solo dominio y cada resolución de dominio devuelve únicamente una dirección IP, WAF no aplica balanceo de carga y solo reenvía el tráfico back-to-origin al único resultado resuelto.

El mismo nombre de dominio se resuelve a varias instancias de productos de nube. ¿Cómo debo realizar la incorporación?

Incorporación de productos de nube: debe incorporar todas estas instancias de productos de nube de forma simultánea (por ejemplo, los puertos de servicio de una instancia de CLB) para que WAF redirija el tráfico a todas ellas.

Incorporación por CNAME: después de incorporar el dominio mediante CNAME, todas las instancias de productos de nube quedan protegidas por la directiva de protección predeterminada de WAF.

Varios nombres de dominio se resuelven a la misma instancia de producto de nube. ¿Cómo debo realizar la incorporación?

Incorporación de productos de nube: después de incorporar la instancia de producto de nube, todos los dominios de dicha instancia quedan protegidos automáticamente por la directiva predeterminada de WAF. No obstante, si desea configurar reglas de protección independientes para cada dominio, agregue manualmente cada dominio como objeto protegido. Para obtener más detalles, consulte Manually add a protected object.

Incorporación por CNAME: incorpore cada dominio de forma individual.

¿Qué sufijos de nombres de dominio se admiten para la incorporación por CNAME?

WAF 3.0 admite la mayoría de los sufijos de nombres de dominio, incluidos los sufijos de dominios chinos. Para consultar la lista completa de sufijos chinos compatibles, visite iana.org.

WAF 3.0 admite más sufijos de dominio que WAF 2.0. Si un sufijo de dominio no es compatible con WAF 2.0, le recomendamos actualizar a WAF 3.0.

¿WAF admite la autenticación mutua HTTPS (mTLS)?

La incorporación por CNAME y la incorporación transparente no admiten la autenticación mutua HTTPS. La solución de incorporación basada en servicios de WAF 3.0 sí la admite. Actualmente, los productos de nube que admiten la incorporación basada en servicios incluyen ALB, MSE, FC y SAE. Configure esta opción en la sección de incorporación de productos de nube de la consola de WAF.

¿WAF admite los protocolos WebSocket, HTTP/2 o SPDY?

Protocolo WebSocket: se admite el reenvío de tráfico, pero no se proporciona protección de seguridad.
Protocolo HTTP/2: se admiten la escucha y el retorno al origen.
Protocolo SPDY: no es compatible.

Para evitar que los atacantes utilicen el contrabando de texto claro HTTP/2 (h2c) y evadan WAF, cree una regla personalizada que intercepte las solicitudes donde el nombre del Header sea Upgrade y el valor sea h2c. Para obtener más detalles, consulte Create a custom rule to defend against specific requests.

¿WAF admite sitios web que usan la autenticación del protocolo NTLM?

No. Si un sitio web utiliza la autenticación del protocolo NTLM, las solicitudes de acceso que reenvía WAF pueden fallar en la autenticación NTLM del servidor de origen. Esto provoca que el cliente muestre mensajes de autenticación repetidos. Le recomendamos usar un método de autenticación distinto para su sitio web.

¿El límite de QPS de WAF se aplica a toda la instancia de WAF o a cada dominio de forma individual?

El límite de QPS de WAF se aplica a toda la instancia de WAF.

Por ejemplo, si configura tres dominios en una instancia de WAF, la suma de sus QPS no debe superar el límite especificado. Si el QPS excede el límite de la instancia de WAF que adquirió, la instancia podría entrar en un sandbox. Cuando el QPS real supera la especificación o la instancia entra en un sandbox, WAF deja de garantizar el cumplimiento del Acuerdo de Nivel de Servicio (SLA).

¿Una instancia de WAF adquirida admite la migración fluida a otra cuenta de Alibaba Cloud?

Las instancias de WAF no admiten la migración directa y fluida a otras cuentas de Alibaba Cloud. Si necesita utilizar WAF entre cuentas, aplique una de las siguientes soluciones alternativas:

Cancelar la suscripción y volver a comprar: cancele la suscripción para liberar la instancia de WAF de la cuenta actual y, después, vuelva a adquirirla en la cuenta de destino.
Gestión unificada de varias cuentas: utilice la función Multi-account management para gestionar la cuenta de destino desde el sistema de WAF de la cuenta actual.

¿Cómo consultar los rangos de direcciones IP back-to-origin de WAF y el CNAME que proporciona WAF?

Encontrará los rangos de direcciones IP back-to-origin de WAF y las direcciones CNAME que WAF proporciona para cada dominio incorporado en la ubicación que muestra la siguiente figura, dentro de la página de la lista de incorporación.

Troubleshooting when the CLB instance, NLB instance, or ECS instance you want to onboard is not found on the onboarding configuration page

Causa posible	Acción relacionada
La instancia de CLB, NLB o ECS que desea incorporar no cumple con las condiciones de incorporación.	Compruebe la instancia con respecto a las condiciones de incorporación. Para obtener más detalles, consulte CLB instance onboarding conditions, NLB instance onboarding conditions y ECS instance onboarding conditions.
La instancia de CLB que desea incorporar no tiene configurado el listener correspondiente.	Para agregar un listener en una instancia de CLB de capa 7, consulte Add an HTTP listener y Add an HTTPS listener. Para agregar un listener en una instancia de CLB de capa 4, consulte Add a TCP listener.
WAF no ha sincronizado la instancia de CLB, NLB o ECS.	Para conocer los pasos necesarios para sincronizar activos manualmente, consulte Manually sync assets.

Al agregar un puerto de redirección de tráfico HTTPS, se muestra el mensaje "CLB certificate is incomplete". ¿Cómo solucionarlo?

Síntoma

Cuando agrega un puerto de redirección de tráfico HTTPS, WAF valida el origen del certificado de ese puerto. Después de agregar el puerto, puede aparecer el siguiente mensaje: The CLB certificate for port XXX is incomplete. Please reselect a certificate from the SSL Certificate Service in the CLB console.

Causas posibles

El certificado no se adquirió a través de Certificate Management Service (Original SSL Certificate) de Alibaba Cloud y no se ha cargado en Certificate Management Service (Original SSL Certificate) de Alibaba Cloud.
El certificado del listener del puerto HTTPS en la instancia de CLB se cargó a través de la consola de CLB. Sin embargo, este método de carga no sincroniza automáticamente la información del certificado con Digital Certificate Management Service (anteriormente SSL Certificate Management). Dado que WAF solo recupera la información de los certificados desde Digital Certificate Management Service, esto genera el mensaje certificate is incomplete.
Se eliminó manualmente un certificado que previamente se había cargado en Digital Certificate Management Service, por lo que Certificate Management Service (Original SSL Certificate) ya no contiene su certificado.

Solución

Cargue su certificado en Certificate Management Service (Original SSL Certificate). Para conocer los pasos, consulte Upload an SSL certificate.
En la consola de CLB, cree un certificado y seleccione los certificados emitidos por Alibaba Cloud como origen del certificado. Para conocer los pasos, consulte Use a certificate from Alibaba Cloud SSL Certificates Service.
En la consola de CLB, seleccione el certificado de servidor que cargó. Para conocer los pasos, consulte Step 2: Configure the SSL certificate.

Para la dirección IP de origen en WAF, ¿debo usar la IP pública o la IP privada de una instancia de ECS?

Use la IP pública. WAF realiza el retorno al origen a través de la red pública y no admite direcciones IP privadas.

¿Por qué falla la adición de varios certificados extendidos durante la incorporación de productos de nube?

Una causa posible es que uno de los certificados no sea válido. Al agregar varios certificados extendidos, asegúrese de que cada certificado seleccionado sea válido. Los certificados caducados provocarán que la adición falle.

Después de incorporar un producto de nube a WAF, ¿todavía necesito configurar objetos protegidos?

De forma predeterminada, cuando un producto de nube se incorpora a WAF, el servicio genera automáticamente un objeto protegido y no se requiere configuración adicional. Sin embargo, si varios dominios se resuelven a la misma instancia de producto de nube y desea configurar reglas de protección independientes para cada dominio, agregue manualmente cada dominio como objeto protegido. Para obtener más detalles, consulte Add a protected object.

Después de agregar los objetos protegidos, seleccione el dominio correspondiente como objeto efectivo al configurar las reglas de protección. De esta manera logrará una protección detallada para varios dominios.

Durante la incorporación por CNAME, ¿por qué se muestra ERR_TOO_MANY_REDIRECTS después de configurar el retorno al origen por HTTP?

El retorno al origen por HTTP significa que WAF utiliza el protocolo HTTP para reenviar las solicitudes back-to-origin al servidor de origen, y el puerto back-to-origin predeterminado es el 80. Después de habilitar esta función, sin importar si el cliente accede a WAF por el puerto 80 o el 443, WAF usa de forma predeterminada el protocolo HTTP y el puerto 80 para el retorno al origen. Si el puerto 80 de su servidor de origen no aloja ningún negocio real, habilitar esta función causará problemas de acceso al sitio web.

Si el puerto 80 del servidor de origen no aloja ningún negocio real y tiene configurada una redirección (por ejemplo, devolver un código de estado 301 para redirigir al puerto 443), el acceso del cliente se redirigirá continuamente y mostrará el error ERR_TOO_MANY_REDIRECTS.

¿Por qué ocurre el error InvalidTLS al incorporar una instancia de CLB mediante la incorporación de productos de nube?

When onboarding a CLB instance via cloud product onboarding, the error Waf.Pullin.InvalidTLS (invalid TLS) may appear. Es probable que esto ocurra porque la instancia de CLB es una instancia de rendimiento compartido. WAF no admite la obtención de información de configuración TLS para instancias de rendimiento compartido. Debe cambiar la instancia a una de rendimiento garantizado para que se admita la incorporación de productos de nube. For more information, see CLB instance types.

La IP pública de mi servidor de origen está expuesta. ¿Cómo evito que los atacantes evadan WAF atacando directamente la IP pública de origen?

Método 1: en el modo de incorporación por CNAME, configure su servidor de origen para aceptar tráfico únicamente desde los rangos de direcciones IP back-to-origin de WAF. Esto garantiza que solo WAF pueda comunicarse con el servidor de origen. Para obtener más detalles, consulte Allow WAF back-to-origin IP ranges.

Método 2: utilice la incorporación de productos de nube.

Varios escenarios de errores 502 después de la incorporación a WAF

Síntoma

Después de la incorporación a WAF, el acceso al servicio de backend devuelve un código de estado 502. También es posible que los registros muestren solicitudes con este mismo código.

Causas y soluciones

Escenario 1: error 502 en el modo de incorporación CNAME

En el modo de incorporación CNAME, se produce un error 502 cuando WAF no puede comunicarse con el servidor de origen (por ejemplo, una instancia ECS o CLB). Se recomienda revisar las reglas del security group del servidor de origen, iptables, el firewall o el software de seguridad (como Safedog o Yunsuo) que puedan bloquear el acceso de WAF. Por ejemplo, podría ser necesario Allow access from back-to-origin CIDR blocks of WAF en su security group de ECS.

También debe asegurarse de que el nombre de dominio y la información del servidor de origen configurados en la consola de WAF coincidan con su servicio real. Una discrepancia también provoca este error.

Escenario 2: errores 5XX intermitentes con un CLB de capa 7 en el modo de incorporación de productos en la nube

Análisis detallado de la causa

Tiempo de espera de inactividad de la conexión back-to-origin de WAF: 3600 segundos (1 hora).

Descripción: cuando la conexión entre CLB y WAF no transmite datos durante 1 hora, WAF cierra automáticamente la conexión.

Tiempo de espera de inactividad de la conexión orientada al cliente de CLB: 15 segundos.

Descripción: cuando la conexión entre el cliente (en este caso, la instancia WAF) y CLB no transmite datos durante 15 segundos, CLB cierra automáticamente la conexión.

En casos extremos, justo cuando una conexión persistente caduca en el lado de CLB (sin transmisión de datos por más de 15 segundos), WAF reutiliza esa conexión para enviar una nueva solicitud back-to-origin a CLB. Como CLB ya no conserva el estado de la conexión, envía un paquete RST para finalizar la solicitud. Esto genera un registro con código de estado 502 en el lado de WAF.

Solución

Ajuste el parámetro Idle persistent connection timeout en la configuración de incorporación de productos en la nube del CLB de capa 7. Asigne un valor inferior al tiempo de espera de inactividad de la conexión orientada al cliente de CLB; por ejemplo, 14 segundos.

Escenario 3: error 502 intermitente debido a un URI demasiado largo

Análisis detallado de la causa

El CLB de capa 7 es el siguiente salto después de que WAF reenvía el tráfico. Sin embargo, el límite de longitud de URI de CLB es de 32 KB. Cuando el URI de una solicitud de WAF supera la longitud que CLB puede analizar sintácticamente, CLB rechaza atender la solicitud. CLB registra un código de estado 414 y WAF devuelve un código de estado 502.

Solución

Reduzca la longitud del URI. Si la carga útil de datos es grande, utilice POST para transmitirlos.

Escenario 4: error 502 intermitente cuando WAF envía solicitudes back-to-origin a varios CLB de capa 4

Arquitectura de red actual

En esta arquitectura, WAF se incorpora en modo reverse proxy con back-to-origin hacia varias instancias CLB de capa 4. El RealServer (RS) de backend escucha en el mismo puerto y está montado detrás de varias instancias CLB de capa 4.

Análisis detallado de la causa

Cuando una instancia ECS actúa como servidor de backend para varias instancias CLB de capa 4 (protocolo TCP) configuradas con el mismo puerto de servicio de backend, pueden surgir los siguientes problemas: si las solicitudes de un mismo nodo WAF se envían simultáneamente como back-to-origin a instancias CLB mediante la misma dirección IP del nodo de la instancia WAF, algunas conexiones fallan o agotan el tiempo de espera.

Caso 1: conflicto de 5 tuplas, colisión de flujo TCP

Cuando WAF protege varios nodos CLB, las solicitudes de esos nodos pueden originarse desde la misma dirección IP back-to-origin de WAF.

Cuando el nodo WAF envía solicitudes back-to-origin a CLB1, la conexión (WIP:CPORT->VIP1:VPORT1) se convierte en (WIP:CPORT->DIP:DPORT) al llegar a la instancia ECS de backend.
Cuando el nodo WAF envía solicitudes back-to-origin a CLB2, la conexión (WIP:CPORT->VIP2:VPORT2) también se convierte en (WIP:CPORT->DIP:DPORT) al llegar a la instancia ECS de backend.
Como los números de secuencia y los estados de ambas conexiones TCP entran en conflicto en el servidor de backend, el establecimiento de la conexión falla. En concreto, el servidor de backend percibe que las dos conexiones TCP iniciadas tienen la misma 5-tupla (TCP:WIP:CPORT:DIP:DPORT). Este conflicto de 5 tuplas puede provocar que se descarten paquetes SYN.

Caso 2: errores de enrutamiento de paquetes de respuesta

En una ruta de solicitud completa, el nodo CLB que inicia la solicitud difiere del nodo CLB que recibe el paquete de respuesta.

WAF envía el paquete SYN como back-to-origin a través de CLB2, con la 5-tupla WIP:CPORT->VIP1:VPORT1. Al llegar a ECS2 de backend, se convierte en WIP:CPORT->DIP:DPORT.
Si ECS2 tiene una conexión TIME-WAIT en ese momento, la 5-tupla es TCP:WIP:CPORT:DIP:DPORT. Al recibir el paquete SYN del paso 1, ECS2 determina que el SYN es válido y responde con un paquete SYN-ACK.
Dado que ECS2 está montado detrás de varias instancias SLB, puede enviar el paquete SYN-ACK de vuelta a CLB1. Si CLB1 no tiene una sesión para esta 5-tupla, envía un paquete Reset bidireccional, lo que hace que WAF devuelva un 502.

Soluciones

Solución 1 (recomendada)

Modifique la arquitectura de red. Por ejemplo, utilice varias instancias CLB de capa 7 como servidores de origen para evitar que distintos nodos de load balancer CLB de capa 4 reenvíen solicitudes al mismo puerto del mismo servicio de backend.

Solución 2

Migre de CLB a NLB y deshabilite Client IP Affinity en la configuración de NLB para resolver el conflicto de 5 tuplas. Despliegue Proxy Protocol en el servicio de backend para obtener la dirección IP real del cliente. Para más detalles, consulte Use Proxy Protocol.

Pasos

Inicie sesión en la consola de Network Load Balancer (NLB).En la barra de navegación superior, seleccione la región donde se despliega la instancia NLB.
En el panel de navegación izquierdo, elija Network Load Balancer (NLB) > Server Groups.
Seleccione su grupo de servidores y, en la columna Actions, haga clic en Modify Basic Information. En el cuadro de diálogo Modify Basic Information, deshabilite Client IP Preservation y guarde los cambios.

Solución 3 (no recomendada)

Envíe un Tickets para habilitar el modo FULLNAT. Cuando varias instancias CLB reenvían solicitudes al mismo puerto del mismo servidor de backend, FullNAT modifica la dirección de origen. De esta forma, la 5-tupla de cada conexión es única y se evitan conflictos. Habilite el modo FULLNAT en los listeners de CLB para evitar conflictos de 5 tuplas.

Escenario 5: problemas con parámetros del kernel de Linux provocan que las solicitudes devuelvan 502

Algunas versiones antiguas de Linux incluyen el parámetro del kernel net.ipv4.tcp_tw_recycle. Este parámetro quedó obsoleto en versiones más recientes de Linux. Cuando está habilitado, aunque TIME-WAIT se libera más rápido, las nuevas conexiones pueden fallar al establecerse. Por ejemplo, cuando varias máquinas internas acceden mediante SNAT con diferencias de marca de tiempo, pueden producirse fallos de conexión y restablecimientos de solicitudes.

Compruebe si el valor de este parámetro es 1. Si lo es, se recomienda cambiarlo a 0. Para más detalles, consulte Modify parameters.

Error al cargar un archivo después de la incorporación a WAF

Este problema puede deberse a que la carga del archivo supera el límite máximo de 2 GB. Actualmente, WAF admite cargas de archivos de hasta 2 GB. Cuando el cuerpo de la solicitud supera los 2 GB, WAF devuelve un código de estado 413. Utilice el código de estado devuelto para determinar si se alcanzó el límite de tamaño de transferencia de archivos.

¿Cómo actualizar un certificado que está a punto de caducar?

El método de actualización varía según su modo de incorporación:

Para la incorporación CNAME, consulte Update a domain certificate.
Para la incorporación de productos en la nube con instancias ECS, consulte Update the certificate bound to an ECS traffic redirection port.
Para la incorporación de productos en la nube con instancias CLB, consulte Update the certificate bound to a CLB traffic redirection port.
Para la incorporación de productos en la nube con instancias NLB, consulte Update the certificate bound to an NLB traffic redirection port.
Para la incorporación de productos en la nube con instancias ALB, no es necesaria ninguna actualización en la consola de WAF. Simplemente despliegue el certificado en la instancia ALB desde la consola de Digital Certificate Management Service (anteriormente SSL Certificate). Para ver los pasos, consulte Overview of SSL certificate deployment methods.

Después de la incorporación de productos en la nube, ¿el servidor de origen puede obtener la dirección IP real del cliente?

Sí. WAF proporciona la dirección IP real del cliente directamente a la instancia del producto en la nube.

Un escaneo reporta un conjunto de cifrado débil en un dominio incorporado a WAF. ¿Cómo configurar la versión del protocolo TLS y el conjunto de cifrado para cumplir los requisitos de seguridad?

Para garantizar que los sitios web HTTPS incorporados a WAF cumplan con los requisitos de seguridad y conformidad, se recomienda configurar protocolos TLS de versiones altas y conjuntos de cifrado fuertes.

Importante

Los protocolos TLS y conjuntos de cifrado de alta seguridad pueden reducir la compatibilidad con los clientes. Tras la configuración, los usuarios con clientes antiguos (como Internet Explorer) podrían no acceder al sitio web. Evalúe completamente la compatibilidad de los clientes antes de habilitarlos.

Paso 1: determinar la ubicación de la configuración

La entrada de configuración para la versión del protocolo TLS y el conjunto de cifrado depende del modo de incorporación de WAF.

Incorporación CNAME

En el modo de incorporación CNAME, la ubicación de la configuración depende del destino del escaneo. Configúrela en la ubicación correspondiente según el destino específico del escaneo.

Escanear el dominio incorporado: en la pestaña CNAME Record, busque el dominio de destino y haga clic en Edit en la columna Actions. En la página Edit Domain Name, dentro de la sección Protocol Type > HTTPS, expanda Advanced Settings y ubique TLS Version y HTTPS Cipher Suite.
Escanear la VIP de WAF: en la pestaña CNAME Record, haga clic en Default SSL/TLS Settings en el lado derecho, cargue el certificado predeterminado y configure TLS Version y HTTPS Cipher Suite.

Incorporación de productos en la nube

En el modo de incorporación de productos en la nube, configure las instancias ECS, las instancias CLB de capa 4 (cuyo protocolo de escucha es TCP) y las instancias NLB desde el lado de WAF. Para otros escenarios de incorporación de productos en la nube, la configuración debe completarse en sus respectivas consolas de producto.

Nota

Al incorporar una instancia CLB de capa 7 mediante la incorporación de productos en la nube, no se admiten conjuntos de cifrado personalizados. Solo puede seleccionar las directivas de seguridad TLS proporcionadas por el sistema.
Al incorporar una instancia ALB mediante la incorporación de productos en la nube, si necesita personalizar el conjunto de cifrado, debe crear manualmente una directiva de seguridad TLS. Para más información, consulte TLS security policy.

ECS, CLB de capa 4 (protocolo de escucha TCP), NLB: en la pestaña Cloud Native, ubique la instancia de destino, haga clic en el icono , seleccione el puerto de destino y haga clic en Actions en la columna Actions; luego seleccione Modify. Configure los campos TLS Version y Cipher Suite.
ALB: en la consola de ALB, tras ubicar la instancia de destino, vaya a la pestaña Listener, localice el listener de destino y configure TLS Security Policy.
CLB de capa 7 (protocolo de escucha HTTPS): en la consola de CLB, tras ubicar la instancia de destino, vaya a la pestaña Listener, localice el listener de destino, haga clic en Manage Certificates y configure TLS Security Policy en el cuadro de diálogo que aparece.
FC, MSE, APIG, SAE: configure estos servicios en la consola del producto correspondiente.

Paso 2: seleccionar la versión del protocolo TLS

Para evitar riesgos de seguridad derivados de versiones antiguas del protocolo TLS, se recomienda seleccionar TLS 1.2 o posterior. Si su sitio web es compatible con TLS 1.3, seleccione Support TLS 1.3.

Cuando selecciona Support TLS 1.3, WAF proporciona los tres conjuntos de cifrado predeterminados de TLS 1.3 siguientes: TLS_AES_128_GCM_SHA256, TLS_AES_256_GCM_SHA384 y TLS_CHACHA20_POLY1305_SHA256. No es posible personalizar estos conjuntos de cifrado.

Paso 3: seleccionar el conjunto de cifrado

Para evitar riesgos de seguridad causados por conjuntos de cifrado débiles, se recomienda seleccionar conjuntos de cifrado fuertes de la lista a continuación.

Conjuntos de cifrado fuertes	Conjuntos de cifrado débiles
ECDHE-ECDSA-AES128-GCM-SHA256 ECDHE-ECDSA-AES256-GCM-SHA384 ECDHE-ECDSA-AES128-SHA256 ECDHE-ECDSA-AES256-SHA384 ECDHE-RSA-AES128-GCM-SHA256 ECDHE-RSA-AES256-GCM-SHA384 ECDHE-RSA-AES128-SHA256 ECDHE-RSA-AES256-SHA384 ECDHE-ECDSA-AES128-SHA ECDHE-ECDSA-AES256-SHA ECDHE-RSA-CHACHA20-POLY1305	AES128-GCM-SHA256 AES256-GCM-SHA384 AES128-SHA256 AES256-SHA256 ECDHE-RSA-AES128-SHA ECDHE-RSA-AES256-SHA AES128-SHA AES256-SHA DES-CBC3-SHA ECDHE-RSA-RC4-SHA

Nota

Recomendaciones de seguridad de conjuntos de cifrado: los conjuntos de cifrado ECDHE-RSA-AES128-SHA256 y ECDHE-RSA-AES256-SHA384 utilizan ECDHE para el intercambio de claves, RSA para la autenticación y el modo de cifrado AES-CBC. En comparación con los conjuntos de cifrado que usan modos de cifrado autenticado como AES-GCM, estos ofrecen menor seguridad y rendimiento. Algunas herramientas de escaneo de seguridad pueden identificarlos como conjuntos de cifrado débiles. Si esto ocurre, seleccione conjuntos de cifrado personalizados y excluya manualmente estos dos conjuntos.
Convenciones de nomenclatura de conjuntos de cifrado: dado que las convenciones de nomenclatura de los conjuntos de cifrado difieren, WAF los muestra en formato OpenSSL, mientras que algunas herramientas de escaneo pueden usar el estándar IANA. Por ejemplo, ECDHE-ECDSA-AES256-SHA384 en OpenSSL corresponde a TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 en IANA. Para consultar rápidamente la asignación, visite ciphersuite.info o utilice otras herramientas de consulta de TLS.

¿Por qué el campo upstream_addr muestra "-" en los registros después de la incorporación?

Cuando el campo upstream_addr en los registros muestra -, significa que WAF no envió una solicitud back-to-origin al servidor de origen. Por ejemplo, esto sucede cuando WAF bloquea la solicitud. Se recomienda revisar otros campos como upstream_status y upstream_response_time para realizar un análisis más detallado.

¿Por qué las solicitudes bloqueadas por WAF siguen registrándose en los registros de ALB en modo cloud native?

En el modo cloud native, WAF 3.0 utiliza un SDK integrado para incorporar capacidades de detección de seguridad directamente en el plano de datos de Application Load Balancer (ALB). Cuando una solicitud llega a una instancia ALB e ingresa al flujo de procesamiento de datos, ALB genera un registro de acceso. Si WAF bloquea la solicitud posteriormente, devuelve una página de bloqueo al cliente y la solicitud no se reenvía al servidor de backend. El registro de acceso no se revoca porque se generó antes de que WAF bloqueara la solicitud.

En el modo cloud native, ¿es necesario configurar certificados SSL tanto en WAF como en la instancia ECS de origen?

Sí. En el modo cloud native, tanto WAF como la instancia ECS de origen deben tener un certificado SSL válido. Este modo no admite una configuración donde solo WAF tenga un certificado. Para descargar el procesamiento SSL a WAF, lo que permite que WAF se comunique con el servidor de origen mediante HTTP, debe utilizar el modo CNAME.