it-swarm-es.com

Protección contra bloqueo de cuenta DoS

¿Alguna idea sobre cómo protegerse contra el siguiente escenario?

La empresa x utiliza Active Directory para la autenticación de sus empleados. La compañía tiene múltiples puntos de autenticación que son semipúblicos y algunos que son totalmente públicos. (p. ej., Extranet accesible desde Internet)

Los nombres de usuario son bastante fáciles de adivinar, ya que siguen una convención de nomenclatura estándar, basada en el nombre del empleado.

Si Eve quisiera montar un DoS contra la Compañía X, y tiene acceso a una gran cantidad de nombres de empleados, parecería bastante trivial para ella bloquear las cuentas de muchos de los empleados de la compañía.

¿Alguna idea sobre cómo protegerse contra este tipo de ataque?

Entiendo que un bloqueo de longitud variable podría ayudar, pero aún así significaría que los empleados no están conectados, trabajando.

Pensamientos?

23
Josh Brower

Hay un documento que describe cómo usar Microsoft Lync (anteriormente Office Communications Server) para mitigar los ataques de fuerza bruta:

http://blogs.technet.com/b/drrez/archive/2010/05/26/protecting-the-Edge-server-against-dos-and-password-brute-force-attacks-in- office-communications-server.aspx

fragmentos:

"Los ataques DoS no se pueden distinguir de las solicitudes de inicio de sesión legítimas. La única diferencia es la frecuencia de los intentos de inicio de sesión y el origen. Un gran número de intentos de inicio de sesión en rápida sucesión puede ser indicativo de un ataque DoS. adivina la contraseña del usuario para obtener acceso no autorizado y, a menudo, bloquea la cuenta del usuario si la política de seguridad está activada en Active Directory ".

"Al imponer el bloqueo de la cuenta en el servidor perimetral, el filtro de seguridad evita los ataques DoS en el borde del perímetro de la red y, como resultado, protege los recursos internos del servidor Office Communications Server"

Microsoft tiene otro libro blanco titulado: Libro blanco de mejores prácticas de bloqueo de cuentas
busque "Protección contra ataques de denegación de servicio de bloqueo de cuenta externa"

fragmentos de clave (copia literal):

Protección contra ataques de denegación de servicio de bloqueo de cuenta externa
Es posible que un usuario malintencionado inicie un ataque de denegación de servicio contra su empresa desde fuera de su red. Debido a que la mayoría de las redes están interconectadas, esto puede ser un ataque difícil de mitigar. Las siguientes técnicas tecnológicas son técnicas y tecnologías comunes que puede usar para ayudar a mitigar o prevenir tales ataques:

Requiere contraseñas complejas: Todas las cuentas deben tener una contraseña compleja. Todas las cuentas de administrador (local y de dominio) deben tener una contraseña larga y compleja y usted debe cambiarla periódicamente.

Cambiar el nombre de la cuenta de administrador: Debido a que la cuenta de administrador no se puede bloquear, se recomienda cambiar el nombre de la cuenta. Aunque esto no mitiga todos los ataques contra la cuenta del administrador, ayuda a mitigar estos ataques la mayor parte del tiempo. Para obtener más información, consulte "CÓMO: Cambiar el nombre de la cuenta de administrador e invitado en Windows 2000" en Microsoft Knowledge Base | http: //support.Microsoft.com/? Id = 320053.

Proteja su entorno con firewalls: Para evitar un ataque de denegación de servicio de bloqueo de cuenta, bloquee los puertos TCP y UDP) 135 a 139 y el puerto 445 en sus enrutadores y firewalls. Cuando hace esto, evita los intentos de inicio de sesión que se producen fuera de su red.

