security - traductor - brute force wifi




¿Cuál es la mejor contramedida de fuerza bruta distribuida? (12)

  1. ¿Qué pasa si se requiere una contraseña de un solo uso antes de ingresar su contraseña normal? Eso haría muy obvio que alguien estaba atacando antes de que tuvieran muchas oportunidades de adivinar la contraseña principal.

  2. Mantenga un conteo global / tasa de fallas de inicio de sesión - este es el indicador de un ataque - durante un ataque sea más estricto sobre las fallas de inicio de sesión, por ejemplo, prohibir las direcciones IP más rápidamente.

Primero, un poco de historia: no es ningún secreto que estoy implementando un sistema auth + auth para CodeIgniter, y hasta ahora estoy ganando (por así decirlo). Pero me encontré con un desafío bastante no trivial (uno que la mayoría de las bibliotecas de auth fallan por completo, pero insisto en manejarlo adecuadamente): cómo lidiar inteligentemente con los ataques de fuerza bruta distribuidos y de nombre de usuario variable a gran escala .

Conozco todos los trucos habituales:

  1. Limitar el número de intentos fallidos por IP / host y denegar el acceso de los delincuentes (por ejemplo, Fail2Ban), que ya no funciona, ya que las botnets se han vuelto más inteligentes
  2. Combinando lo anterior con una lista negra de IPs / hosts "malos" conocidos (por ejemplo, DenyHosts) - que se basa en botnets que caen en el # 1, que cada vez más no lo hacen
  3. Las listas blancas de IP / host se combinan con la autenticación tradicional (lamentablemente inútil con usuarios dinámicos de IP y la alta rotación en la mayoría de los sitios web)
  4. Estableciendo un límite para todo el sitio en # intentos fallidos dentro de un período de N minutos / hora, y estrangulando (suspendiendo) todos los intentos de inicio de sesión durante varios minutos / horas (con el problema de que el ataque DoS se convierte en juego de botnet)
  5. Fichas digitales obligatorias (certificados de clave pública) o tokens de hardware RSA para todos los usuarios sin opción de inicio de sesión / contraseña (sin duda una solución sólida, pero solo práctica para servicios dedicados cerrados)
  6. Implementados esquemas de contraseñas ultrafuertes (por ej.,> 25 caracteres sin sentido con símbolos; de nuevo, demasiado poco prácticos para usuarios ocasionales)
  7. Y, por último, CAPTCHA (que podría funcionar en la mayoría de los casos, pero son molestos para los usuarios y prácticamente inútiles contra un atacante decidido e ingenioso )

Ahora, estas son solo las ideas teóricamente viables. Hay muchas ideas basura que hacen que el sitio se abra de par en par (por ejemplo, para ataques triviales de DoS). Lo que quiero es algo mejor. Y por mejor, quiero decir:

  • Tiene que ser seguro (+) contra DoS y ataques de fuerza bruta, y no introducir nuevas vulnerabilidades que puedan permitir que un robot un poco más sigiloso continúe operando bajo el radar.

  • Tiene que ser automatizado. Si se requiere que un operador humano verifique cada inicio de sesión o monitoree actividad sospechosa, no funcionará en un escenario del mundo real

  • Tiene que ser factible para el uso general de la web (es decir, alta rotación, alto volumen y registro abierto que puede ser realizado por no programadores)

  • No puede impedir la experiencia del usuario hasta el punto en que los usuarios casuales se molestarán o frustrarán (y posiblemente abandonen el sitio)

  • No puede involucrar gatitos, a menos que sean realmente gatitos seguros

(+) Por 'seguro', me refiero al menos tan seguro como la capacidad de un usuario paranoico de mantener su contraseña en secreto

Entonces, ¡vamos a escucharlo! ¿Cómo lo harías ? ¿Conoces alguna de las mejores prácticas que no he mencionado (oh, por favor di que sí)? Admito que tengo una idea propia (combinando ideas de 3 y 4), pero dejaré que los verdaderos expertos hablen antes de avergonzarme ;-)


