CREAR UN LOG PROPIO PARA IPTABLES

Tweet
Copyright
2005-2015
Sergio
Gonzlez
Durn
Se concede permiso para copiar, distribuir y/o modificar este documento siempre y cuando se cite al
autor y la fuente de linuxtotal.com.mx y segn los trminos de la GNU Free Documentation License,
Versin 1.2 o cualquiera posterior publicada por la Free Software Foundation.

autor: sergio.gonzalez.duran@gmail.com

Prcticamente todos los mensajes generados por el sistema se guardan

por default en /var/log/messages, esto es til y necesario, pero de una
manera muy sencilla podemos hacer que los eventos o mensajes
generados por iptables se guardan en su propio archivo de bitacora
(log).

Editar /etc/syslog.conf
En este archivo de configuracin se indica el modo en que los mensajes
del sistema son bitacorizados a travs de la utileria syslogd que se
instala y configura por default en todos los sistemas GNU/Linux y rara
vez el usuario del sistema la modifica, pero en esta ocasin lo abriremos
(con tu editor favorito) y haremos lo siguiente:
#> vi /etc/syslog.conf
Y aadimos al final la siguiente lnea
kern.warning
/var/log/iptables.log

/etc/syslog.conf se compone de varias lneas y cada lnea es una regla

que indica como bitacorizar los mensajes del sistema. Cada regla tiene
dos campos, tal como el que aadimos al final. El primer campo
(kern.warning) es el "selector" que se compone de dos partes separadas
por el punto: facility.priority, 'facility' que en este caso es kern (kernel)
representa el subsistema que produce el mensaje y 'priority' define la
severidad del mensaje. Estas pueden ser en orden ascendente: debug,
info, notice, warning, error, crit, alert, emerg.
Entonces 'warning' es el nivel 4 de prioridad e indica entonces que todos
los mensajes provenientes del kernel que tengan un nivel de prioridad 4
o mayor se bitacorizarn en el archivo /var/log/iptables.log y se ignoran
los de debug, info y notice que son del 3 haca abajo y que
generalmente son irrelevantes.

Es importante aclarar que los mensajes del sistema tambin seguirn

guardndose en /var/log/messages y otros que se tengan definidos
en /etc/syslog.conf ya que lo que hicimos fue 'aadir' una lnea ms y
no modificamos nada de lo que ya estaba ah.

Reiniciando el servidor syslog

Como cualquier otro programa servidor hay que reiniciarlo para que los
cambios en el archivo de configuracin surtan efecto.
#>
#>
si
#>

/etc/rc.d/init.d/syslog restart
/etc/init.d/syslog restart
tienes el comando service instalado
service syslog restart

o en varias distros

Modificando el firewall
Si por ejemplo quieres bitacorizar todo lo que sea rechazado en la
cadena INPUT:
iptables -A INPUT -j LOG -log--level 4
iptables -A INPUT DROP

Es decir, generalmente se usar el targer LOG antes de rechazar los

paquetes que no queramos, y como notars en el ejemplo usamos la
opcin -log--level 4 que activar syslog solo cuando el mensaje sea del
tipo warning (4) o superior.
Un ejemplo ms interesante es el siguiente:
iptables -A
iptables -A
DE ACCESO A
iptables -A

INPUT
INPUT
SSH '
INPUT

-s 192.168.10.10 -p tcp -m tcp --dport 22 -j ACCEPT

-p tcp -m tcp --dport 22 -j LOG --log-prefix 'INTENTO
--log-level 4
-p tcp -m tcp --dport 22 -j REJECT

En este caso, la primera regla est aceptando a la ip 192.168.10.10,

pero si es cualquier otra ip, entonces se bitacoriza el evento con el
mensaje 'INTENTO DE ACCESO A SSH ' en /var/log/iptables.log
Esto es mucho ms til ya que posteriormente con un simple grep
podremos observar solo los mensajes de este tipo:
#> grep 'INTENTO DE ACCESO A SSH' /var/log/iptables.log
Apr 13 10:43:39 equipolinux kernel: INTENTO DE ACCESO A SSH IN=eth1 OUT=
MAC=00:50:fc:89:63:39:00:16:e6:82:cd:8a:08:00 SRC=192.168.10.16
DST=192.168.10.100 LEN=48 TOS=0x00 PREC=0x00 TTL=128 ID=4601 DF PROTO=TCP
SPT=1138 DPT=22 WINDOW=65535 RES=0x00 SYN URGP=0
Apr 13 10:44:10 equipolinux kernel: INTENTO DE ACCESO A SSH IN=eth1 OUT=
MAC=00:50:fc:89:63:39:00:16:e6:82:cd:8a:08:00 SRC=192.168.10.16
DST=192.168.10.100 LEN=48 TOS=0x00 PREC=0x00 TTL=128 ID=4602 DF PROTO=TCP
SPT=1138 DPT=22 WINDOW=65535 RES=0x00 SYN URGP=0

Se puede apreciar que hay dos intentos de acceder al servidor ssh del
equipolinux (192.168.10.100) desde el equipo 192.168.10.16 y con tan
solo algunos segundos de diferencia, esto ya es sospechoso y habra que
investigar quien est intentando conectarse y porque. (Claro estando en
una LAN que controlemos)
Pues ah lo tienes, puedes agregar a tus reglas de iptables todos los
targets LOG que consideres necesarios y revisarlos ms utilmente en un
archivo por separado. Espero te sea til.