Prevención de fugas de información en logs. Campo Passwords y Mod security
Cuando un atacante pretende comprometer un sistema, una de las ubicaciones que debe observar son los logs. Imaginaros el caso de un sistema comprometido, en el que el atacante accede a los logs del sistema, en el que se muestran en claro los usuarios y contraseñas de nuestros usuarios. Se lo pondríamos muy fácil.
En algún cliente me ha ocurrido la situación de presentar una solución tipo Snort, Mod Security e incluso un simple Squid Proxy para proporcionar elementos de seguridad, y ser la propia gerencia la que descartaba este tipo de soluciones por la exposición de información sensible, y casi siempre personal, al departamento IT o el departamento que accede a los logs ( redundante, los informáticos lo vemos todo, desde el de micro-informática hasta el sysadmin-boss).
Con un proxy podemos ver los hábitos de navegación de nuestros director de ventas, que son muy decorosos...Con Snort podemos detectar aplicaciones prohibidas, como pueda ser el famoso BroadCast de Dropbox...
Para proporcionar un nivel de seguridad y confianza en la gestión de logs de Mod Security, vamos a crear una pequeña regla al respecto.
Lo que hacemos es crear una regla tan sencilla como la siguiente. Con ella simplemente lo que hacemos es que en fase 5,la parte de logging, sanitice !*"!^·*!^"*·! (limpie los caracteres de un campo con asteriscos).
SecRule &ARGS:password "@eq 1" "phase:5,t:none,id:123458,nolog,pass,sanitiseArg:password"
Esta regla de por sí no generará alarma, simplemente que en nuestras reglas existentes, cuando detecte un campo password, "limpiará" el registro con ****.
Veamos un ejemplo. Lanzo un "ataque" ficticio sobre una aplicación, para que salte cualquiera de las alarmas que tenemos configuradas ( en este caso salta una alarma por hacer match de la palabra UNION).
Como puedes ver, aparece la contraseña en claro.
Sin embargo una vez activada nuestra nueva regla, podemos comprobar que el mismo ataque, genera la misma alerta, pero limpia el campo.
Como puedes ver, esta simple regla puede propiciar que gerencia vea con buenos ojos tu medida de seguridad, y no estés viendo todas las passwords de los clientes. Pobres ilusos xD pero bueno, creo que todo el mundo es consciente de que este tipo de información es manejada por el departamento IT.
Como siempre, espero que os guste, gracias por leerme !!!
En algún cliente me ha ocurrido la situación de presentar una solución tipo Snort, Mod Security e incluso un simple Squid Proxy para proporcionar elementos de seguridad, y ser la propia gerencia la que descartaba este tipo de soluciones por la exposición de información sensible, y casi siempre personal, al departamento IT o el departamento que accede a los logs ( redundante, los informáticos lo vemos todo, desde el de micro-informática hasta el sysadmin-boss).
Con un proxy podemos ver los hábitos de navegación de nuestros director de ventas, que son muy decorosos...Con Snort podemos detectar aplicaciones prohibidas, como pueda ser el famoso BroadCast de Dropbox...
Para proporcionar un nivel de seguridad y confianza en la gestión de logs de Mod Security, vamos a crear una pequeña regla al respecto.
Lo que hacemos es crear una regla tan sencilla como la siguiente. Con ella simplemente lo que hacemos es que en fase 5,la parte de logging, sanitice !*"!^·*!^"*·! (limpie los caracteres de un campo con asteriscos).
SecRule &ARGS:password "@eq 1" "phase:5,t:none,id:123458,nolog,pass,sanitiseArg:password"
Esta regla de por sí no generará alarma, simplemente que en nuestras reglas existentes, cuando detecte un campo password, "limpiará" el registro con ****.
Veamos un ejemplo. Lanzo un "ataque" ficticio sobre una aplicación, para que salte cualquiera de las alarmas que tenemos configuradas ( en este caso salta una alarma por hacer match de la palabra UNION).
Como puedes ver, aparece la contraseña en claro.
Sin embargo una vez activada nuestra nueva regla, podemos comprobar que el mismo ataque, genera la misma alerta, pero limpia el campo.
Como puedes ver, esta simple regla puede propiciar que gerencia vea con buenos ojos tu medida de seguridad, y no estés viendo todas las passwords de los clientes. Pobres ilusos xD pero bueno, creo que todo el mundo es consciente de que este tipo de información es manejada por el departamento IT.
Como siempre, espero que os guste, gracias por leerme !!!
