Usuarios falsos en la base de datos para la detección de compromiso

Crear un honeypot es una técnica utilizada comúnmente en la seguridad de la información, aunque probablemente no sea la mejor idea para un entorno de producción. Aparte del hecho de que agrega riesgos potencialmente nuevos a su aplicación, es posible que no haya tanta necesidad de dicha trampa.

La mayoría de las aplicaciones (y / o demonios del servidor) pueden monitorear los inicios de sesión fallidos, lo que debería proporcionarle información más que suficiente sin poner en riesgo su aplicación.

Para establecer lo obvio; los ataques de fuerza bruta son (desafortunadamente) un fenómeno común y es probable que afecten tu aplicación de todos modos.

Llego un poco tarde al juego, pero como casi no estoy de acuerdo con las otras respuestas aquí hasta ahora, estoy presentando una nueva.

Las principales cosas con las que no estoy de acuerdo con las otras respuestas son:

1. Agregar usuarios a la base de datos no es lo mismo que crear un honeypot. (Probablemente sea posible tomar una definición de honeypot e interpretarla de tal manera que pueda considerarse un honeypot, pero creo que es un tramo). Supongamos que agrega 10 usuarios solo para que su equipo de control de calidad los utilice para las pruebas. Si observa que alguno de esos usuarios ha iniciado sesión fuera de las horas normales de prueba, o por IP que no se esperan, estaría logrando lo mismo, y seguramente no llamaría honeypot a esos usuarios de control de calidad.

2. Agregar usuarios adicionales al sistema no hace que el sistema sea más vulnerable. Si eso fuera cierto, entonces cada vez que un nuevo usuario crea una cuenta, el sistema se volvería más vulnerable. ¡Eso sería bastante triste si fuera verdad!

En cuanto a si sería útil agregar usuarios al sistema, la respuesta depende de lo que realmente haga su aplicación. Si su base de datos de usuario está comprometida, ¿qué preferiría tener el atacante: la información contenida en la base de datos (como nombres de usuario / contraseñas / direcciones de correo electrónico) o preferirían tener acceso al sitio web? Considera:

• Si el sitio maneja banca, entonces un atacante probablemente intentará iniciar sesión con muchas cuentas y mover dinero o recopilar información de la cuenta. (Los usuarios "adicionales" pueden tener intentos de inicio de sesión en este caso).
• Si el sitio es solo un foro gratuito, es probable que al atacante no le importe iniciar sesión y, en su lugar, considere vender las direcciones de correo electrónico, o intente brutal forzar los hashes de contraseñas para adivinar contraseñas en sitios de banca o comercio electrónico. ( Este podría ser el escenario más probable. )
• Si el sitio tiene un contenido de pago interesante que el atacante desea, pueden elegir un solo usuario e iniciar sesión con él. (Lo cual es poco probable que sea uno de los usuarios "adicionales").

Por lo tanto, en el primer caso, monitorear a los usuarios "adicionales" podría ser algo útil, pero en la mayoría de los casos probablemente no lo sea.

Dicho esto, si aún quieres intentarlo, quizás el enfoque más efectivo sea el siguiente:

1. Cree dos nuevas cuentas de correo electrónico con direcciones muy difíciles de adivinar, contraseñas extremadamente difíciles, y luego configúrelas para reenviarlas a su cuenta de correo electrónico principal que verifique con frecuencia.
2. En su sitio, cree un nuevo usuario con cada una de esas direcciones de correo electrónico, ambas con muy difíciles de adivinar nombres de usuarios .
3. Dé a uno de los usuarios una contraseña muy difícil, y del otro una contraseña fácil.

Ahora ha logrado dos cosas: si alguno de esos usuarios alguna vez inicia sesión (probablemente será el que tenga la contraseña fácil), entonces su base de datos probablemente esté comprometida. O, si alguna vez recibe un correo electrónico a una de las direcciones de correo electrónico de esa cuenta, es probable que su base de datos haya sido comprometida y que las direcciones de correo electrónico hayan sido vendidas.

Reflexión final: arriba, donde mencioné el escenario más probable (el atacante intenta recopilar usuarios / correos electrónicos / contraseñas para su uso en otros sitios), en ese caso, es posible que nunca inicien sesión o vendan / envíen correos electrónicos no deseados, y si es así Desafortunadamente, será bastante difícil detectar esto fuera del monitoreo de todos los accesos al servidor DB.

Esto podría ser útil para la evaluación de vulnerabilidad con credenciales, pero desde el punto de vista de la producción, está poniendo en riesgo su aplicación. Este podría ser un posible vector de ataque para un atacante.

El atacante puede obtener acceso a estas cuentas y puede encontrar formas de explotar y obtener derechos administrativos o una escalada de privilegios.

El concepto que intentabas decir es un Honeypot (monitoreando lo que podría hacer el atacante), pero los Honeypots están diseñados para ser comprometidos. Creo que no querrás que tu aplicación se vea comprometida.

1 regla en Application Hardening es deshabilitar cuentas innecesarias / cuentas predeterminadas / cuentas de invitados / cuentas compartidas.

Me parece una buena idea, pero con una advertencia: debe asegurarse de que no haga que su sistema sea MÁS vulnerable. Me doy cuenta de que esto es técnicamente imposible, ya que otra cuenta de usuario es otra forma de ingresar, pero esto es lo que sugiero si decides implementarlo:

• No use un nombre de usuario común, como admin. Es probable que esto se vea afectado por los ataques pasivos de host múltiples que solo se analizan.
• Haga que la contraseña sea insana, incluso poco práctica y compleja, ya que no hay ninguna intención de que se use la cuenta.
• Supervise intente los accesos, así como también los éxitos, aunque tiene mayores problemas si hay un éxito.
• Finalmente, uno de esos problemas más grandes: ASEGÚRESE DE QUE USTED HAGA SUS CONTRASEÑAS. Esto debería ser de sentido común, pero se sorprenderá. Si sus contraseñas no están ocultas, entonces un compromiso de la base de datos HARÁ el acceso a todas las cuentas.

Nota final: otros usuarios han mencionado la razón por la que es tan importante ir para los intentos de acceso en lugar de los accesos exitosos: la escalada de privilegios es probable probablemente si pueden entrar.