Los ataques de capa 7 en sitios incluyen ataques a la capa del servidor web (nginx, apache, etc.) y ataques a la capa del servidor de aplicaciones (php-fpm, nodejs, etc.), que generalmente se encuentra detrás del servidor proxy (nginx, apache , etc.). Desde la perspectiva del protocolo de red, ambos son ataques a la capa de aplicación. Pero nosotros, desde un punto de vista práctico, necesitamos separar estos dos casos. El servidor web (nginx, apache, etc.), por regla general, proporciona de forma independiente archivos estáticos (imágenes, estilos, scripts) y envía solicitudes de contenido dinámico al servidor de aplicaciones (php-fpm, nodejs, etc.). Son estas solicitudes las que se convierten en blanco de ataques, ya que, a diferencia de las solicitudes estáticas, los servidores de aplicaciones al generar contenido dinámico requieren varios órdenes de magnitud de recursos del sistema más limitados, que es lo que utilizan los atacantes.
Por trivial que parezca, para defenderse de un ataque, primero debe identificarse. De hecho, no solo los ataques DDoS pueden provocar fallas en el sitio, sino también otras razones asociadas con errores por parte de desarrolladores y administradores de sistemas. Para la conveniencia del análisis, debe agregar el parámetro $ request_time al formato de registro nginx (lo siento, no tengo una opción con apache) y registrar las solicitudes en el servidor de aplicaciones en un archivo separado:
log_format timed '$remote_addr - $remote_user [$time_local] '
'$host:$server_port "$request" $status $body_bytes_sent '
'"$http_referer" "$http_user_agent" ($request_time s.)';
location /api/ {
proxy_pass http://127.0.0.1:3000;
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection 'upgrade';
proxy_set_header Host $host;
proxy_cache_bypass $http_upgrade;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-NginX-Proxy true;
access_log /var/log/ngunx/application_access.log timed;
}
Habiendo recibido los registros en el servidor de aplicaciones en un archivo separado (sin registros estáticos) y con el tiempo de solicitud en segundos, puede identificar rápidamente el momento en que comienza el ataque, cuando el número de solicitudes y el tiempo de respuesta comienza a aumentar drásticamente.
Una vez identificado el ataque, puede proceder a la defensa.
Muy a menudo, los administradores del sistema intentan proteger el sitio limitando el número de solicitudes de una única dirección IP. Para hacer esto, use 1) la directiva nginx limit_req_zone ( ver documentación ), 2) fail2ban y 3) iptables. Por supuesto, se deben utilizar estos métodos. Sin embargo, este método de protección ha sido ineficaz durante 10 a 15 años. Hay dos razones para esto:
1) El tráfico generado por la red de bots durante un ataque en el séptimo nivel puede ser menor en volumen que el tráfico de un visitante normal del sitio, ya que un visitante normal del sitio tiene una solicitud "pesada" al servidor de aplicaciones (php-fpm , nodejs, etc.) hay alrededor de 100 solicitudes "ligeras" para descargar archivos estáticos que son enviados por el servidor web (nginx, apache, etc.). Iptables no protege contra tales solicitudes, ya que puede restringir el tráfico solo mediante indicadores cuantitativos y no tiene en cuenta la separación de solicitudes en estática y dinámica.
2) La segunda razón es la distribución de la red de bots (la primera letra es D en la abreviatura de DDoS). El ataque generalmente involucra una red de varios miles de bots. Pueden realizar solicitudes con menos frecuencia que el usuario medio. Como regla general, al atacar un sitio, un atacante calcula empíricamente los parámetros limit_req_zone y fail2ban. Y configura la red del bot para que esta protección no funcione. A menudo, los administradores del sistema comienzan a subestimar estos parámetros, deshabilitando así a los clientes reales, sin mucho resultado en términos de protección contra los bots.
Para proteger con éxito un sitio de DDoS, es necesario que se utilicen todos los medios de protección posibles en el servidor del complejo. En mi publicación anterior sobre este tema, protección DDoS a nivel de servidor webhay enlaces a materiales sobre cómo configurar iptables y qué parámetros del kernel del sistema deben ajustarse al valor óptimo (es decir, en primer lugar, la cantidad de archivos abiertos y sockets). Este es un requisito previo, una condición necesaria, pero no suficiente, para protegerse de los bots.
Además, es necesario construir una protección basada en la detección de bots. Todo lo que se necesita para comprender la mecánica de detección de bots se describió en detalle en el artículo histórico sobre Habré El módulo nginx para combatir DDoS del autor kyprizel , y está implementado en la biblioteca del mismo autor testcookie-nginx-module
Es una biblioteca de C y continúa siendo desarrollada por una pequeña comunidad de autores. Probablemente, no todos los administradores de sistemas están preparados para compilar una biblioteca desconocida en un servidor de producción. Si necesita realizar cambios adicionales en el trabajo de la biblioteca, esto está completamente fuera del alcance de un administrador o desarrollador de sistemas ordinario. Afortunadamente, ahora hay nuevas características: el lenguaje de secuencias de comandos Lua que se puede ejecutar en el servidor nginx. Hay dos compilaciones populares de nginx con un motor de scripting Lua incorporado: openresty, que originalmente se inspiró en Taobao, luego Cloudfare y nginx-extras, que se incluye con algunas distribuciones de Linux, como Ubuntu. Ambas opciones usan las mismas bibliotecas, por lo que no importa cuál usar.
La protección de bots puede basarse en determinar la capacidad del cliente web para 1) ejecutar código JavaScript, 2) realizar redireccionamientos y 3) establecer cookies. De todos estos métodos, la ejecución del código JavaScript resultó ser el menos prometedor, y lo rechacé, ya que el código JavaScript no se ejecuta si el contenido se carga con solicitudes de fondo (ajax), y la recarga de la página usando JavaScript distorsiona el estadísticas de transiciones al sitio (desde el título Referer). Por lo tanto, existen redireccionamientos que establecen cookies, cuyos valores están sujetos a una lógica que no se puede reproducir en el cliente y no permiten que los clientes accedan al sitio sin estas cookies.
En mi trabajo, confié en la biblioteca leeyiw / ngx_lua_anticc, que actualmente no se está desarrollando, y continué las mejoras en mi bifurcación apapacy / ngx_lua_anticc , ya que el trabajo de la biblioteca original no se adaptaba a todo.
Para operar los contadores de consultas en la biblioteca, se utilizan tablas de memoria, que admiten métodos incr, convenientes para incrementar los valores del contador y establecer valores con TTL. Por ejemplo, el siguiente fragmento de código incrementa el recuento de solicitudes de una única dirección IP si el cliente no tiene una cookie con un nombre específico establecido. Si el contador aún no se ha inicializado, se inicializa a 1 con un TTL de 60 segundos. Después de exceder el número de solicitudes 256 (en 60 segundos), el cliente no puede ingresar al sitio:
local anticc = ngx.shared.nla_anticc
local remote_id = ngx.var.remote_addr
if not cookies[config.cookie_name] then
local count, err = anticc:incr(remote_id, 1)
if not count then
anticc:set(remote_id, 1, 60)
count = 1
end
if count >= 256 then
if count == 256 then
ngx.log(ngx.WARN, "client banned by remote address")
end
ngx.exit(444)
return
end
end
No todos los bots son dañinos. Por ejemplo, debe omitir los bots de búsqueda y los bots de los sistemas de pago que informan cambios en los estados de pago al sitio. Es bueno si puede crear una lista de todas las direcciones IP de las que pueden provenir dichas solicitudes. En este caso, puede crear una lista "blanca":
local whitelist = ngx.shared.nla_whitelist
in_whitelist = whitelist:get(ngx.var.remote_addr)
if in_whitelist then
return
end
Pero esto no siempre es posible. Uno de los problemas es la incertidumbre con las direcciones de los bots de Google. Omitir todos los bots que falsifican a los bots de Google equivale a eliminar la protección del sitio. Por lo tanto, usaremos el módulo resty.exec para ejecutar el comando de host:
local exec = require 'resty.exec'
if ngx.re.find(headers["User-Agent"],config.google_bots , "ioj") then
local prog = exec.new('/tmp/exec.sock')
prog.argv = { 'host', ngx.var.remote_addr }
local res, err = prog()
if res and ngx.re.find(res.stdout, "google") then
ngx.log(ngx.WARN, "ip " .. ngx.var.remote_addr .. " from " .. res.stdout .. " added to whitelist")
whitelist:add(ngx.var.remote_addr, true)
return
end
if res then
ngx.log(ngx.WARN, "ip " .. ngx.var.remote_addr .. " from " .. res.stdout .. "not added to whitelist")
else
ngx.log(ngx.WARN, "lua-resty-exec error: " .. err)
end
end
La experiencia muestra que dicha estrategia de protección le permite proteger el sitio de una determinada clase de ataques, que a menudo se utilizan para la competencia desleal. Comprender los mecanismos de los ataques y los métodos de protección ayuda a ahorrar mucho tiempo en los intentos fallidos de defenderse contra fail2ban, y cuando se usa protección de terceros (por ejemplo, de Cloudfare), elige los parámetros de protección de manera más deliberada.
apapacy@gmail.com
9 de mayo de 2021