Algunos pasos simples:

Ponga en lista negra ciertos nombres de usuario comunes, y úselos como un honeypot. Administrador, invitado, etc. No permita que nadie cree cuentas con estos nombres, de modo que si alguien intenta iniciar sesión, sabe que alguien está haciendo algo que no debería.

Asegúrese de que cualquier persona que tenga poder real en el sitio tenga una contraseña segura. Exige que los administradores / moderadores tengan contraseñas más largas con una combinación de letras, números y símbolos. Rechace contraseñas triviales simples de los usuarios habituales con una explicación.

Una de las cosas más simples que puede hacer es decirle a las personas cuando alguien intentó ingresar a su cuenta, y darles un enlace para reportar el incidente si no fueran ellos. Un mensaje simple cuando inician sesión como "Alguien intentó ingresar a su cuenta a las 4:20 AM del miércoles, bla, bla. Haga clic aquí si este no era usted". Te permite mantener algunas estadísticas sobre ataques. Puede intensificar las medidas de monitoreo y seguridad si ve que hay un aumento repentino en los accesos fraudulentos.


Dado que varias personas incluyeron CAPTCHA como un mecanismo humano alternativo, agregué una pregunta anterior de y enhebré la efectividad de CAPTCHA.

¿Ha sido craqueado / pirateado / OCR'd / derrotado / roto ReCaptcha?

El uso de CAPTCHA no limita las mejoras de su aceleración y otras sugerencias, pero creo que la cantidad de respuestas que incluyen CAPTCHA como una alternativa debería considerar los métodos basados ​​en el ser humano disponibles para las personas que buscan romper la seguridad.


Descargo de responsabilidad: trabajo para una empresa de dos factores, pero no estoy aquí para conectarlo. Aquí hay algunas observaciones.

Las cookies pueden ser robadas con XSS y vulnerabilidades del navegador. Los usuarios generalmente cambian los navegadores o borran sus cookies.

Las direcciones IP de origen son simultáneamente dinámicamente variables y falsificables.

Captcha es útil, pero no autentica a un ser humano específico.

Se pueden combinar varios métodos con éxito, pero el buen gusto está ciertamente en orden.

La complejidad de las contraseñas es buena, todo lo que se base en contraseñas depende críticamente de que las contraseñas tengan suficiente entropía. En mi humilde opinión, una contraseña segura anotada en una ubicación física segura es mejor que una contraseña débil en la memoria. Las personas saben cómo evaluar la seguridad de los documentos en papel mucho mejor de lo que saben cómo calcular la entropía efectiva en el nombre de su perro cuando se usa como contraseña para tres sitios web diferentes. Considere darles a los usuarios la capacidad de imprimir una página grande o pequeña llena de códigos de acceso de uso únicos.

Las preguntas de seguridad como "¿cuál era tu mascota de la escuela secundaria?" Son en su mayoría otra forma pésima de "algo que sabes", la mayoría de ellas son fáciles de adivinar o directamente en el dominio público.

Como ha señalado, reducir los intentos de inicio de sesión fallidos es una solución de compromiso entre la prevención de ataques de fuerza bruta y la facilidad de hacer una cuenta. Las políticas de bloqueo agresivo pueden reflejar una falta de confianza en la entropía de contraseñas.

Personalmente, no veo el beneficio de imponer la caducidad de contraseñas en un sitio web de todos modos. El atacante obtiene su contraseña una vez, puede cambiarla y cumplir con esa política tan fácilmente como sea posible. Quizás uno de los beneficios es que el usuario puede notarlo antes si el atacante cambia la contraseña de la cuenta. Aún mejor sería si el usuario fuera notificado de alguna manera antes de que el atacante obtuviera acceso. Mensajes como "N intentos fallidos desde el último inicio de sesión" son útiles a este respecto.

La mejor seguridad proviene de un segundo factor de autenticación que está fuera de banda en relación con el primero. Como dijiste, los tokens de hardware en "algo que tienes" son geniales, pero muchos (no todos) tienen una sobrecarga de administración real asociada con su distribución. No conozco ninguna solución biométrica de "algo que seas" buena para los sitios web. Algunas soluciones de dos factores funcionan con proveedores de código abierto, algunas tienen PHP / Perl / Python SDK.


