Product SiteDocumentation Site

4.13. La importancia de logs y alarmas

Cómo las bitácoras y alarmas son tratadas es un problema importante en un sistema seguro. Es fácil ver que, aun cuando el sistema está perfectamente configurado y, supuestamente, 99% asegurado. Si el 1% sucede, y no hay seguridad midiendo en tales situaciones, primero, descubra esto y, segundo, las alarmas del aumento, el sistema no está en absoluto seguro.
Debian GNU/Linux provides some tools to perform log analysis, most notably swatch, [26] logcheck or log-analysis (all will need some customisation to remove unnecessary things from the report). It might also be useful, if the system is nearby, to have the system logs printed on a virtual console. This is useful since you can (from a distance) see if the system is behaving properly. Debian's /etc/syslog.conf comes with a commented default configuration; to enable it uncomment the lines and restart syslogd (/etc/init.d/syslogd restart):
  daemon,mail.*;\
        news.=crit;news.=err;news.=notice;\
        *.=debug;*.=info;\
        *.=notice;*.=warn       /dev/tty8
To colorize the logs, you could take a look at colorize, ccze or glark. There is a lot to log analysis that cannot be fully covered here, so a good information resource would be books should as http://books.google.com/books?id=UyktqN6GnWEC. In any case, even automated tools are no match for the best analysis tool: your brain.

4.13.1. Uso y personalización de logcheck

The logcheck package in Debian is divided into the three packages logcheck (the main program), logcheck-database (a database of regular expressions for the program) and logtail (prints loglines that have not yet been read). The Debian default (in /etc/cron.d/logcheck) is that logcheck is run every hour and after reboots.
Hay también un número de registros de auditorias de herramientas, en el site, como logcheck. Estas herramientas pueden ser absolutamente usables si se garantiza propiamente para alertar al administrador sobre eventos inusuales en el sistema de archivos locales. logcheck. pude ser enteramente garantizado, pude enviar mensajes desde eventos recuperados y desde los registros que son meritorios de atención. El abandono de instalación incluye perfiles para eventos ignorados y violaciones políticas para tres diferentes montajes (estación de trabajo, servidor y paranoia). Los paquetes de Debian incluyen un archivo de configuración /etc/logcheck/logcheck.conf, dirigido por el programa, que define al usuario y que también revisa sus envios. También suministra una forma de paquete que provee servicios para implementar nuevas políticas en los directorios: /etc/logcheck/hacking.d/_packagename_, /etc/logcheck/violations.d/_packagename_, /etc/logcheck/violations.ignore.d/_packagename_, /etc/logcheck/ignore.d.paranoid/_packagename_, /etc/logcheck/ignore.d.server/_packagename_, and /etc/logcheck/ignore.d.workstation/_packagename_. Sin embargo, no muchos paquetes lo hacen actualmente. Si usted tiene una política que puede ser útil para otros usuarios , por favor envielo como un pequeño reporte para los paquetes apropiados, mire mas información en /usr/share/doc/logcheck/README.Debian
The best way to configure logcheck is to edit its main configuration file /etc/logcheck/logcheck.conf after installation. Change the default user (root) to whom reports should be mailed. You should set the reportlevel in there, too. logcheck-database has three report levels of increasing verbosity: workstation, server, paranoid. "server" being the default level, paranoid is only recommended for high-security machines running as few services as possible and workstation for relatively sheltered, non-critical machines. If you wish to add new log files just add them to /etc/logcheck/logcheck.logfiles. It is tuned for default syslog install.
Once this is done you might want to check the mails that are sent, for the first few days/weeks/months. If you find you are sent messages you do not wish to receive, just add the regular expressions (see regex(7) and egrep(1)) that correspond to these messages to the /etc/logcheck/ignore.d.reportlevel/local. Try to match the whole logline. Details on howto write rules are explained in /usr/share/doc/logcheck-database/README.logcheck-database.gz. It's an ongoing tuning process; once the messages that are sent are always relevant you can consider the tuning finished. Note that if logcheck does not find anything relevant in your system it will not mail you even if it does run (so you might get a mail only once a week, if you are lucky).

