Herramienta para capturar información confidencial de las líneas de comando [cerrado]

En los sistemas Linux, toda esta información está disponible a través de la interfaz proc, y como tal es bastante fácil de escribir. Como ejemplo de trabajo (proveniente de un sistema RHEL6) veamos el proceso rsyslog.

[user@node1 ~]$ ps aux | grep rsyslog
root      1105  0.0  0.0 248680  1460 ?        Sl   May29   0:42 /sbin/rsyslogd -i /var/run/syslogd.pid -c 4
user     26440  0.0  0.0 103236   824 pts/4    S+   11:38   0:00 grep rsyslog

Bien, entonces el pid es 1105, bastante fácil. Dado que el sistema proc almacena procesos en el formato de /proc/<pid> , veamos qué datos se presentan.

[user@node1 ~]$ ls -l /proc/1105
ls: cannot read symbolic link /proc/1105/cwd: Permission denied
ls: cannot read symbolic link /proc/1105/root: Permission denied
ls: cannot read symbolic link /proc/1105/exe: Permission denied
total 0
dr-xr-xr-x. 2 root root 0 Jun 15 11:39 attr
-rw-r--r--. 1 root root 0 Jun 15 11:39 autogroup
-r--------. 1 root root 0 Jun 15 11:39 auxv
-r--r--r--. 1 root root 0 Jun 15 11:39 cgroup
--w-------. 1 root root 0 Jun 15 11:39 clear_refs
-r--r--r--. 1 root root 0 Jun 15 11:35 cmdline
-rw-r--r--. 1 root root 0 Jun 15 11:39 coredump_filter
-r--r--r--. 1 root root 0 Jun 15 11:39 cpuset
lrwxrwxrwx. 1 root root 0 Jun 15 11:39 cwd
-r--------. 1 root root 0 Jun 15 11:39 environ
lrwxrwxrwx. 1 root root 0 Jun 15 11:39 exe
dr-x------. 2 root root 0 Jun 15 11:39 fd
dr-x------. 2 root root 0 Jun 15 11:39 fdinfo
-r--------. 1 root root 0 Jun 15 11:39 io
-rw-------. 1 root root 0 Jun 15 11:39 limits
-rw-r--r--. 1 root root 0 Jun 15 11:39 loginuid
-r--r--r--. 1 root root 0 Jun 15 11:39 maps
-rw-------. 1 root root 0 Jun 15 11:39 mem
-r--r--r--. 1 root root 0 Jun 15 11:39 mountinfo
-r--r--r--. 1 root root 0 Jun 15 11:39 mounts
-r--------. 1 root root 0 Jun 15 11:39 mountstats
dr-xr-xr-x. 6 root root 0 Jun 15 11:39 net
-r--r--r--. 1 root root 0 Jun 15 11:39 numa_maps
-rw-r--r--. 1 root root 0 Jun 15 11:39 oom_adj
-r--r--r--. 1 root root 0 Jun 15 11:39 oom_score
-rw-r--r--. 1 root root 0 Jun 15 11:39 oom_score_adj
-r--r--r--. 1 root root 0 Jun 15 11:39 pagemap
-r--r--r--. 1 root root 0 Jun 15 11:39 personality
lrwxrwxrwx. 1 root root 0 Jun 15 11:39 root
-rw-r--r--. 1 root root 0 Jun 15 11:39 sched
-r--r--r--. 1 root root 0 Jun 15 11:39 schedstat
-r--r--r--. 1 root root 0 Jun 15 11:39 sessionid
-r--r--r--. 1 root root 0 Jun 15 11:39 smaps
-r--r--r--. 1 root root 0 Jun 15 11:39 stack
-r--r--r--. 1 root root 0 Jun 15 11:35 stat
-r--r--r--. 1 root root 0 Jun 15 11:39 statm
-r--r--r--. 1 root root 0 Jun 15 11:35 status
-r--r--r--. 1 root root 0 Jun 15 11:39 syscall
dr-xr-xr-x. 6 root root 0 Jun 15 11:39 task
-r--r--r--. 1 root root 0 Jun 15 11:39 wchan

