¿Cuáles son los enfoques seguros para manejar un script que requiere una contraseña de base de datos (MySQL)?

Question

Obviamente, no deseamos hardcode la contraseña del texto plano en cada secuencia de comandos. Esto dificultaría la ciclación de la contraseña, ya que habría que cambiar una tonelada de scripts además de la contraseña en texto plano en primer lugar.

Si las secuencias de comandos toman la contraseña como parámetro, entonces tenemos que preocuparnos de modificar la salida 'ps' para que no se muestre el valor del argumento de la contraseña. También tendríamos que preocuparnos de que el comando se grabe en el historial de shell. Esto se puede manejar potencialmente a través de HISTIGNORE/HISTCONTROL en bash, pero hay otros shells en uso con control de historial diferente y menos flexible (por ejemplo, zsh). También podríamos usar una variable de entorno específica de línea de comando (FOO = bar ./script), y mientras que 'FOO = bar' no aparecerá en 'ps', todavía está, por defecto, registrado en el historial de shell. Además, algunos sistemas exponen los entornos de proceso de otros usuarios (a través de 'ps') de todos modos.

Se puede usar un archivo de contraseña (configuración) que simplemente almacena la contraseña de texto sin formato. Este archivo podría ser propiedad/autorizado para reforzar su acceso. Pero, al final del día, todavía tienes una contraseña en texto plano.

La solicitud también es una opción, pero esto tiende a ser menos conveniente (aún posible a través de esperar, por ejemplo, sin embargo) y complica la falta de interactividad si el script así lo requiere.

Se podría usar cifrado de algunos sabores, pero todavía tenemos un problema similar al tratar con la clave de descifrado.

¿Debo seguir con uno de los anteriores de todos modos? ¿Las otras opciones pueden ser superiores? ¿Cómo manejan las personas esta situación de manera segura?

El objetivo general aquí es que un atacante no debería ser capaz de comprender el servidor de la base de datos si el atacante llega de alguna manera a un sistema que hace uso del servidor de la base de datos. Por ejemplo, un ataque no debería ser capaz de encontrar la contraseña en algún lugar, no debería ser capaz de observar el sistema ('ps') para descubrirlo, y no debería ser capaz de "mirar atrás en el tiempo". (historial de shell) para encontrarlo.

Estoy perfeccionado sabiendo que hay millones de escenarios (kmem, páginas intercambiadas, etc. etc.) y que la mayoría de las apuestas están desactivadas si el atacante obtiene acceso raíz o físico y que nada va a ser 100% seguro Estoy realmente buscando el mejor enfoque dentro del motivo. :-)

Answer 1

Si los scripts no usan mensajes, y de alguna manera conocen la contraseña de db, entonces el atacante puede ejecutar cualquiera de sus scripts y hacer esas mismas cosas.

Si solicita una contraseña, tendrá que dársela a algunas personas, que la colocará en sus scripts, o creará una contraseña para cada usuario, que proporciona varias contraseñas para adivinar (y aún así pondrán en sus guiones).

Quizás una cosa a tener en cuenta es tener un usuario sin contraseña que solo puede seleccionar en las tablas apropiadas y solo puede iniciar sesión desde hosts particulares y requerir contraseñas y otros usuarios para funciones más sensibles.

Si desea ocultar la contraseña, siempre puede tener un sistema de 2 partes. Aunque puede hacer cosas muy complicadas, XOR (bitwise exclusive o, que está en perl y en la mayoría de los demás idiomas) también puede ser su amigo. Es simple para el administrador y para el atacante, ninguna pieza es útil. Un atacante automático podría pasar a un terreno más fértil. Incluso puede mantener una de las partes en otro host y buscarla con wget o nfs o lo que sea. De esa forma podría ser desconectado como parte de un sistema de trampa.

Mientras tanto, tal vez necesites algún tipo de trampas o trampas tipo honeypots, de modo que si los tipos malos te llaman, puedes darles desinformación o incluso cerrar las cosas más rápido. Me gusta fail2ban para firewalls activos. Puede escanear archivos de registro y bloquear direcciones IP que le envían crud que no desea basándose en cualquier cosa que aparezca en sus registros. Utiliza expresiones regulares y cualquier archivo de registro para definir un incidente y tiene cierta flexibilidad en el motor de reglas.

Answer 2

No soy un administrador de Unix, pero ... ¿Qué tal si los scripts se ejecutan bajo una cuenta sin inicio de sesión y establece los permisos en el script (y el archivo de contraseñas) en 500. Eso limitaría el acceso a la raíz y el usuario del script.

Answer 3

Que le gustaría explorar TPM (http://en.wikipedia.org/wiki/Trusted_Platform_Module)

Muchos productos de seguridad utilizan TPM para almacenar claves relacionadas con la seguridad crítica. Otra idea podría ser encriptar la contraseña usando un certificado almacenado en una tarjeta inteligente.

Saludos, GK

Answer 4

Se puede poner un archivo en el directorio .my.cnf (s) Casa de usuarios que pueden acceder a la secuencia de comandos, con su información y MySQL puede leerla desde allí en lugar del comando línea. También deberá establecer una variable de entorno para apuntar a ~/.my.cnf, pero ... No estoy seguro de si es MYSQL_HOME o SYSCONFDIR o alguna otra cosa *. Todavía sería un archivo de texto sin formato, pero si restringe ese archivo a propietario, ¿estaría bien? Al menos mantendrá las contraseñas fuera de ps.

MySQL: Option Files y MySQL: Password Security páginas de doc ambos insinúan esto un poco.

(* Nota: No soy un administrador por definición, sólo lo suficiente para meter en problemas)

Answer 5

Dependiendo del grado de gravedad de los datos es, se podría implementar diversas medidas.

Almacenar la contraseña en un archivo legible solo por root. El script que lee las claves debe comenzar como root, leer la contraseña, establecer la conexión de base de datos utilizando la cuenta de base de datos con el mínimo privilegio requerido, borrar la contraseña de la memoria y luego desplegable (How can I drop privileges in Perl? puede ayudar) a una cuenta del sistema no privilegiado.

tiene secuencias de comandos simples/gatillo para controlar sesiones de bases de datos (inicio de la sesión y la hora de finalización, el usuario, la dirección IP, los comandos ejecutados) en el servidor de base de datos, controlar el uso de sudo en el sistema, etc.