Prevención de que las contraseñas de los usuarios se almacenen como texto sin formato en el historial de bash

3

Diga que quiero encontrar la contraseña de una cuenta de usuario de Linux sudoer. Supongamos que usa una contraseña segura. Supongamos que tengo acceso físico a la máquina. Puedo obtener su archivo de contraseñas y sombras y forzarlo durante días, o simplemente obtener una copia de su archivo de historial de bash y utilizarlo como una lista de palabras.

No soy un hacker, pero este método ha funcionado muchas veces cuando quería secuestrar la cuenta de alguien. En mi Openion, muchas personas accidentalmente escriben su contraseña en la línea de comandos, especialmente si no son de tipo táctil.

Lolz, no toco tipo tampoco. Tampoco los usuarios de los sistemas que gestiono. ¿Cómo puedo asegurarme de que mi contraseña súper segura no se almacene como texto sin formato en mi .bash_history ?

Sé que puedo seguir eliminando el historial de bash, pero ¿hay otros medios?

    
pregunta daltonfury42 02.10.2015 - 15:14
fuente

3 respuestas

3

No puedes, y no debes intentarlo por las siguientes razones:

  1. Capacidad técnica imperfecta (semántica)
  2. Capacidad técnica imperfecta (registro centralizado)
  3. Vectores alternativos (tabla de proceso)
  4. Mejores prácticas (enseñar corrección)

Capacidad técnica imperfecta (semántica)

Supongamos que realmente desea tener un archivo histórico: existe por una razón; lo ayuda a recordar los comandos que escribió, repetir comandos por referencia, etc. En este caso, desea eliminar las contraseñas que ingresó por error. ¿Cómo haces eso?

Puede tener una lista de contraseñas de texto sin formato que escanear dentro de los archivos de historial de bash ... pero luego tiene una lista de contraseñas de texto simple en su sistema.

Puedes buscar comandos como 'sudo' y 'su' y tratar de eliminar cosas después de ellos ... pero lo que sucederá es que alguien escriba 'sudp' por error, luego escribe su contraseña en el y su filtro no lo notará debido al error tipográfico que condujo a la exposición de la contraseña.

En resumen, la computadora no es lo suficientemente inteligente como para filtrar entradas de contraseña inapropiadas; eso es un problema de significado semántico.

Capacidad técnica imperfecta (registro centralizado)

En bash 4.1, introdujeron la capacidad de copie los registros del historial de todos en syslog . Esta era una versión legítima de la funcionalidad que las personas habían estado pirateando, parcheando y haciendo scripts en bash (y otros shells) durante años . Si alguien más administra su máquina, por ejemplo, el grupo de TI en el trabajo, es posible que no tenga control sobre si sus líneas de comando se están registrando, de manera silenciosa, sin que usted lo sepa.

No es solo bash. El daemon auditd en Linux se puede configurar para registrar comandos y argumentos:

# grep oops /var/log/audit/auditd.log
type=EXECVE msg=audit(1443795447.953:2387443): argc=6 a0="sudo" a1="oops" a2="i" a3="typed" a4="my" a5="password"
#

Esa es una configuración de nivel de sistema, que opera a través del kernel, que no tiene ninguna relación con la shell que uses y sin importar la configuración de historial que hayas elegido.

Vectores alternativos (tabla de proceso)

Cualquier cosa que escriba en la línea de comando puede aparecer en la tabla de procesos, por lo que las herramientas que usan contraseñas requieren que se ingresen de manera interactiva. Si lo arruinas (como en el ejemplo de sudo anterior) y los ingresas como argumentos, están ahí para que alguien los saque de la lista de procesos, y no es tan difícil para alguien escribir un cosechador que atrapa líneas de comandos fuera de la lista. tabla de proceso.

Mejores prácticas (enseñar con exactitud)

Cada una de estas objeciones tiene advertencias ... "Si no quiero seguir usando un archivo de historial", "Si mi administrador de sistemas está desactivado", "Si nadie está observando la tabla de procesos con cuidado" .. ... Pero mi definición de "mejores prácticas" es "cosas que haces porque no puedes confiar en que otras cosas vayan como te gustaría". Por lo tanto, las mejores prácticas son simplemente asumir que cualquier contraseña mal escrita donde no debería haber estado comprometida, cambiarla de inmediato y seguir adelante con su vida.

Cualquier "solución" que pueda implementar es parcial y propensa a fallas fuera de la esfera de detección del usuario. Preferiría no dar a las personas la falsa impresión de que están más seguros que ellos.

Me doy cuenta de que entrenar a la gente para hacerlo es difícil. Demonios, entrenar a la gente para hacer algo es difícil, y la seguridad es doble. Pero es la respuesta correcta.

    
respondido por el gowenfawr 02.10.2015 - 16:24
fuente
2

Bueno, el método que describiste (resquebrajando los hashes en el archivo de la sombra) no se puede prevenir, ya que Linux no lo hizo o no fue diseñado para evitar que los atacantes tengan acceso físico a la máquina.

Si desea eliminar el historial de bash (al cerrar sesión), coloque lo siguiente en los archivos ~ / .bashrc y ~ / bash_logout :

cat /dev/null > ~/.bash_history && history -c && exit
    
respondido por el Sebi 02.10.2015 - 15:28
fuente
0

Edite el archivo .bashrc :

nano ~/.bashrc

Cambie los valores de estos dos parámetros a:

HISTSIZE=0
HISTFILESIZE=0
  

HISTSIZE es el número de líneas o comandos que se almacenan en la memoria   en una lista de historial mientras tu sesión de bash está en curso.

     

HISTFILESIZE es el número de líneas o comandos que (a) están permitidos   en el archivo histórico en el momento de inicio de una sesión, y (b) se almacenan   en el archivo histórico al final de su sesión de bash para usar en el futuro   sesiones.

    
respondido por el user45139 02.10.2015 - 15:39
fuente

Lea otras preguntas en las etiquetas