User Tools

Site Tools


informatica:linux:auditd

auditd

audit usuario edita archivo permisos grupo

Escenario: queremos saber el usuario de sistema que ha leido/escrito un archivo

1. Instalar:

sudo aptitude update; sudo aptitude install auditd

2. Monitorizar el archivo, en este caso '/tmp/xxx':

sudo auditctl -w /tmp/xxx -p war -k snmp_tmp_xxx

3. Monitorizar en vivo:

sudo su
tail -F /var/log/audit/audit.log

Resultado:

type=CWD msg=audit(1352110649.171:34):  cwd="/"
type=PATH msg=audit(1352110649.171:34): item=0 name="/tmp/xxx" inode=9278 dev=fd:00 mode=0100600 ouid=0 ogid=108 rdev=00:00
type=SYSCALL msg=audit(1352110649.175:35): arch=c000003e syscall=2 success=no exit=-13 a0=7f18e174f380 a1=0 a2=1b6 a3=0 items=1 ppid=1 pid=2774 auid=4294967295 uid=106 gid=108 euid=106 suid=106 fsuid=106 egid=108 sgid=108 fsgid=108 tty=(none) ses=4294967295 comm="snmpd" exe="/usr/sbin/snmpd" key="snmp_tmp_xxx"

En este ejemplo vemos usuario y grupo:

Usuario ('uid') 106
Grupo ('gid') 108

4. Vemos de quien se trata:

cat /etc/passwd | grep "x:106"
snmp:x:106:108::/var/lib/snmp:/bin/false

cat /etc/group | grep "x:108"
snmp:x:108:snmp

CONCLUSION Es importante determinar el grupo con el que se esta ejecutando un servicio, y no solo el usuario (lo que obtenemos con un 'ps aux'). No es suficiente con que el usuario con el que se ejecuta el demonio pertenezca al grupo que le da permisos de lectura, sino que ademas el demonio tiene que ejecutarse con ese grupo.

informatica/linux/auditd.txt · Last modified: 2015/04/13 20:19 by 127.0.0.1