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').
© 2002 Antonio Villalón Huerta