Evitar el acceso anónimo: Establezca el valor RestrictAnonymous en 2 en todas las computadoras que están expuestas a Internet y a todo el dominio si todas las computadoras están funcionando versiones de Windows 2000 o posterior. Esto evita que los usuarios malintencionados realicen conexiones anónimas a los recursos y puede ayudar a derrotar algunos tipos de ataques. Tenga en cuenta que algunos sistemas operativos tienen soporte limitado para computadoras que tienen esta configuración. Algunos programas también pueden tener problemas con esta configuración si usan una conexión anónima para obtener acceso a los recursos. Para obtener más información, consulte "Cómo utilizar el valor de registro RestrictAnonymous en Windows 2000" en Microsoft Knowledge Base http://support.Microsoft.com/? Id = 246261.

Proteja el tráfico de sitio a sitio mediante el uso de un túnel VPN: Si se requiere la comunicación entre los miembros del dominio en dos sitios, use un sitio a sitio Túnel VPN para conectar de forma segura las redes del sitio. No abra todos los puertos NetBIOS en el firewall. Puede utilizar el servicio de enrutamiento y acceso remoto de Windows 2000 Server para crear túneles VPN de sitio a sitio. Si no hay dispositivos VPN disponibles, debe configurar el firewall Edge o los filtros de enrutador para limitar el tráfico que se permite que fluya entre los rangos de direcciones de Protocolo de Internet (IP) que utiliza cada sitio. Si los sitios necesitan usar la replicación de Active Directory solo en Internet, entonces use el modo de transporte de seguridad del Protocolo de Internet (IPSec) a través de los firewalls para proteger todo el tráfico entre los servidores de Active Directory. Para obtener más información sobre la replicación de Active Directory a través de firewalls, consulte el documento técnico "Replicación de Active Directory sobre firewalls" en el sitio web de Microsoft | http: //www.Microsoft.com/serviceproviders/columns/config_ipsec_p63623.asp.

Protección de los puertos de autenticación y NetBIOS contra ataques de Internet: En el firewall o en el enrutador que conecta su red interna a Internet, bloquee el acceso a TCP y puertos UDP 135 a 139 y puerto 445. Si no hay un dispositivo de filtrado Edge disponible, puede usar filtros IPSec para bloquear estos puertos. Para ello, use la configuración que se describe en "Cómo bloquear Protocolos y puertos de red específicos mediante IPSec "en Microsoft Knowledge Base | http: //support.Microsoft.com/? Id = 813878.

• En la misma política IPSec, debe crear una regla adicional que agregue filtros para permitir el tráfico a estos puertos cuando la dirección de origen se encuentre en una subred que utiliza la red interna. Para hacerlo, use la configuración que se describe en "Cómo bloquear protocolos y puertos de red específicos mediante IPSec" en Microsoft Knowledge Base | http: //support.Microsoft.com/? Id = 813878.

Protección de los puertos de autenticación y NetBIOS contra ataques internos: Si debe proteger el acceso a los puertos de autenticación y NetBIOS de usuarios malintencionados internos, puede restringir las computadoras que se les permite obtener acceso a estos puertos solo a las computadoras miembros del dominio mediante el uso de la función en IPSec que le permite negociar la seguridad. Al permitir que solo las computadoras confiables (computadoras miembros del dominio) tengan acceso a los puertos de autenticación y NetBIOS, reduce la cantidad de computadoras que pueden realizar el ataque. Esta protección adicional proporciona una defensa contra cualquier violación en su perímetro de seguridad y contra usuarios maliciosos que pueden conectarse a la red interna. Para obtener información sobre cómo crear una política IPSec personalizada para utilizar la autenticación Kerberos al negociar la seguridad IPSec para acceder a TCP y los puertos UDP 135 a 139 y el puerto 445, consulte la "Guía paso a paso para Internet Protocol Security (IPSec) "en el sitio web de Microsoft | http: //www.Microsoft.com/windows2000/techinfo/planning/security/ipsecsteps.asp.

Actualice el servidor: Mantenga todos sus servidores actualizados con las versiones actuales de software antivirus, software de firewall y parches de seguridad de Windows. Esto ayuda a evitar que los programas de troyanos y los virus ataquen sus recursos si el usuario malintencionado puede lanzar un ataque desde su red interna en lugar de hacerlo desde Internet. Estas actualizaciones son una parte importante de una estrategia de seguridad profunda y defensiva.

