Tengo una API en la que los usuarios pueden iniciar sesión. No quiero que sea hackeado. ¿Qué pasa si limito a cada usuario a 60 solicitudes por minuto? ¿Esto no frenará significativamente a los hackers en una situación de fuerza bruta?
Tengo una API en la que los usuarios pueden iniciar sesión. No quiero que sea hackeado. ¿Qué pasa si limito a cada usuario a 60 solicitudes por minuto? ¿Esto no frenará significativamente a los hackers en una situación de fuerza bruta?
Configura Fail2Ban o su equivalente primero para reducir rápidamente los ataques.
Luego mire una herramienta como mod_security para restringir el acceso permitido a su API. Si tiene tiempo, cree una lista blanca estricta de lo que está permitido y bloquee todo lo demás. Configure Fail2Ban para ver sus registros de mod_security. Los principios básicos aquí primero le ayudarán a bloquear los ataques, pero también deberá realizar ajustes a largo plazo en este sistema, especialmente a medida que su API evolucione.
Observe sus registros en busca de ataques comunes contra rutas que no existen en su API y luego agréguelos a mod_security como elementos para desencadenar prohibiciones en Fail2Ban.
Idealmente, puede hacer todo lo anterior en un servidor proxy dedicado ejecutándose frente al sistema que ejecuta su API, pero estos también pueden implementarse en la API sistema en sí.
Si hay alguna forma de incluir en la lista blanca las IP de los usuarios que acceden a ella o pedirles que usen una VPN , esto reduciría radicalmente la superficie de ataque disponible para los atacantes.
Una vez que tenga más tiempo, comience a medir el rendimiento de cada consulta en comparación con su API si tiene una que tarda mucho más en responder (consultas de búsqueda), esto puede convertirse en un objetivo para los ataques DoS, por lo que puede querer construir más reglas defensivas alrededor de esto.
Además, es muy importante endurecer constantemente su API y los sistemas en los que se está ejecutando. Realmente desea hacer análisis de vulnerabilidades, usar herramientas de pruebas de penetración Y análisis de códigos estáticos de su código sobre una base regular.
Algo en lo que también debe pensar , si tiene datos confidenciales en la base de datos detrás de esta API que nunca se solicitarán a través de la API, podría ser un buen ejemplo, como las tarjetas de crédito. Puede ser conveniente exportar el subconjunto de datos no confidenciales de la base de datos principal y alojarlo en un servidor dedicado para usarlo solo para la API y bloquear el acceso de este sistema al resto de su red (piense en la regla de firewall de una vía ). En muchos casos, esta puede ser una forma muy poderosa de prevenir la pérdida de datos al eliminar la superficie de ataque externo completamente del sistema con datos confidenciales. No todas las implementaciones de una API pueden hacer esto, pero cuando funciona, realmente puede ayudar.
En lo que respecta a las 60 solicitudes por minuto por usuario, no hay nada que impida que un atacante use miles de cuentas de usuario falsas en su ataque, por lo que no detendrá a los atacantes serios, sino que estrangulará a los usuarios abusivos, lo que puede ser algo para usted. También quiero hacer. Del mismo modo, hay muchos tipos diferentes de ataques de fuerza bruta. Si un atacante apunta un terabit de tráfico de botnet hacia su API, realmente no importará cómo tenga configuradas las cosas. Herramientas como Cloudflare ayudarán en ese escenario, pero nuevamente hay un límite a lo que se puede hacer.
Asegúrese de leer también la Hoja de referencia de seguridad de OWASP REST
Eso ayudaría a proteger contra ataques automatizados. La mayoría de los escáneres y fuzzers enviarán miles de permutaciones, esto ralentizaría estos esfuerzos. No protegerá contra la comprobación manual y un atacante metódico y persistente. Asegúrese de que está siguiendo prácticas de programación seguras dentro del código del servicio web en sí mismo, esta es su mejor defensa contra los atacantes.
Si solo le preocupa la fuerza bruta de credenciales, implemente los bloqueos de cuenta. Debido a que este es un servicio web, puede establecer el umbral de bloqueo en algo bastante alto (600 intentos fallidos). Si se alcanza el umbral, sabes que algo extraño está sucediendo. También restringiría el acceso a sus servicios web solo a aquellos hosts que necesitan interactuar con ellos.
Lea otras preguntas en las etiquetas brute-force http php threat-mitigation