¿Ejemplo simple de configuración auditd?

45

Auditd se recomendó en una respuesta a ¿registro de comandos de Linux?

La instalación predeterminada en Ubuntu parece apenas registrar algo. Hay varios ejemplos que vienen con él (capp.rules, nispom.rules, stig.rules) pero no está claro cuál sería el impacto en el rendimiento de cada uno de ellos, ni qué tipo de entorno o supuestos sería el más adecuado para cada uno.

¿Cuál sería el mejor punto de partida para implementar auditd en un servidor web? Esto incluiría un archivo audit.rules, la configuración para permitir el envío del flujo de registro de auditoría a una máquina remota en tiempo real y la herramienta más sencilla para ver lo que se ha registrado.

A continuación, ¿qué tal una máquina de escritorio típica?

Actualización : dannysauer señala que por seguridad es importante comenzar con el objetivo, y estoy de acuerdo. Pero mi intención principal es desencadenar algunas explicaciones más útiles del uso de esta herramienta y ver un ejemplo práctico de ella en acción, junto con las implicaciones de rendimiento y almacenamiento, etc. Si eso ya existe y yo lo perdí, por favor señálelo. Si no, sugiero que se cree un ejemplo para uno de los escenarios más comunes (por ejemplo, un servidor web simple, ejecutando su pila de elección), donde el objetivo podría ser preservar la información en caso de un robo para ayudar rastrear hacia atrás para averiguar dónde comenzó la penetración. Si hay un objetivo más adecuado o alcanzable para su uso en, por ejemplo, una pequeña empresa sin un personal de TI importante, que también ayudaría.

    
pregunta nealmcb 18.06.2011 - 19:26
fuente

3 respuestas

38

Auditd es una herramienta de monitoreo extraordinariamente poderosa. Como cualquier persona que lo haya mirado puede dar fe, usabilidad. Es la principal debilidad. Configurar algo así como auditd requiere una gran cantidad de reflexión detallada sobre exactamente qué es lo que necesita auditoría en el sistema específico en cuestión. En la pregunta te decidiste por un servidor web. Como nuestro sistema de ejemplo, lo cual es bueno ya que es específico.

En aras del argumento, supongamos que existe una división formal entre los servidores web test / dev y la producción servidores web donde los desarrolladores web realizan todo su trabajo en los sistemas de prueba / desarrollo y cambios en la producción El entorno se realiza en una implementación controlada.

Entonces, al hacer esas suposiciones bastante grandes y al concentrarnos en el sistema de producción, podemos ponernos a trabajar. Mirando la recomendación de auditd en el punto de referencia CIS para RHEL5 podemos comenzar a desarrollar el siguiente conjunto de reglas sugerido:

-a exit,always -S unlink -S rmdir
-a exit,always -S stime.*
-a exit,always -S setrlimit.*
-w /etc/group -p wa 
-w /etc/passwd -p wa 
-w /etc/shadow -p wa 
-w /etc/sudoers -p wa
-b 1024
-e 2

Esto hará que los registros se escriban cada vez que salgan las llamadas al sistema rmdir, desvincular, stime o setrlimit. Esto debería Háganos saber si alguien intenta eliminar archivos o jigger con los tiempos. También configuramos relojes de archivos específicos en el Archivos que definen grupos, usuarios, contraseñas y acceso sudo. En lugar de mirar las llamadas del sistema para cada una de ellas el registro de auditoría se escribirá cada vez que uno de esos archivos sea:

  1. abierto con los modos O_WRONLY o O_RDWR
  2. un atributo ha cambiado

Ya que asumimos que estamos hablando de un servidor web de producción, recomendaría agregar la línea:

-w /var/www -p wa

Esto observará recursivamente todos los archivos bajo el árbol de directorios /var/www .

Ahora podemos ver el motivo de la suposición de "entorno controlado" que se hizo anteriormente. Entre monitorear todos los archivos en La raíz web, así como todos los eventos de desvinculación o rmdir, podrían ser prohibitivamente ruidosos en un entorno de desarrollo. Si podemos anticipar cambios en el sistema de archivos, como durante las ventanas de mantenimiento o los eventos de implementación, podemos filtrar de manera más razonable este ruido.

Combinando todo esto en un solo archivo coherente, queremos que se vea como /etc/audit/audit.rules

