¿Hay alguna característica específicamente en Spring 3.0 MVC que ayudaría a implementar la detección de un ataque de fuerza bruta en la página de autenticación/inicio de sesión de una aplicación web?¿La mejor forma de que una aplicación web Spring MVC detecte un ataque de fuerza bruta?
Sorprendentemente, no pude encontrar nada en los documentos de referencia para Spring MVC o Spring Security.
Sí, sin embargo, encontré this 3 year old tutorial que describe cómo se puede hacer usando Splunk.
La práctica comprobada hace tiempo es introducir un retraso aleatorio pero considerable si la autenticación ha fallado.
De esta forma, los usuarios legítimos iniciarán sesión de inmediato, pero un atacante gastará 500ms-1 por intento, lo que hace que toda la idea de la fuerza bruta sea poco práctica (llevará una eternidad).
El inicio de sesión fallido ocasional por usuarios legítimos les causará solo un pequeño retraso y pasará desapercibido.
Si necesita para ser notificado sobre los inicios de sesión fallidos repetidos, es necesario implementar una serie de impresión del informe de inicios de sesión fallidos consecuentes por usuario, por orden de ese límite desc número 100.
P. S. Here es una publicación que explica cómo recibir notificaciones en el intento de inicio de sesión. Siguiendo el mismo enfoque, uno puede introducir un retraso, creo.
Buena idea. Incluso se puede incrementar el tiempo de demora exponencialmente, como creo que algunos sistemas operativos lo hacen. –
La respuesta corta es no, por lo que sé, Spring 3.0 MVC no tiene nada que lo ayude a detectar un ataque de fuerza bruta. No creo que Spring 3.0 tenga nada tampoco para ese asunto.
Sin embargo, debe poder implementar algo usted mismo extendiendo algunos de los UserDetailsServices.
A veces es aconsejable registrar todos los intentos de inicio de sesión, exitosos o no. Si está registrando todas las fallas (como en una base de datos), debería poder determinar si alguien/algo está intentando un ataque de fuerza bruta en su sitio.
Debería considerar los intentos de acceso a la aceleración como @road to yamburg.
También considere agregar captcha a su página de inicio de sesión, reCAPTCHA de Google es muy fácil de integrar en cualquier aplicación. Here es la documentación para usarlo con Java/JSP
Es posible por algunas configuraciones y codificación en Spring security.
Por cierto, no sugiero retrasar un poco las pruebas de inicio de sesión sospechosas no válidas. Puede retrasar un poco para responder a un intento de inicio de sesión sospechoso, pero este retraso le cuesta suspender un hilo por un tiempo en su aplicación. Esto puede proporcionar un ataque DoS o DDoS en su sistema si hay una gran cantidad de inicios de sesión no válidos simultáneamente a su aplicación.
El mejor enfoque es hacer una respuesta rápida a un inicio de sesión inválido sospechoso pero al mismo tiempo suspender la cuenta de usuario por la cual el usuario intenta iniciar sesión. De esta manera, la evitación de ataque de fuerza bruta no conduce a la provisión de ataques de Dos o DDoS.
Sin embargo, la suspensión de la cuenta del usuario también proporcionaría una forma para el ataque DoS, ya que puede llevar a la falla en la entrega del servicio al usuario real. Pero, los escenarios de seguridad correctos serían útiles en estos casos. Por ejemplo, si se detecta un ataque de fuerza bruta, es posible que:
Todo esto depende de sus escenarios de dominio y de servicios. Como ejemplo, puede implementar su propio UserDetailsService y detectar ataques de fuerza bruta en esta implementación. Para implementar el último escenario de Spring Security, el siguiente código declara un administrador de autenticación al que se le pasa un UserDetailsService personalizado, que es JdbcDaoImpl aquí (tenga en cuenta que los nombres y las consultas de los paquetes deben modificarse para su propio paquete y modelo de datos) .
<authentication-manager alias="authenticationManager" xmlns="http://www.springframework.org/schema/security">
<authentication-provider user-service-ref="CustomUserDetailsService" />
</authentication-manager>
<!--
This bean is to provide jdbc-user-service.
Also, it provides a way to avoid BFD along with AuthenticationFailureListener
-->
<bean id="CustomUserDetailsService" class="com.example.CustomUserDetailsService">
<property name="dataSource" ref="dataSource" />
<property name="usersByUsernameQuery" value="SELECT user_client.user_name, user_client.password, user.is_active
FROM user_client INNER JOIN user ON user_client.fk_user = user.ID
WHERE user_client.user_name=? "/>
<property name="authoritiesByUsernameQuery" value="SELECT user_client.user_name, CONCAT('ROLE_',user_client.client_id)
FROM user_client WHERE user_client.user_name=? "/>
</bean>
El CustomUserDetailsService detecta si hay un ataque de fuerza bruta sucediendo o no, junto con AuthenticationFailureListener que discuto pronto. FailedLoginCacheManager es un contenedor de ehcache que mantiene los inicios de sesión fallidos (nombres de usuario) con sus cantidades relativas fallidas. El caché se establece con un timeToIdleSeconds adecuado para que la suspensión de la cuenta sea temporal.
public class CustomUserDetailsService extends JdbcDaoImpl {
@Autowired
private FailedLoginCacheManager cacheManager;
@Override
public UserDetails loadUserByUsername(String username) throws UsernameNotFoundException {
if (cacheManager.isBruteForceAttackLogin(username)) {
//throw some security exception
...
}
return super.loadUserByUsername(username);
}
}
Además, un ApplicationListener se implementa para detectar intentos de acceso fallidos y conservarlos dentro de la ehcache.
@Component public class AuthenticationFailureListener implements ApplicationListener<AuthenticationFailureBadCredentialsEvent> {
@Autowired
private FailedLoginCacheManager cacheManager;
@Override
public void onApplicationEvent(AuthenticationFailureBadCredentialsEvent event) {
UsernamePasswordAuthenticationToken token = (UsernamePasswordAuthenticationToken) event.getSource();
String userName = token.getPrincipal().toString();
cacheManager.updateLoginFailureStatus(userName);
}}
No hay necesidad de discutir más sobre el servicio FailedLoginCacheManager sino dos métodos principales que se discuten aquí se podrían implementar como los métodos siguientes:
public void updateLoginFailureStatus(String userName) {
Cache cache = manager.getCache(CACHE_NAME);
Element element = cache.get(userName);
if (isValid(element)) {
int failureCount = (Integer)element.getObjectValue();
cache.remove(userName);
cache.put(new Element(userName, ++failureCount));
} else {
cache.put(new Element(userName, 1));
}
}
public boolean isBruteForceAttackLogin(String username) {
Cache cache = manager.getCache(CACHE_NAME);
Element element = cache.get(username);
if (isValid(element)) {
int failureCount = (Integer)element.getObjectValue();
return failureCount >= 3;
} else {
return false;
}
}
esto depende de su entorno. Cuando controlas el entorno del servidor y registras todos los intentos de inicio de sesión, puedes usar fail2ban. O simplemente escribe algo similar como fail2ban dentro de tu proveedor de autenticación o solicita filtro – BlueWizard