Estoy ejecutando esto como un usuario normal, por lo que parte de la información no está disponible. No es gran cosa, porque lo que realmente queremos es que haya un archivo llamado cmdline .

[user@node1 ~]$ cat /proc/1105/cmdline
/sbin/rsyslogd-i/var/run/syslogd.pid-c4[user@node1 ~]$

Los argumentos parecen estar todos juntos. De hecho, están separados por caracteres nulos. Obtendrá una visualización más amigable al convertir los caracteres nulos en nuevas líneas (pero tenga en cuenta que esto eliminará la distinción entre separaciones entre argumentos y nuevas líneas reales en un argumento):

[user@node1 ~]$ tr '
for p in /proc/[0-9]*/cmdline; do
  …
done
' '\n' </proc/1105/cmdline; echo
/sbin/rsyslogd
-i
/var/run/syslogd.pid
-c
4
[user@node1 ~]$

Por supuesto, esto no realmente nos da nada más allá de lo que obtuvimos de la salida ps. Sin embargo, dependiendo de lo que desee, puede ser más fácil de scripts. Si quisiéramos trabajar exclusivamente en bash, por ejemplo, podría usar esta estructura para iterar sobre todos los procesos:

[user@node2 ~]$ ps aux | grep mysql
user     7974  0.0  0.1 157116  2732 pts/0    S+   11:47   0:00 mysql -u root -px xxxxxxxxxx database
[user@node2 ~]$ cat /proc/7974/cmdline
mysql-uroot-pxxxxxxxxxxxdashboard[user@node2 ~]$

Luego, usa eso como una lista de archivos para procesar.

Si estás en Perl, existe un módulo llamado Proc :: ProcessTable que consulta el Proc sistema y expone la misma información que un objeto.

Todo lo que se dice, si desea buscar contraseñas en la línea de comandos, a veces puede sentirse decepcionado. Algunas aplicaciones de alguna manera funcionan para enmascararlo, por ejemplo, MySQL:

[user@node1 ~]$ ps aux | grep rsyslog
root      1105  0.0  0.0 248680  1460 ?        Sl   May29   0:42 /sbin/rsyslogd -i /var/run/syslogd.pid -c 4
user     26440  0.0  0.0 103236   824 pts/4    S+   11:38   0:00 grep rsyslog

Este es el tipo de tarea que los humanos hacen mucho mejor que las máquinas. Y con eso me refiero al reconocimiento de patrones. Puede intentar escribir un script que continuamente llame a ps (recortar el comando y luego ordenar los duplicados con sort -u) y luego revisar la salida más tarde. Sin embargo, tenga en cuenta que esto es ahora la persistencia de los datos que ya ha identificado como potencialmente sensibles. Asegúrese de que sus permisos sean sanos o que estén almacenados en forma cifrada. Revise periódicamente hasta que se sienta cómodo con sus usuarios y luego elimine el script para reducir los costos de mantenimiento.

Volviendo a su hipotética herramienta, la cantidad de falsos positivos que generaría sería asombrosa a menos que ya se conozcan las contraseñas. En ese caso, dado que ahora está compartiendo información confidencial entre usuarios, está aumentando el riesgo de no disminuirla.

Un método para reducir esos falsos positivos es hacer que el script sea lo más simple posible. Por ejemplo, solo restrinja para comandos comunes con argumentos consistentes que requieren que las contraseñas se ingresen en la línea de comandos. Incluso entonces, los scripts de shell pueden ser tan complejos que obtendrás un montón de falsos negativos y positivos. Lo mejor que puedes hacer son expresiones regulares y eso será una pesadilla para implementar. Esto significa que el valor de una herramienta de este tipo disminuye, especialmente cuando se considera el costo de mantenimiento. Creo que probablemente hay cosas mejores que un administrador podría estar haciendo con su tiempo.

