next up previous contents
Siguiente: IPFilter Subir: ipfwadm/ipchains/iptables Anterior: Gestión   Índice General

El sistema de log

Evidentemente, tanto ipchains como iptables están preparados para generar logs en el sistema: ambos permiten registrar mediante syslogd los paquetes que cumplan cierta regla - por norma general, todos -. Un registro exhaustivo de las acciones que se toman en el núcleo con respecto al filtrado de paquetes no es conveniente: la gran cantidad de información guardada hace imposible detectar actividades sospechosas, y además no es difícil que se produzcan ataques de negación de servicio, ya sea por disco ocupado o por tiempo consumido en generar y guardar registros. Por tanto, lo habitual es almacenar sólamente los paquetes que no sean rutinarios (por ejemplo, intentos de conexión desde direcciones no autorizadas, ciertos paquetes ICMP no habituales...).

En el caso de ipchains el núcleo de Linux, a través de klogd y de syslogd, registra estos eventos con prioridad `info', y al provenir del kernel (no olvidemos que el subsitema de filtrado forma parte del núcleo del operativo), su tipo es obviamente `kernel'. Para que cuando un paquete haga match con una regla se genere un registro hemos de utilizar la opción `-l'; por ejemplo, si deseamos que cada vez que alguien intente hacer un finger contra la máquina el tráfico, aparte de ser denegado, registre un log, ejecutaremos una orden como la siguiente:
luisa:~# /sbin/ipchains -A input -p tcp -j DENY -l -s 0.0.0.0/0 \
> -d 158.42.22.41 79
luisa:~#
Así, si estos registros se almacenan en el fichero /var/adm/fwdata, sus entradas serán de la siguiente forma:
rosita:~# tail -1 /var/adm/fwdata
Apr  3 02:03:13 rosita kernel: Packet log: input DENY eth0 PROTO=6 \
 158.42.2.1:1032 158.42.22.41:79 L=34 S=0x00 I=18 F=0x0000 T=254
rosita:~#
El anterior mensaje nos dice principalmente que un paquete con protocolo 6 (corresponde a TCP en nuestro archivo /etc/protocols) proveniente de la dirección 158.42.2.1 y destinado a nuestro servicio finger ha sido denegado; el resto de la información no la veremos aquí (se puede consultar la documentación del producto para ver el significado concreto de todos y cada uno de los campos registrados).

En el caso de iptables el registro de eventos generado por el subsistema de filtrado es algo diferente al de ipchains, tanto al hablar de su funcionamiento como de su sintaxis. Ahora el log se realiza a través de un target independiente (LOG) que registra las tramas que hacen match con una regla determinada, y la prioridad de registro ya no es `info' sino que se puede indicar en la propia línea de órdenes (por defecto es `warning'). Además, se ha definido una nueva extensión denominada `limit' que permite restringir el número de registros que una regla puede generar por unidad de tiempo, lo cual es evidentemente útil para evitar que alguien ataque con éxito nuestros recursos mediante un flood del log en el subsistema de filtrado.

Volvamos de nuevo al ejemplo anterior, en el que registrábamos los intentos de acceso a nuestro puerto 79 (finger) para tener constancia de cuándo alguien trataba de obtener información de los usuarios de nuestro sistema; en el caso de iptables deberíamos definir una regla como la siguiente:
luisa:~# /sbin/iptables -A INPUT -p TCP -m limit -j LOG --log-prefix \
> "FINGER ATTEMPT:" -d 158.42.22.41 --dport 79
luisa:~#
Lo que indicamos mediante esta orden es que genere un mensaje cada vez que alguien envíe tráfico al puerto 79 de la dirección 158.42.22.41 (esto es, cada vez que alguien haga finger contra la máquina). Podemos observar que ahora definimos el target LOG (opción `-j'), y que además aplicamos la extensión `limit' (parámetro `-m') para limitar el registro y evitar así ciertas negaciones de servicio; cada vez que esta regla genere un log añadirá al principio del mismo la cadena `FINGER ATTEMPT:', lo que nos permite identificar de una forma más clara el mensaje. Podemos fijarnos en que a través de esta regla no estamos ni aceptando ni negando el tráfico, sino sólo registrando su existencia: para detener la trama, hemos de indicarlo explícitamente o bien a través de la acción por defecto que hayamos especificado para la chain INPUT (mediante la opción `-P').
next up previous contents
Siguiente: IPFilter Subir: ipfwadm/ipchains/iptables Anterior: Gestión   Índice General
2003-08-08