9
Tate Hansen
  1. Detección
    • Necesita controles de auditoría para alertarlo sobre una alta frecuencia de bloqueos de cuentas
  2. Defensa
    • Una idea es rastrear la dirección IP de origen que está causando el bloqueo de la cuenta. Después de que esta dirección IP src haya cruzado un umbral definido (digamos 2 cuentas en 10 segundos), se le solicita al usuario un CAPTCHA que debe completarse con éxito para continuar los intentos de autenticación en el sitio web. Esto evitaría que el atacante pudiera ejecutar un ataque de bloqueo de cuenta.
    • Después de que la dirección IP src haya cruzado un segundo umbral (por ejemplo, 10 cuentas bloqueadas en 60 segundos), la dirección IP se bloquea durante X minutos. Claro, esto podría bloquear a otros usuarios si el atacante está detrás de un NAT corporativo, pero es una opción que puede usar para defender su aplicación.

Si el atacante está usando múltiples servidores proxy y ha programado un ataque de bloqueo de cuenta que aprovecha una variedad de direcciones IP de origen, entonces no podrá usar estas ideas. Sin embargo, es de esperar que los controles de detección en el paso 1 hayan alertado a un administrador que puede investigar el problema manualmente.

Nada de esto está integrado en LDAP; todo sería un código personalizado.

  • Miguel
7
Michael Coates

Lo primero que viene a la mente es observar múltiples inicios de sesión fallidos en varias cuentas una vez que han sido bloqueados. P.ej. Eve prueba la cuenta de Bob 10 veces y queda bloqueada. Luego prueba la cuenta de Tim y queda bloqueada. Después de un número n de cuentas, tiene una idea bastante buena de que alguien está tratando de hacer las cuentas. Sin embargo, esto realmente no resuelve su problema, solo le permite auditarlo.

Una solución simple sería separar los bloqueos de inicio de sesión por red, por lo que si intenta iniciar sesión a través de la extranet y quedar bloqueado, aún puede iniciar sesión localmente. Dicho esto, no estoy seguro de cómo puede hacerlo a través de Active Directory, ni estoy seguro de qué tipo de implicaciones tiene esto.

3
Steve

Si por alguna razón no puede realmente segregar sus puntos de autenticación públicos de las cuentas de usuario internas, entonces enfrenta la posibilidad de tener que lidiar constantemente con usuarios bloqueados. Incluso si no hay una amenaza inmediata de incumplimiento, esto podría sobrecargar a su equipo de administración con solicitudes de desbloqueo.

Además, hay otro aspecto: el bloqueo de cuenta puede convertirse en un problema incluso en la red interna. En el pasado, se sabía que el malware intentaba forzar cuentas brutas para propagarse (por ejemplo, algunas versiones de conficker intentaban ataques de diccionario en los recursos compartidos de ADMIN $), lo que podría generar situaciones incómodas para los administradores.

Por lo tanto, sugeriría:

  1. considerar cuidadosamente sus políticas de bloqueo para evitar un bloqueo completo
  2. para ajustar sus dispositivos de seguridad de "desbloqueo" para permitir el eventual desbloqueo

LockOutThreshold, ObservationWindow, y LockOutDuration todos pueden ayudar con esto. Para conocer su uso exacto, verifique MS Mejores prácticas de bloqueo de cuenta .

Un enfoque que pensaría (más sugerencias en el documento anterior) son:

usuarios normales :

  • número medio o alto de intentos (para ayudar a los usuarios olvidadizos),

  • (relativamente) ventana de observación corta (para evitar ataques de fuerza bruta),

  • liberación rápida, quizás 15'-30 '(para salvar el servicio de asistencia de esas llamadas ...)

administradores :

  • pequeño número de intentos (deben saber la contraseña),

  • ventana de observación un poco más larga (la complejidad de la contraseña debería ofrecer cierta protección contra la fuerza bruta),

  • liberar después de unas horas

¿Tus ideas?

2
George