Además, este es un enfoque reaccionario a la seguridad y no preventivo. ¿Es posible que haya una forma en su sistema para evitar que los usuarios vean la información del proceso de otros usuarios? Probablemente esto sea muy poco probable, pero puede ser la mejor pregunta.

También tenga en cuenta que esta información también termina ingresando al archivo histórico del usuario, esencialmente persistiendo en la divulgación. La verificación de los permisos / propiedad de esos archivos puede ser una tarea útil. Lo mismo con los registros que pueden contener contraseñas u otra información confidencial. También algunas aplicaciones como mysql pueden registrar el historial de comandos.

La automatización de tales procesos es realmente una tarea trivial, una vez que sabes lo que quieres lograr.

Suponiendo que sus sistemas son cuadros de Linux, los scripts de bash / python / perl se pueden escribir fácilmente para ejecutar comandos y analizar los resultados. Dichos scripts también podrían comparar las diferencias entre los resultados del día a día. Los scripts podrían configurarse para ejecutarse regularmente mediante el uso de trabajos cron.

La utilidad de los resultados dependería de la persona que lo supervise / interprete.

Probablemente se podría hacer lo mismo para los cuadros de Windows usando scripts de proceso por lotes (no muy seguro).

Hum, sabes como pienso acerca de esta pregunta. No estoy tan seguro de lo trivial que sería esta tarea. Desea información sobre cada imagen, probablemente también información sobre instancias de corta duración.

Entonces, si desea toda esta información, podría estar hablando sobre el uso de la plataforma de filtrado de Windows y algo así como la recopilación de datos para Posix para que pueda obtener toda la notificación de E / S de eventos.

Luego necesita una forma de conservar estos datos y transportarlos a un repositorio central donde pueda agregar estos datos para el consumo. Esto sería una gran cantidad de datos, se requeriría una gran cantidad de caballos de fuerza para hacer el análisis en vivo. Probablemente tendría que depender de un proceso / solución como un ETL o un Mapa / Reducir antes de que pueda darle sentido. Por supuesto, podría simplemente enviarlo a un servidor de syslog e ir a través de él manualmente. Creo que eso lo abrumaría rápidamente.

Supongamos que en su lugar podría realizar el procesamiento y filtrado localmente en la máquina y exportar solo a un servidor syslog / agregaciones positivas del servidor.

No conozco una herramienta que haga esto específicamente, tal vez si tiene un producto AV / HIPS instalado que le permita escribir una regla personalizada, podría acercarse. Una aplicación personalizada desde cero sería un proyecto saludable para un solo desarrollador, probablemente uno divertido.

Mirar regularmente la lista de procesos no es muy confiable. Es muy probable que cualquier método de muestreo omita procesos de corta duración que capturaría un atacante más específico que no teme utilizar temporalmente muchos recursos de CPU.

Utilice los mecanismos de registro existentes de su sistema operativo. Incluso si va a tomar muestras porque el registro sistemático es demasiado costoso, tome muestras de (digamos) un minuto completo de vez en cuando (preferiblemente en momentos en que suceden cosas).

Por ejemplo, en Linux, use el subsistema de auditoría ( auditd ) para registrar todas las llamadas a la llamada al sistema execve . Consulte ¿Registro de comandos de Linux? para obtener una descripción general y ¿Ejemplo simple de configuración auditd? para obtener instrucciones. Tenga en cuenta que en Linux, los argumentos de un proceso son legibles públicamente (excepto en algunas configuraciones de seguridad restrictivas con SELinux o entornos de alta seguridad similares), pero las variables de entorno solo pueden ser vistas por otros procesos ejecutados por el mismo usuario. Para tener una idea de qué es público y qué no lo es, ejecute ls /proc/1 .