La mayoría de los otros métodos mencionados aquí son fácilmente derrotados y / o reducen significativamente el rendimiento.
Es por eso que los firewalls de aplicaciones web (WAF) no confían en ellos.
2 métodos confiables son:
-
Analice la secuencia de paquetes en el encabezado de IP: la mayoría de las pilas TCP / IP
numere los paquetes secuencialmente, entonces si el número es aleatorio, entonces el
El cliente probablemente está detrás de NAT (una conexión compartida a Internet con
otros clientes). Existe una sobrecarga de RAM para recordar el ID del paquete anterior, pero es comparable a una cookie de sesión. Esto es más difícil de falsificar ya que el atacante debe volver a escribir el paquete a un nivel bajo, pero no imposible, por lo que debe combinarse con una limitación de velocidad: permitir que las IP públicas NATted tengan más aciertos / segundo.
-
Cookies de sesión con autenticación criptográfica:
Las cookies de sesión normal son no suficientes. No están cifrados con HTTP, e incluso con HTTPS, pueden no formar parte de una carga útil cifrada con HTTPS y, por lo tanto, tampoco están autenticados. enlace Hazlo correctamente. Asegúrese de que no solo esté cifrado, sino que esté autenticado / "firmado". enlace Si solo tiene acceso al código de la aplicación web, esta es la mejor opción. Obviamente, si las cookies están deshabilitadas, ejecute un JavaScript del lado del cliente que distinga entre navegadores y bots (solicite una resolución de pantalla, etc., que un bot no admitiría y devuelva el estado del bot si el script falla). Combine esto con la limitación de velocidad por cookie de sesión autenticada o, si las cookies están deshabilitadas, la limitación de velocidad basada en IP ("limitación") o el bloqueo. Esto acepta / rechaza la solicitud al principio de la rutina del analizador IP / HTTP, conservando los ciclos de CPU futuros, ya que un atacante de fuerza bruta puede volver a intentarlo miles de veces. Debido a las cookies de DHCP / PPPoE / nueva sesión, las prohibiciones deben expirar después de unos minutos. Tenga en cuenta que debe incluir en la lista blanca las direcciones IP no falsificadas de los rastreadores de motores de búsqueda como Google y Baidu. De lo contrario, su ranking de búsqueda puede sufrir.
Si combina su solución con un límite de velocidad, el límite de velocidad correcto debe ser 1-2 veces el número de URL por página. Por ejemplo, si login.php incluye 2 archivos CSS, 4 archivos JavaScript y 10 imágenes más la página 1, debe permitir al menos un total de 17 visitas por cookie de sesión de cliente, por segundo. De lo contrario, es posible que esté bloqueando / limitando las solicitudes normales.
Para ataques persistentes, debe solicitar a su ISP que bloquee / haga un agujero negro en la ruta en sentido ascendente.
¿Por qué no usar las otras soluciones?
'User-Agent:' es muy trivial para la falsificación:
wget -O index.html --user-agent="My Fake Browser"
Las cookies de sesión, el encabezado HTTP 'X-Forwarded-For:' y otros encabezados también son triviales para robar / falsificar. Google 'Firesheep' o 'Cookies Manager +' o 'Modify Headers plugin' o 'LiveHeaders plugin', etc. como prueba.
La limitación de la tasa tampoco es suficiente por sí sola, porque un ataque oculto aleatorizará o aumentará el tiempo de espera entre solicitudes:
wget --limit-rate=10 http://example.com/index.php
La fuerza bruta no suele ser su único problema. enlace Codificación y probar la protección efectiva también requiere tiempo. Para ahorrar tiempo y / o ciclos de CPU en sus servidores web, se multiplica el desperdicio si tiene una granja de servidores. Su servidor web debe ofrecer un WAF de front-end con esto configurado para usted. Esa es la mejor solución, no lo hagas del lado del servidor. Hazlo aguas arriba.