La primera respuesta que usualmente he escuchado al hacer esta pregunta es cambiar los puertos, pero olvídate de eso y solo inhabilita IPv4. Si solo permite clientes de redes IPv6, ya no orará por un simple escaneo de red y los atacantes recurrirán a búsquedas de DNS. No se ejecute en la misma dirección que su Apache (AAAA) / Sendmail (MX-> AAAA) / lo que le ha dado a todos (AAAA). Asegúrate de que tu zona no pueda ser compartida, espera a que tu zona sea descargada por cualquiera.

Si los bots encuentran que su servidor está configurando nuevos nombres de host, simplemente anteponga algunos galimatías a sus nombres de host, y cambie su dirección. Deje los nombres antiguos e incluso la configuración ** nombres de honeypot para que la red bot agote el tiempo de espera.

** Pon a prueba tus registros inversos (PTR) (en ip6.arpa) para ver si se pueden usar para concentrar en / 4 que tienen registros VS / 4 que no lo hacen. IE Típicamente ip6.arpa tendría ~ 32 "." S en una dirección, pero tratar con los últimos que faltan podría eludir los bloques de red que tienen registros VS otros que no. Si lleva eso más allá, es posible omitir grandes porciones del espacio de direcciones.

En el peor de los casos, los usuarios tendrán que configurar un túnel IPv6, no es como si tuvieran que llegar hasta una DMZ ... Aunque uno se pregunta por qué esa no es la primera opción.

También Kerberos es genial, pero en mi humilde opinión, LDAP falla (¿Qué es técnicamente incorrecto con NISPlus? He leído que Sun decidió que los usuarios querían LDAP y, debido a esto, descartaron NIS +). Kerberos funciona bien sin LDAP o NIS, solo tiene que gestionar usuarios host por host. El uso de Kerberos le proporciona una PKI fácil de usar, si no automatizada.


Mi más alta recomendación es simplemente asegurarme de mantener a los usuarios informados de los intentos de acceso incorrectos a sus cuentas. Los usuarios probablemente tomarán la fortaleza de su contraseña mucho más en serio si se les presenta evidencia de que alguien realmente intenta ingresar a su cuenta. .

De hecho, atrapé a alguien que pirateó la cuenta de myspace de mi hermano porque habían intentado acceder a la cuenta de Gmail que configuré para él y usé la función "restablecer mi contraseña por correo electrónico" ... que fue a mi bandeja de entrada.


No importa cuán bueno sea su sistema, fallará en un ataque lo suficientemente prolongado. Aquí hay algunas buenas ideas sobre cómo extender la duración de una contraseña. (Personalmente, me gusta la idea de limitar de forma exponencial la tasa de intentos por usuario y por dirección IP.) Pero no importa lo que ocurra, tendrá que respaldarlo con algunas reglas de contraseña.

Te animo a que averigües qué tan rápido se puede descifrar una contraseña y que los usuarios la cambien el doble de veces. Espero que esto ayude.

Editar: Si esperas un montón de atacantes perezosos, necesitar un poco de CAPTCHA después de múltiples intentos fallidos es bueno: sube un poco la barra. Si le preocupan muchos atacantes inteligentes, contrate a un asesor de seguridad. ;)