# This file contains the auditctl rules that are loaded
# whenever the audit daemon is started via the initscripts.
# The rules are simply the parameters that would be passed
# to auditctl.

# First rule - delete all
-D

# Increase the buffers to survive stress events.
# Make this bigger for busy systems
-b 1024

-a exit,always -S unlink -S rmdir
-a exit,always -S stime.*
-a exit,always -S setrlimit.*
-w /var/www -p wa
-w /etc/group -p wa
-w /etc/passwd -p wa
-w /etc/shadow -p wa
-w /etc/sudoers -p wa

# Disable adding any additional rules - note that adding *new* rules will require a reboot
-e 2
    
respondido por el Scott Pack 12.07.2011 - 23:10
fuente
13

Actualización: este artículo es una buena explicación de las reglas de auditd y proporciona ejemplos para cada evento que desee registrar:

Echa un vistazo al informe de errores aquí:

enlace

Proporcionan un archivo de ejemplo muy largo que contiene muchos cambios importantes que podrían realizarse en un sistema. Copiado a continuación para mayor comodidad (con ligeras modificaciones):

## Remove any existing rules
-D

## Buffer Size
## Feel free to increase this if the machine panic's
-b 8192

## Failure Mode
## Possible values are 0 (silent), 1 (printk, print a failure message),
## and 2 (panic, halt the system).
-f 1

## Audit the audit logs.
## successful and unsuccessful attempts to read information from the
## audit records; all modifications to the audit trail
-w /var/log/audit/ -k auditlog

## Auditd configuration
## modifications to audit configuration that occur while the audit
## collection functions are operating.
-w /etc/audit/ -p wa -k auditconfig
-w /etc/libaudit.conf -p wa -k auditconfig
-w /etc/audisp/ -p wa -k audispconfig

## Monitor for use of audit management tools
-w /sbin/auditctl -p x -k audittools
-w /sbin/auditd -p x -k audittools

## special files
-a exit,always -F arch=b32 -S mknod -S mknodat -k specialfiles
-a exit,always -F arch=b64 -S mknod -S mknodat -k specialfiles

## Mount operations
-a exit,always -F arch=b32 -S mount -S umount -S umount2 -k mount
-a exit,always -F arch=b64 -S mount -S umount2 -k mount

## changes to the time
##
-a exit,always -F arch=b32 -S adjtimex -S settimeofday -S stime -S clock_settime -k time
-a exit,always -F arch=b64 -S adjtimex -S settimeofday -S clock_settime -k time

## Use stunnel
-w /usr/sbin/stunnel -p x -k stunnel

## cron configuration & scheduled jobs
-w /etc/cron.allow -p wa -k cron
-w /etc/cron.deny -p wa -k cron
-w /etc/cron.d/ -p wa -k cron
-w /etc/cron.daily/ -p wa -k cron
-w /etc/cron.hourly/ -p wa -k cron
-w /etc/cron.monthly/ -p wa -k cron
-w /etc/cron.weekly/ -p wa -k cron
-w /etc/crontab -p wa -k cron
-w /var/spool/cron/crontabs/ -k cron

## user, group, password databases
-w /etc/group -p wa -k etcgroup
-w /etc/passwd -p wa -k etcpasswd
-w /etc/gshadow -k etcgroup
-w /etc/shadow -k etcpasswd
-w /etc/security/opasswd -k opasswd

## monitor usage of passwd
-w /usr/bin/passwd -p x -k passwd_modification

#Monitor for use of tools to change group identifiers
-w /usr/sbin/groupadd -p x -k group_modification
-w /usr/sbin/groupmod -p x -k group_modification
-w /usr/sbin/addgroup -p x -k group_modification
-w /usr/sbin/useradd -p x -k user_modification
-w /usr/sbin/usermod -p x -k user_modification
-w /usr/sbin/adduser -p x -k user_modification

## login configuration and information
-w /etc/login.defs -p wa -k login
-w /etc/securetty -p wa -k login
-w /var/log/faillog -p wa -k login
-w /var/log/lastlog -p wa -k login
-w /var/log/tallylog -p wa -k login

## network configuration
-w /etc/hosts -p wa -k hosts
-w /etc/network/ -p wa -k network