4.13.2. Configurando el sitio donde las alertas son enviadas

Debian viene con una configuración de syslog estándard dentro de (etc/syslog.conf)que anota mensajes para apropiar archivos dependiendo de la facilidad del sistema. Usted debería familiarizarse con ésto, debe mirar el archivo syslog.conf o sino la documentación. Si usted pretende mantener un sistema seguro usted podrá estar precavido de a dónde se mandan los mensajes de registro de manera que no pasen inadvertidos.
Por ejemplo, enviar mensajes a la consola es una configuración interesante ya que es útil para muchos sistemas de nivel de producción. Pero para muchos sistemas también es importante añadir una nueva máquina que podría servir como servidor de registro (i.e. esto recibe los registros desde todos los otros sistemas).
El correo de Root también deberia ser considerado, muchos controles de seguridad como snort) envían alarmas al buzón de Root. Este buzón normalmente apunta al primer usuario que se creó en el sistema (compruebe /etc/aliases). Tenga cuidado de enviar correo de root a cualquier lugar donde pueda ser leído (ya sea local ó remotamente)
Hay otros informes y alianzas en su sistema. En un pequeño sistema, ésto probablemente lo más simple para asegurarse de que todas las alianzas apunten hacia la cuenta de root, y que el correo para root este dispuesto para el sistema de buzón personal del administrador.
ARREGLAME: it would be interesting to tell how a Debian system can send/receive SNMP traps related to security problems (jfs). Check: snmptraglogd, snmp and snmpd.

4.13.3. Usar un servidor de registro

A loghost is a host which collects syslog data remotely over the network. If one of your machines is cracked, the intruder is not able to cover the tracks, unless hacking the loghost as well. So, the loghost should be especially secure. Making a machine a loghost is simple. Just start the syslogd with
syslogd -r
and a new loghost is born. In order to do this permanently in Debian, edit /etc/default/syslogd and change the line
SYSLOGD=""
a
SYSLOGD="-r"
Luego, configure las otras máquinas al enviar los datos al servidor de registro. Agrege una entrada como la siguiente /etc/syslog.conf:
  facility.level            @your_loghost
Mire la documentación para saber que usar en lugar de facility y level (ellos no deben ser introducirse de forma literal como se hace aquí). Si usted quiere registrar todo remotamente, escriba:
  *.*                       @your_loghost
into your syslog.conf. Logging remotely as well as locally is the best solution (the attacker might presume to have covered his tracks after deleting the local log files). See the syslog(3), syslogd(8) and syslog.conf(5) manpages for additional information.

4.13.4. Permisos para el archivo de registro

It is not only important to decide how alerts are used, but also who has read/modify access to the log files (if not using a remote loghost). Security alerts which the attacker can change or disable are not worth much in the event of an intrusion. Also, you have to take into account that log files might reveal quite a lot of information about your system to an intruder who has access to them.
Algunos permisos para el achivo de registro no son perfectos despúes de la instalación. Primero /var/log/lastlog y /var/log/faillogno necesitan tener un permiso de lectura para un usuario normal. En el archivo lastlog usted puede ver quien entró recientemente y en faillog usted mira un resumen de las entradas fallidas. El autor recomienda cambiar permisos a 660.Haga una breve revisión en sus archivos de registro y decida muy cuidadosamente cuales logfile deben tener permiso de lectura y escritura para un usuario con UID distinto a 0 y un grupo aparte de 'adm' o 'root'.
  #  find /var/log -type f -exec ls -l {} \; | cut -c 17-35 |sort -u
  (see to what users do files in /var/log belong)
  #  find /var/log -type f -exec ls -l {} \; | cut -c 26-34 |sort -u
  (see to what groups do files in /var/log belong)
  # find /var/log -perm +004
  (files which are readable by any user)
  #  find /var/log \! -group root \! -group adm -exec ls -ld {} \;
  (files which belong to groups not root or adm)
To customize how log files are created you will probably have to customize the program that generates them. If the log file gets rotated, however, you can customize the behavior of creation and rotation.


[26] there's a very good article on it written by http://www.spitzner.net/swatch.html