¿Cómo evitar scripts con contraseña codificada? [duplicar]

Puede crear clave pública / privada pares y cifrar la contraseña. Esto debería ofuscar la contraseña a los transeúntes ocasionales, ya que solo conocerían la parte pública de la clave.

También debe proteger la secuencia de comandos mediante los permisos de directorio y archivo.

Además, (dependiendo de la base de datos), debería poder crear una cuenta de usuario para la base de datos que solo tiene privilegios de respaldo. Esto evitaría que alguien creara tablas, volcara tablas y reemplazara contenidos. Puede limitar el acceso a este usuario a los tiempos en que espera que se ejecuten las copias de seguridad.

Actualizar

Esta publicación en Comodo explica las claves un poco mejor . Ya que le preocupa que alguien obtenga acceso a la contraseña original que existe en el código, el atacante tendría que escuchar la clave privada del usuario que activa el script (lo que podría ocurrir a través de SSH en un cron en un [virtual] separado máquina). Obviamente, no tendría ningún sentido si almacenara ambas claves en el mismo sistema a menos que, por supuesto, almacenara la clave privada con mayores privilegios que la clave pública.

Ambas teclas juntas = contraseña

Acerca de los permisos, si alguien tiene acceso a su sistema y esto es una gran preocupación para que una contraseña se almacene en la caja en un "formato legible", parece que hay problemas más profundos con la configuración de permisos en el caja en sí. Además, si alguien puede sudo y supera sus propios privilegios (como el host que ejecuta el cuadro), el hashing de claves es realmente la única opción para evitar que el usuario administrador ingrese a la base de datos.

Además, deberías deshabilitar la cuenta root en la base de datos, ya que esto permitiría al atacante leer las tablas de la base de datos de todos modos.

Como se mencionó en otras respuestas, sus credenciales estarán en un lugar accesible a su script.

Pero los pondría en un archivo de configuración separado que será leído por su script.

Tendrás las siguientes ventajas:

• puede usar el mismo script para varios sistemas (con diferentes archivos de configuración)
• podrá compartir el script con otros (o mostrárselo a alguien sin comprometer sus credenciales)

Teniendo en cuenta la naturaleza automatizada del script, no creo que haya una mejor manera de almacenar la contraseña además de codificarla.

Mi recomendación sería bloquear el script con los permisos adecuados del sistema de archivos UNIX. Crear el script -rwx------ y establecer el propietario y el grupo en los valores adecuados contribuirá en gran medida a proteger la contraseña.

Por supuesto, tenga las medidas de registro adecuadas para detectar si el script se ha comprometido. Si es así, cambie la contraseña en el servidor de la base de datos inmediatamente.

Me gusta la respuesta de @ absolute acerca de cifrar las credenciales con un par de claves, también agregaré que para las soluciones basadas en Windows, solo he usado C # en lugar de un script de powershell a veces; ya que ambos están basados en .NET, solo puedo compilar mi solución y lanzar las credenciales allí.

Entonces, quizás pueda crear un ejecutable compilado que llame al script y pase las credenciales como un parámetro, o incluso una copia cifrada de las credenciales como un parámetro que su script pueda descifrar.

Sí , estoy aware que los credos todavía pueden ser arrancados del exe en ciertas circunstancias, pero esto es específicamente para el Situación de OPs de evitar creditos de texto claro.

Quizás estás haciendo la pregunta equivocada. Si bien es correcto preocuparse por las secuencias de comandos con credenciales de autenticación codificadas, la pregunta real es cómo administrar las credenciales de autenticación utilizadas por las secuencias de comandos automatizadas y, lo que es más importante, cuáles son las mayores amenazas o riesgos asociados con el sistema. Los diferentes sistemas tienen diferentes riesgos. Debe comprender los riesgos más relevantes para su situación para evaluar qué acciones son las más adecuadas. En general

• No credenciales de autenticación codificadas. Póngalos en un archivo / ubicación por separado y haga que su script use la información. Esto tiene la ventaja de hacer que sea más fácil cambiar sus contraseñas, ya que no necesita editar sus fuentes y puede hacer que múltiples scripts utilicen la misma fuente, lo que le permite cambiar las contraseñas en un solo lugar.

• Obtenga los permisos, usos y grupos. Utilice las instalaciones disponibles para restringir el acceso.

• Use las características de refuerzo adicionales de su sistema operativo. Por ejemplo, Linux usa SELinux o AppArmor (creo que ubuntu se basa en apparmor). Defina las políticas adecuadas para restringir el acceso solo a lo absolutamente necesario.

• Comprenda y use las herramientas disponibles: ssh, sudo, chroot etc.

Saber y comprender dónde están sus amenazas determinará qué técnicas e instalaciones son las más adecuadas y si las instalaciones predeterminadas son suficientes o si necesita aumentar las cosas e instalar precauciones adicionales. No pase por alto la importancia de la auditoría y el análisis de registros. Una cosa es poner protección en su lugar. Otra cosa es saber cuándo su protección ha fallado y usted ha sido comprometido. Puede ser malo que su sistema se vea comprometido, pero es mucho peor que esté comprometido y no lo sepa.

Si está usando ssh para iniciar sesión en el servidor de base de datos, puede configurar ~ / .ssh / authorized_keys en el servidor de base de datos para incluir ~ / .ssh / id_dsa.pub o ~ / .ssh / id_rsa Archivo .pub en su sistema ubuntu. Podrás iniciar sesión sin contraseñas.

Si no tiene un archivo en ~ / .ssh / id_dsa.pub, busque cómo crear uno con ssh-keygen