## system startup scripts
-w /etc/inittab -p wa -k init
-w /etc/init.d/ -p wa -k init
-w /etc/init/ -p wa -k init

## library search paths
-w /etc/ld.so.conf -p wa -k libpath

## local time zone
-w /etc/localtime -p wa -k localtime

## kernel parameters
-w /etc/sysctl.conf -p wa -k sysctl

## modprobe configuration
-w /etc/modprobe.conf -p wa -k modprobe

## pam configuration
-w /etc/pam.d/ -p wa -k pam
-w /etc/security/limits.conf -p wa  -k pam
-w /etc/security/pam_env.conf -p wa -k pam
-w /etc/security/namespace.conf -p wa -k pam
-w /etc/security/namespace.init -p wa -k pam

## GDS specific secrets
-w /etc/puppet/ssl -p wa -k puppet_ssl

## postfix configuration
-w /etc/aliases -p wa -k mail
-w /etc/postfix/ -p wa -k mail

## ssh configuration
-w /etc/ssh/sshd_config -k sshd

## changes to hostname
-a exit,always -F arch=b32 -S sethostname -k hostname
-a exit,always -F arch=b64 -S sethostname -k hostname

## changes to issue
-w /etc/issue -p wa -k etcissue
-w /etc/issue.net -p wa -k etcissue

## this was to noisy currently.
# log all commands executed by an effective id of 0 aka root.
-a exit,always -F arch=b64 -F euid=0 -S execve -k rootcmd
-a exit,always -F arch=b32 -F euid=0 -S execve -k rootcmd

## Capture all failures to access on critical elements
-a exit,always -F arch=b64 -S open -F dir=/etc -F success=0 -k unauthedfileacess
-a exit,always -F arch=b64 -S open -F dir=/bin -F success=0 -k unauthedfileacess
-a exit,always -F arch=b64 -S open -F dir=/sbin -F success=0 -k unauthedfileacess
-a exit,always -F arch=b64 -S open -F dir=/usr/bin -F success=0 -k unauthedfileacess
-a exit,always -F arch=b64 -S open -F dir=/usr/sbin -F success=0 -k unauthedfileacess
-a exit,always -F arch=b64 -S open -F dir=/var -F success=0 -k unauthedfileacess
-a exit,always -F arch=b64 -S open -F dir=/home -F success=0 -k unauthedfileacess
-a exit,always -F arch=b64 -S open -F dir=/srv -F success=0 -k unauthedfileacess

## Monitor for use of process ID change (switching accounts) applications
-w /bin/su -p x -k priv_esc
-w /usr/bin/sudo -p x -k priv_esc
-w /etc/sudoers -p rw -k priv_esc

## Monitor usage of commands to change power state
-w /sbin/shutdown -p x -k power
-w /sbin/poweroff -p x -k power
-w /sbin/reboot -p x -k power
-w /sbin/halt -p x -k power

## Make the configuration immutable
-e 2
    
respondido por el dberm22 10.01.2014 - 20:16
fuente
11

Te estás acercando un poco a la pregunta de manera incorrecta. Debe decidir qué desea iniciar sesión y averiguar cómo iniciar sesión. Generar un montón de archivos de registro es genial y todo, pero si nunca los miras o no sabes lo que estás buscando, solo se pierde tiempo y espacio.

Al decidir qué registrar, debe identificar qué comportamiento es lo que le importa y luego averiguar cómo registrar esa actividad. Una buena manera de comenzar a hacer esto sería leer sobre AppArmor y leer detenidamente las auditctl página de manual. luego aprenda qué llamadas del sistema están disponibles aprendiendo a programar para Unix e identifique las llamadas que puedan ser de su interés. Es realmente una empresa bastante grande. Sé que esta es una respuesta un tanto simplista y no proporciona "aquí hay un script de shell que registrará todo lo que le importa en su servidor", pero la razón por la que esas respuestas no existen es que, bueno, cada situación es diferente por lo que no es posible dar una respuesta de "talla única".

En el lugar (ciertamente grande) donde trabajo, tenemos todo un equipo de personas dedicadas solo al registro del sistema, por no mencionar a los diversos equipos de administración y seguridad que contribuyen. Este no es un tema pequeño. : /

    
respondido por el dannysauer 23.06.2011 - 01:17
fuente

Lea otras preguntas en las etiquetas