Logueando toda actividad con iptables

Iptables, por default tiene la regla filter en modo “Aceptar todo”, es decir, que deja entrar y salir toda conexión desde o hacia nuestra PC, pero, ¿Y si deseamos loguear toda la info de conexiones hechas a nuestros servers o PCs?

 

 

Nota: El procedimiento que ahora ejecutaré es válido 100% en distribuciones Debian/Debian-based, por lo que si usted usa Slackware, Fedora, CentOS, OpenSuSe, puede que el procedimiento no sea el mismo, recomendamos leer y entender el sistema de logueo de su distribución antes de aplicar lo que más adelante se expone. También existe la posibilidad de instalarse rsyslog en su distribución, si está disponible en los repositorios, aunque en este tutorial, se explica también syslog al final.

Todo bien hasta ahora, pero, ¿Dónde vamos a loguear? Fácil, en el archivo “/var/log/firewall/iptables.log“, que no existe, hasta que lo creemos nosotros mismos…

1- Debemos crear el archivo “iptables.log” dentro de la carpeta “/var/log/firewall” que debemos crearla, pues tampoco existe.

mkdir -p /var/log/firewall/
touch /var/log/firewall/iptables.log

2- Permisos, muy importante…

chmod 600 /var/log/firewall/iptables.log
chown root:adm /var/log/firewall/iptables.log

3- Rsyslog, el demonio de logueo de Debian, lee la configuración desde “/etc/rsyslog.d“, por lo que debemos crear un archivo que yo llamaré “firewall.conf” desde el cual rsyslog, pueda interpretar lo que queremos hacer.

touch /etc/rsyslog.d/firewall.conf

Y dentro le dejamos caer suavemente el siguiente contenido:

:msg, contains, “iptables: ” -/var/log/firewall/iptables.log
& ~

Ni tengo ni la menor idea, ¿qué hacen este par de líneas?

La primera línea chequea los datos logueados buscando la cadena “iptables: ” y lo añade al archivo “/var/log/firewall/iptables.log

La segunda, detiene el procesamiento de la información logueada con el patrón anterior para que no siga siendo enviada a “/var/log/messages“.

4- Rotando el fichero de logs, con logrotate.

Debemos crear dentro de “/etc/logrotate.d/” el archivo “firewall” el cual contendrá el siguiente contenido:

/var/log/firewall/iptables.log
{
rotate 7
daily
size 10M
dateext
missingok
create 600 root adm
notifempty
compress
delaycompress
postrotate
invoke-rc.d rsyslog reload > /dev/null
endscript
}

Para así poder rotar los logs 7 veces antes de borrarlos, 1 vez al día, tamaño máximo del log 10MB, comprimido, con fecha, sin dar error si el log no existe, creado como root.

5- Reiniciar, como todo final feliz xD, el demonio rsyslog:

/etc/init.d/rsyslog restart

¿Cómo probar que todo eso está trabajando?

Probemos con SSH.

Instalar OpenSSH (en caso de que no lo tengan instalado…):

apt-get install openssh-server

Antes de continuar, debemos ejecutar como root en una consola:

iptables -A INPUT -p tcp --dport 22 --syn -j LOG --log-prefix "iptables: " --log-level 4

Ejecutando esta sentencia iptables logueará info suficiente para demostrar que lo que hemos hecho no es en vano. En esta sentencia le decimos a iptables que loguée toda información que le llegue por el puerto 22. Para probar con otros servicios, solamente cambiar el número del puerto, como 3306 para MySQL, por sólo citar un ejemplo, si desea más información, lea este tutorial muy bien documentado y basado en ejemplos tipicos de las configuraciones más usadas.

SSH usa el puerto 22 por default, por lo que haremos la prueba con él. Teniendo instalado openssh, nos conectamos a él.

ssh pepe@servidor-de-prueba

Para ver los logs, con un tail resuelves ese problema:

tail -f /var/log/firewall/iptables.log

Iptables, en este ejemplo, loguea todo, día, hora, ip, mac, etc, lo que lo hace genial para monitorear nuestros servers. Una pequeña ayuda que nunca está de más.

Ahora, tomando nota de que usamos otra distro, como decía al principio, generalmente se usa rsyslog, o algún similar. Si tu distro usa syslog, para realizar el mismo ejercicio debemos editar/modificar ligeramente syslog.conf

nano /etc/syslog.conf

Añadir y guardar la siguiente línea:

kern.warning /var/log/firewall/iptables.log

Y después, ya sabes, el final feliz:

/etc/init.d/sysklogd restart

Resultado: el mismo.

Eso es todo por ahora, en próximos posts, seguiremos jugando con iptables.

Referencias:

Force iptables to log to a different file

Log iptables to a separate file with rsyslog

Iptables configuration tutorial on Fedora/RHEL systems


8 comentarios

  1.   FerreryGuardia dijo

    Cojonudo este “mini-manual” para BOFH que estais haciendo poco a poco

  2.   Koratsuki dijo

    Gracias, poco a poco iré dando detalles y datos de iptables, que yo tuve que conocer por mi trabajo, que a veces necesitamos y están muy mal explicados en Internet, todo por el usuario… xD

    1.    KZKG^Gaara dijo

      Aprovecho para darte la bienvenida socio 😀
      De veras tienes MUCHO que aportar, tienes conocimientos realmente avanzados de redes, sistemas, firewalls etc, así que seré (ya soy) uno de los tantos lectores que tendrás jajaja.

      Saludos y bueno… ya sabes, para lo que haga falta 😀

    2.    isar dijo

      Espero con ansias esos artículos ^^

  3.   Hugo dijo

    Anda Koratsuki, no sabía que frecuentabas este blog.

    Por cierto, otra variante de registrar la actividad del cortafuegos es mediante el paquete ulogd, que esta hecho por la gente del proyecto netfilter para facilitar la separación de este tipo de trazas (permite guardarlas de diferentes maneras). Es el acercamiento que suelo usar yo. Utilizarlo es fácil, por ejemplo:

    iptables -A INPUT -p udp -m multiport ! --ports 53,67:68 -m state --state NEW -j ULOG --ulog-prefix "Solicitud UDP dudosa"

  4.   Koratsuki dijo

    Tendré que darle un F5 al post, me cuadra la forma de trabajar de Ulogd, hasta de MySQL loguea el tipo :D.

  5.   msx dijo

    Buen post, keep it up.

  6.   chinoloco dijo

    Hola capo, como va?
    Me podrías dar una mano?
    Ya que no me sale lo del tutorial, y esta mas claro que el agua, no se en que le erro

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

*

*

  1. Responsable de los datos: Miguel Ángel Gatón
  2. Finalidad de los datos: Controlar el SPAM, gestión de comentarios.
  3. Legitimación: Tu consentimiento
  4. Comunicación de los datos: No se comunicarán los datos a terceros salvo por obligación legal.
  5. Almacenamiento de los datos: Base de datos alojada en Occentus Networks (UE)
  6. Derechos: En cualquier momento puedes limitar, recuperar y borrar tu información.