Cuando desee otorgar acceso administrativo a algunos de sus usuarios mientras controla y verifica lo que hacen en sus sistemas, use sudo . Sin embargo, incluso con sudo , hay bastantes problemas que no se ven, solo piense en otorgar acceso de shell. sudo reciente lanza funciones adicionales que le permiten ver estos problemas e incluso controlarlos. Por ejemplo, puede activar mensajes de registro más detallados y fáciles de procesar y registrar cada comando ejecutado en una sesión de shell.
Algunas de estas características son completamente nuevas. Algunos de ellos se basan en características introducidas en la versión 1.9.0 o incluso anteriores. Por ejemplo, sudo podía grabar todo lo que sucedía en un terminal, incluso en la versión 1.8. Sin embargo, el sistema almacenaba estas grabaciones localmente y eran fáciles de eliminar, especialmente aquellas en las que las grabaciones eran más útiles:las sesiones de Shell. La versión 1.9.0 agregó una recopilación de grabaciones de sesión central, por lo que el usuario local no puede eliminar las grabaciones, y las versiones recientes agregaron retransmisiones, lo que hace que la recopilación sea aún más sólida.
Si solo conoce los conceptos básicos de sudo o usé solo la versión 1.8 anteriormente, recomiendo leer mi artículo anterior.
1. Registro con formato JSON
La primera característica nueva que quiero presentar es el registro en formato JSON. Soy un fanático de los registros (comencé a trabajar en syslog-ng hace doce años), y esta función es la primera que se presenta desde mi artículo de Opensource.com. Cuando está habilitado, sudo registra mucha más información y lo hace de una manera más fácil de analizar.
syslog tradicional mensajes de sudo son breves y contienen sólo la cantidad mínima de información necesaria. Esto se debe a las restricciones del antiguo syslog implementaciones:Los mensajes de más de 1k de tamaño fueron descartados o truncados:
Jan 28 13:56:27 localhost.localdomain sudo[10419]: czanik : TTY=pts/0 ; PWD=/home/czanik ; USER=root ; COMMAND=/bin/bash
syslog más reciente Las implementaciones pueden manejar tamaños de mensaje mucho más grandes. syslog-ng acepta mensajes de registro de hasta 64k de tamaño de forma predeterminada (pero, por supuesto, puede ser más pequeño o más grande, según la configuración actual).
El mismo evento contiene mucha más información si se registra en formato JSON. Más no significa más difícil de manejar:los mensajes con formato JSON son más fáciles de analizar por muchas aplicaciones de software de administración de registros. Aquí hay un ejemplo:
Jan 28 13:58:20 localhost.localdomain sudo[10518]: @cee:{"sudo":{"accept":{"uuid":"616bc9efcf-b239-469d-60ee-deb5af8ce6","server_time":{"seconds":1643374700,"nanoseconds":222446715,"iso8601":"20220128125820Z","localtime":"Jan 28 13:58:20"},"submit_time":{"seconds":1643374700,"nanoseconds":209935349,"iso8601":"20220128125820Z","localtime":"Jan 28 13:58:20"},"submituser":"czanik","command":"/bin/bash","runuser":"root","runcwd":"/home/czanik","ttyname":"/dev/pts/0","submithost":"localhost.localdomain","submitcwd":"/home/czanik","runuid":0,"columns":118,"lines":60,"runargv":["/bin/bash"],"runenv":["LANG=en_US.UTF-8","HOSTNAME=localhost.localdomain","SHELL=/bin/bash","TERM=xterm-256color","PATH=/home/czanik/.local/bin:/home/czanik/bin:/usr/local/bin:/usr/bin:/usr/local/sbin:/usr/sbin","MAIL=/var/mail/root","LOGNAME=root","USER=root","HOME=/root","SUDO_COMMAND=/bin/bash","SUDO_USER=czanik","SUDO_UID=1000","SUDO_GID=1000"]}}}
Puede habilitar los mensajes de registro con formato JSON en sudoers archivo:
Defaults log_format=json
Puede obtener más información sobre cómo trabajar con mensajes de registro con formato JSON en sudo de mi blog syslog-ng.
2. Recopilación de registros de forma centralizada mediante sudo_logsrvd
Otra característica relacionada con el registro en 1.9.4 es recopilar todos los sudo registrar mensajes (incluyendo fallas) usando sudo_logsrvd . Anteriormente, el sistema solo registraba sesiones exitosas cuando sudo_logsrvd en realidad hizo una grabación. El registro todavía se realiza a través de syslog por defecto al final.
¿Porque es esto importante? En primer lugar, puede recopilar cualquier cosa relacionada con sudo en un solo lugar:Tanto las grabaciones de la sesión como todos los mensajes de registro correspondientes. En segundo lugar, también puede garantizar el registro adecuado de todos los sudo -eventos relacionados, como sudo puede negarse a ejecutar comandos si sudo_logsrvd es inaccesible.
Puede habilitar el registro en sudo_logsrvd con la siguiente configuración en sudoers archivo (por supuesto, reemplace la dirección IP):
Defaults log_servers=172.16.167.150
Si desea mensajes de registro con formato JSON, necesita la siguiente configuración en el [eventlog] sección de sudo_logsrvd configuración:
log_format = json
De lo contrario, sudo_logsrvd usa el tradicional sudo formato de registro con una simple modificación:También incluye información sobre el host de donde proviene el registro:
Nov 18 12:40:16 centos8splunk.localdomain sudo[21028]: czanik : 3 incorrect password attempts ; HOST=centos7sudo.localdomain ; TTY=pts/0 ; PWD=/home/czanik ; USER=root ; COMMAND=/bin/bash
Nov 18 12:40:23 centos8splunk.localdomain sudo[21028]: czanik : HOST=centos7sudo.localdomain ; TTY=pts/0 ; PWD=/home/czanik ; USER=root ; TSID=00000A ; COMMAND=/bin/bash
Nov 18 12:40:30 centos8splunk.localdomain sudo[21028]: czanik : command rejected by I/O plugin ; HOST=centos7sudo.localdomain ; TTY=pts/0 ; PWD=/home/czanik ; USER=root ; COMMAND=/bin/bash
Más sobre administradores de sistemas
- Habilitar el blog de administrador del sistema
- La empresa automatizada:una guía para administrar TI con automatización
- Libro electrónico:Automatización de Ansible para administradores de sistemas
- Historias del campo:una guía del administrador de sistemas para la automatización de TI
- eBook:Una guía de Kubernetes para SRE y administradores de sistemas
- Últimos artículos de administrador de sistemas
3. Relés
Cuando introdujeron originalmente sudo_logsrvd (versión 1.9.0) para la recopilación de grabaciones de sesiones centrales, los clientes solo podían enviar grabaciones directamente. La versión 1.9.7 introdujo el concepto de relés. Con relevos, en lugar de enviar grabaciones directamente, puede enviar grabaciones a múltiples niveles de hosts intermedios, que estructuran su red.
¿Porque es esto importante? En primer lugar, los repetidores permiten recopilar grabaciones de sesiones incluso si el host central no está disponible debido a problemas de red o mantenimiento. Por defecto, sudo se niega a ejecutarse cuando no puede enviar grabaciones, por lo que los relés pueden garantizar que pueda usar sudo todo el día.
En segundo lugar, también le permite tener controles más estrictos en su red:en lugar de abrir el firewall para todos los hosts al sudo_logsrvd central , solo necesita permitir el paso de su retransmisión.
Finalmente, le permite recopilar grabaciones de sesiones de redes sin acceso directo a Internet, como redes privadas de AWS, donde puede instalar sudo_logsrvd en modo de retransmisión en el host de la puerta de enlace.
Cuando usa relés, configurando el sudo clientes y el sudo_logsrvd central sigue siendo el mismo. En el host de retransmisión, agregue la siguiente línea a [relay] sección de sudo_logsrvd.conf :
relay_host = 172.16.167.161Si se sabe que la conexión de red hacia el servidor central es problemática, puede configurar el relé para almacenar grabaciones antes de reenviarlas:
store_first = true4. Registro de subcomandos
¿Alguna vez quiso saber qué sucede dentro de una sesión de shell iniciada a través de sudo? ? Sí, las grabaciones de sesiones están ahí, pero mirar horas de grabaciones solo para ver un par de comandos ejecutados es aburrido y una gran pérdida de tiempo. Afortunadamente, la versión 1.9.8 introdujo subcomandos de registro. Ahora es suficiente revisar sus mensajes de registro con regularidad y ver las grabaciones solo cuando ocurre algo sospechoso.
Ni siquiera necesita una regla para permitir el acceso de shell para tener acceso de shell, solo acceda a un editor. La mayoría de los editores pueden ejecutar comandos externos. Mi editor favorito es JOE, y esto es lo que puedes ver cuando lo inicio a través de sudo :
Aug 30 13:03:00 czplaptop sudo[10150]: czanik : TTY=pts/1 ; PWD=/home/czanik ; USER=root ; COMMAND=/usr/bin/joeNada interesante, solo un editor, incluso si genero un shell y elimino algunos archivos y particiones de ese shell. Ahora veamos qué sucede cuando habilita los subcomandos de registro:
Aug 30 13:13:14 czanik : TTY=pts/1 ; PWD=/home/czanik ; USER=root ; COMMAND=/usr/bin/joe
Aug 30 13:13:37 czanik : TTY=pts/1 ; PWD=/home/czanik ; USER=root ; COMMAND=/bin/sh -c /bin/bash
Aug 30 13:13:37 czanik : TTY=pts/1 ; PWD=/home/czanik ; USER=root ; COMMAND=/bin/bash
Aug 30 13:13:37 czanik : TTY=pts/1 ; PWD=/home/czanik ; USER=root ; COMMAND=/usr/bin/readlink /proc/10889/exe
[...]
Aug 30 13:13:37 czanik : TTY=pts/1 ; PWD=/home/czanik ; USER=root ; COMMAND=/usr/bin/sed -r s@/*:|([^\\]):@\1\n@g;H;x;s@/\n@\n@
Aug 30 13:13:37 czanik : TTY=pts/1 ; PWD=/home/czanik ; USER=root ; COMMAND=/usr/bin/tty
Aug 30 13:13:42 czanik : TTY=pts/1 ; PWD=/home/czanik ; USER=root ; COMMAND=/usr/bin/id
Aug 30 13:13:56 czanik : TTY=pts/1 ; PWD=/home/czanik ; USER=root ; COMMAND=/usr/bin/ls -A -N --color=none -T 0 /usr/share/syslog-ng/include/scl/
Omití docenas de líneas para ahorrar espacio, pero aún puede ver que comencé un shell y los comandos ejecutados por bash_profile también están disponibles en los registros.
Puede habilitar los subcomandos de registro en sudoers archivo usando la siguiente configuración:
Defaults log_subcmds
En el tradicional sudo logs, se puede ver desde el sudo ID de proceso que estos registros son del mismo sudo sesión. Si activa el registro en formato JSON, como se muestra anteriormente, sudo registra mucha más información en los registros, lo que facilita su análisis.
5. Interceptar subcomandos
Los subcomandos de registro eliminan la mayoría de las áreas problemáticas ocultas de sudo , pero hay situaciones en las que no solo desea observar lo que sucede, sino también controlar el flujo de eventos. Por ejemplo, debe otorgar acceso de shell a un usuario pero aún desea evitar que ejecute un comando específico. La interceptación es ideal en tales casos. Existen, por supuesto, algunas limitaciones, como que no puede limitar los comandos integrados de los shells.
Digamos el who El mando es peligroso. Puede habilitar la interceptación en dos pasos:el primero lo habilita, el segundo lo configura. En este caso, mi usuario no puede ejecutar who :
Defaults intercept
czanik ALL = (ALL) ALL, !/usr/bin/who
Esto es lo que sucede cuando inicio una sesión de shell raíz a través de sudo e intente ejecutar who :
$ sudo -s
# who
Sorry, user czanik is not allowed to execute '/usr/bin/who' as root on czplaptop.
bash: /usr/bin/who: Permission denied
Puede deshabilitar fácilmente la ejecución de shells por completo:
Defaults intercept
Cmnd_Alias SHELLS=/usr/bin/bash, /usr/bin/sh, /usr/bin/csh
czanik ALL = (ALL) ALL, !SHELLS
Sin embargo, también significa que no puede iniciar sesiones de shell a través de sudo . No solo eso, sino que tampoco puede ejecutar comandos externos desde editores. Esto es lo que sucede cuando trato de iniciar el ls comando desde dentro de vi :
$ sudo vi /etc/issue
Sorry, user czanik is not allowed to execute '/bin/bash -c /bin/ls' as root on czplaptop.
Cannot execute shell /bin/bash
Press ENTER or type command to continue
¿Qué sigue?
Espero que la lectura de mi artículo te haga querer probar estas nuevas funciones por ti mismo. Puede instalar el último sudo en muchas distribuciones de Linux y variantes de UNIX desde su administrador de paquetes, o use un instalador binario disponible en el sitio web de Sudo.
Este artículo le proporciona solo una descripción general de las nuevas posibilidades. Si desea obtener más información sobre estas funciones, visite el sitio web, que alberga páginas de manuales, y también el blog de Sudo.