Para resumir el esquema de Jens en un diagrama de transición pseudoestado / base de reglas:

  1. usuario + contraseña -> entrada
  2. usuario +! contraseña -> denegado
  3. usuario + known_IP (usuario) -> puerta de entrada, // never throttle
  4. usuario + unknown_IP (usuario) -> catflap
  5. (#denied> n) a través de catflaps (sitio) -> throttle catflaps (sitio) // slow the bots
  6. catflap + throttle + password + captcha -> entry // humans still welcome
  7. catflap + throttle + password +! captcha -> denied // a correct guess from a bot

Observaciones:

  • Nunca estrangule la puerta delantera. La policía estatal de Elbon tiene su computadora, en su casa, pero no pueden interrogarlo. La fuerza bruta es un enfoque viable desde su computadora.
  • Si proporciona un "¿Olvidó su contraseña?" enlace, entonces su cuenta de correo electrónico se convierte en parte de la superficie de ataque.

Estas observaciones cubren un tipo diferente de ataque a los que estás tratando de contrarrestar.


Si entiendo correctamente el MO de los ataques de fuerza bruta, uno o más nombres de usuario se prueban de forma continua.

Hay dos sugerencias que no creo haber visto todavía aquí:

  • Siempre pensé que la práctica estándar era tener un pequeño retraso (un segundo más o menos) después de cada inicio de sesión incorrecto para cada usuario. Esto disuade a la fuerza bruta, pero no sé por cuánto tiempo un retraso de un segundo mantendría a raya un ataque de diccionario. (diccionario de 10,000 palabras == 10,000 segundos == alrededor de 3 horas. Hmm. No lo suficiente).
  • en lugar de una ralentización en todo el sitio, ¿por qué no un acelerador de nombre de usuario? El acelerador se vuelve cada vez más duro con cada intento equivocado (hasta un límite, supongo que el usuario real aún puede iniciar sesión)

Editar : en respuesta a los comentarios sobre un acelerador de nombre de usuario: este es un acelerador específico de nombre de usuario sin tener en cuenta la fuente del ataque.

Si el nombre de usuario es acelerado, incluso un ataque de nombre de usuario coordinado (IP múltiple, conjetura individual por IP, mismo nombre de usuario) sería atrapado. Los nombres de usuario individuales están protegidos por el acelerador, incluso si los atacantes son libres de probar otro usuario / pase durante el tiempo de espera.

Desde el punto de vista de los atacantes, durante el tiempo de espera, es posible que adivine por primera vez 100 contraseñas y descubra rápidamente una contraseña incorrecta por cuenta. Es posible que solo pueda hacer una aproximación de 50 segundos para el mismo período de tiempo.

Desde el punto de vista de una cuenta de usuario, aún se necesita el mismo número promedio de intentos para descifrar la contraseña, incluso si las suposiciones provienen de múltiples fuentes.

Para los atacantes, en el mejor de los casos, será el mismo esfuerzo romper 100 cuentas como lo haría con 1 cuenta, pero como no está estrangulando en todo el sitio, puede aumentar el acelerador rápidamente.

Refinamientos adicionales:

  • detectar direcciones IP que adivinan varias cuentas: 408 Tiempo de espera de solicitud
  • detectar direcciones IP que adivinan la misma cuenta: 408 Tiempo de espera de solicitud después de un número grande (digamos 100) de conjeturas.

Ideas de UI (pueden no ser adecuadas en este contexto), que también pueden refinar lo anterior:

  • Si tiene el control de la configuración de la contraseña, mostrarle al usuario qué tan fuerte es su contraseña lo anima a elegir una mejor.
  • si tiene el control de la página de inicio de sesión, después de un número pequeño (digamos 10) de conjeturas de un único nombre de usuario, ofrezca un CAPTCHA.

También puede acelerar según la fuerza de la contraseña de un usuario.

Cuando un usuario se registra o cambia su contraseña, calcula una clasificación de resistencia para su contraseña, por ejemplo, entre 1 y 10.

Algo como "contraseña" obtiene un puntaje de 1, mientras que "c6eqapRepe7et * Awr @ ch" puede obtener un puntaje de 9 o 10 y cuanto mayor sea el puntaje, más tiempo tardará en acelerarse.


Un poco tarde aquí, pero estaba pensando, asumiendo un caso difícil: el atacante usa una gran cantidad de direcciones IP aleatorias, nombres de usuario aleatorios y una contraseña aleatoria seleccionada de, digamos, una lista de los 10 000 más populares.

Una cosa que podría hacer, especialmente si el sistema parece estar siendo atacado, hay muchos intentos incorrectos de contraseña en el sistema y especialmente si la contraseña es de baja entropía es hacer una pregunta secundaria como cuáles son los nombres de pila de sus padres, por ejemplo . Si un atacante alcanza un millón de cuentas probando la contraseña 'contraseña1', hay una gran posibilidad de que obtenga mucho, pero sus probabilidades de obtener los nombres correctos reducirían los éxitos dramáticamente.


Muy bien, suficiente estancamiento; esto es lo que se me ocurrió hasta ahora

(Lo siento, larga publicación por delante. Sé valiente, amigo, el viaje valdrá la pena)

Combina los métodos 3 y 4 de la publicación original en una especie de lista blanca "difusa" o dinámica, y luego, y aquí está el truco, no bloquea las IP no incluidas en la lista blanca, limitándolas al infierno y viceversa .

Tenga en cuenta que esta medida solo pretende frustrar este tipo de ataque muy específico. En la práctica, por supuesto, funcionaría en combinación con otros enfoques de mejores prácticas para auth: aceleración de nombre de usuario fijo, aceleración por IP, política de contraseña sólida implementada por código, inicio de sesión de cookies sin estrangulamiento, hash todos los equivalentes de contraseña antes de guardarlos, nunca usando preguntas de seguridad, etc.

Supuestos sobre el escenario de ataque

Si un atacante tiene como objetivo nombres de usuario variables, nuestro límite de nombre de usuario no se activa. Si el atacante está utilizando una botnet o tiene acceso a un amplio rango de IP, nuestra regulación de IP no tiene ningún poder. Si el atacante ha raspado previamente nuestra lista de usuarios (generalmente posible en servicios web de registro abierto), no podemos detectar un ataque continuo basado en el número de errores de "usuario no encontrado". Y si aplicamos un límite restrictivo para todo el sistema (todos los nombres de usuario, todos los IP), cualquier ataque de este tipo causará todo nuestro sitio durante la duración del ataque más el período de aceleración.

Entonces tenemos que hacer otra cosa.

La primera parte de la contramedida: lista blanca

De lo que podemos estar bastante seguros es de que el atacante no puede detectar y falsificar dinámicamente las direcciones IP de varios miles de nuestros usuarios (+). Lo que hace factibles las listas blancas . En otras palabras: para cada usuario, almacenamos una lista de las direcciones IP (hash) desde donde el usuario ha iniciado sesión (recientemente).

Por lo tanto, nuestro esquema de listas blancas funcionará como una 'puerta de entrada' cerrada, donde un usuario debe estar conectado desde una de sus 'buenas' IP reconocidas para poder iniciar sesión. Un ataque de fuerza bruta contra esta "puerta principal" sería prácticamente imposible (+).

(+) a menos que el atacante sea "propietario" del servidor, de todas las casillas de nuestros usuarios o de la conexión en sí, y en esos casos, ya no tenemos un problema de 'autenticación', tenemos una verdadera franquicia del tamaño de una franquicia. -plug FUBAR situación

La segunda parte de la contramedida: regulación de todo el sistema de direcciones IP no reconocidas

Para hacer que una lista blanca funcione para un servicio web de registro abierto, donde los usuarios cambian las computadoras con frecuencia y / o se conectan desde direcciones IP dinámicas, necesitamos mantener abierta una 'puerta de gato' para los usuarios que se conectan desde direcciones IP no reconocidas. El truco está en diseñar esa puerta para que los botnets se atasquen, y los usuarios legítimos se molesten lo menos posible .

En mi esquema, esto se logra estableciendo un número máximo muy restrictivo de intentos fallidos de inicio de sesión por IP no aprobadas durante, por ejemplo, un período de 3 horas (puede ser más prudente usar un período más corto o más largo según el tipo de servicio), y haciendo que esa restricción sea global , es decir. para todas las cuentas de usuario.

Incluso una fuerza bruta lenta (1-2 minutos entre intentos) sería detectada y frustrada de forma rápida y efectiva con este método. Por supuesto, una fuerza bruta realmente lenta podría pasar inadvertida, pero velocidades demasiado lentas vencerán el propósito del ataque de fuerza bruta.

Lo que espero lograr con este mecanismo de aceleración es que, si se alcanza el límite máximo, nuestra "puerta de gato" cierra de golpe por un momento, pero nuestra puerta de entrada permanece abierta para que los usuarios legítimos se conecten por los medios habituales:

  • Al conectarse desde una de sus direcciones IP reconocidas
  • O mediante el uso de una cookie de inicio de sesión persistente (desde cualquier lugar)

Los únicos usuarios legítimos que se verían afectados durante un ataque, es decir. mientras se activaba la aceleración, serían los usuarios sin cookies de inicio de sesión persistentes que iniciaban sesión desde una ubicación desconocida o con una dirección IP dinámica. Esos usuarios no podrían iniciar sesión hasta que el estrangulamiento se haya disipado (lo que podría tomar un tiempo, si el atacante mantuvo su botnet funcionando a pesar del estrangulamiento).

Para permitir que este pequeño subconjunto de usuarios se escurriera a través de la puerta de gato sellada de otro modo, incluso cuando los bots todavía estaban martillando, emplearía un formulario de "copia de seguridad" con un CAPTCHA. De modo que, cuando muestre el mensaje "Lo sentimos, pero no puede iniciar sesión desde esta dirección IP en este momento", incluya un enlace que diga " inicio de sesión de copia de seguridad segura: SOLO HUMANOS ( bots: sin mentir ) ". Broma aparte, cuando hacen clic en ese enlace, les da un formulario de inicio de sesión autenticado reCAPTCHA que elude el límite de todo el sitio. De esta forma, SI son humanos Y conocen la contraseña correcta (y pueden leer CAPTCHA), nunca se les negará el servicio, incluso si se conectan desde un host desconocido y no usan la cookie de autenticación automática.

Ah, y solo para aclarar: dado que considero que los CAPTCHA son en general malvados, la opción de inicio de sesión de "copia de seguridad" solo aparecería mientras la regulación estuviera activa .

No se puede negar que un ataque sostenido como ese constituiría todavía una forma de ataque DoS, pero con el sistema descrito implementado, solo afectaría lo que sospecho que es un pequeño subconjunto de usuarios, es decir, personas que no usan el sistema. "recuérdame" cookie Y sucede que está ingresando mientras ocurre un ataque Y no está iniciando sesión desde ninguna de sus direcciones IP habituales Y que no puede leer CAPTCHA. Solo aquellos que pueden decir NO a TODOS esos criterios, específicamente bots y personas realmente desafortunadas , serán rechazados durante un ataque de bot.

EDITAR: En realidad, pensé en una forma de permitir que incluso los usuarios desafiados por CAPTCHA pasen durante un 'bloqueo': en lugar de, o como complemento del inicio de sesión CAPTCHA de respaldo, brinde al usuario la opción de tener un único uso , código de bloqueo específico del usuario enviado a su correo electrónico, que luego puede utilizar para eludir la regulación. Esto definitivamente cruza mi umbral de "molestia", pero como solo se utiliza como último recurso para un pequeño subconjunto de usuarios, y dado que aún supera el bloqueo de su cuenta, sería aceptable.

(Además, tenga en cuenta que nada de esto sucede si el ataque es menos sofisticado que la desagradable versión distribuida que he descrito aquí. Si el ataque proviene de solo unas pocas direcciones IP o solo toca algunos nombres de usuario, se frustrará mucho antes y sin consecuencias en todo el sitio)

Entonces, esa es la contramedida que implementaré en mi biblioteca de autenticación, una vez que esté convencido de que es sólida y que no hay una solución mucho más simple que me haya perdido. El hecho es que hay muchas maneras sutiles de hacer las cosas mal en materia de seguridad, y no estoy por encima de hacer suposiciones falsas o una lógica irremediablemente defectuosa. Por lo tanto, cualquier comentario, crítica y mejoras, sutilezas, etc. son muy apreciados.







brute-force