Cómo defenderse contra un atacante sin afectar a otros usuarios de la misma puerta de enlace NAT

Question

Cómo defenderse contra un atacante sin afectar a otros usuarios de la misma puerta de enlace NAT

#1 de user7859067 (1 votos)

1

Estoy implementando un servicio web y tengo un proceso de daemon que detecta repetidos intentos fallidos de inicio de sesión desde cualquier fuente dada. Si se producen demasiados, la dirección IP se bloquea durante un tiempo determinado.

Esto es similar a los paquetes fail2ban o (ahora en desuso) denyhosts.

Mi preocupación es si el mal actor está detrás de una puerta de enlace NAT para una organización grande (una universidad o Fortune 1000 por ejemplo), entonces la prohibición afectará a todos los que están detrás de esa puerta de enlace, no solo a la única estación que ejecuta los ataques de diccionario.

¿Hay algún método viable para evitar ese efecto secundario?

ACTUALIZACIÓN: cambié el título según la sugerencia y se me ocurre que este problema se aplica a casi cualquier tipo de ataque, no solo al ataque del diccionario que describí.

dictionary nat

pregunta AlanObject 26.04.2017 - 22:20

fuente

1 respuesta

Lea otras preguntas en las etiquetas dictionary nat

¿Existen razones para firmar archivos transportados a través de TLS? Intercambio de claves durante la fase IKE_AUTH de IKEv2

score 1 · Answer 1

Su solución es fácil de configurar / codificar, pero no es tan justa como usted dijo, la ip podría ser no solo para una persona.

Podría venir con las siguientes alternativas:
1:
Si el ataque es para un usuario en particular (digamos usuario a ), entonces, después de algunos inicios de sesión fallidos, deshabilite la cuenta y envíe un correo electrónico / notificación al usuario para activar su usuario, y / o activar la cuenta después de 24 horas del último ataque.
Deshabilitar la cuenta significa rechazar tanto la autenticación errónea como la correcta para el usuario en cuestión, y en lugar de decir que esta cuenta está deshabilitada o que la contraseña es incorrecta, indique que es un nombre de usuario o contraseña no válidos.

2:
Después de algún ataque desde la ip, solicite captcha para los próximos intentos de inicio de sesión y siempre verifique primero el captcha. Si el atacante comienza a continuar atacando con distintas IP para omitir el captcha, actúe de manera más inteligente y solicite el captcha de todas las solicitudes (suponga que es un código de seguridad para su servidor). Captcha (si es lo suficientemente bueno) te asegura que el atacante no sea un robot (que es el 99%).
Incluso si el atacante pudiera superar el captcha, vuelva al plan 1 nuevamente, deshabilite al usuario debido a demasiados inicios de sesión fallidos.