Iptables

Netfilter/Iptables, logs y ajustes en el kernel
La finalidad de este artículo es presentar algunos aspectos tal vez no muy conocidos y/o avanzados relacionados con iptables y su funcionamiento, el fin no es explicar iptables, esta de mas decir que el tema es muy extenso y para que este "pequeño articulo" permanezca pequeño no queda opción mas que asumir que quien lee posee un buen conocimientoprevio, además de conocer y comprender el funcionamiento de protocolos como ethernet, IP, TCP y UDP, y el comportamiento del kernel respecto a ellos. Se asume entonces que usted sabe por ejemplo lo que es tamaño de ventana, una conexión half-open o el RTO. La idea es mencionar lo que son buenas prácticas a la hora de implementar un firewall, los criterios a la hora de registrar eventos en un log ylas variables del núcleo más significativas respecto a eso. El articulo no sigue un formato, son mas bien una lista desordenada de comentarios y experiencias relacionados con el tema.

Logs y iptables
¿Que gestor de logs utilizar?
Definitivamente ULOG es la mejor alternativa, de hecho Ulog e Iptables pertenecen al mismo proyecto, el proyecto Netfilter [http://www.netfilter.org/]. Además serámás fácil separar el log de iptables de los logs del sistema y la rotacion de los mismos está configurada por defecto. Otro motivo, por lo menos a mi parecer, es que puede ser deseable, si estamos dispuestos a asumir el riesgo de perder algún registro del log, desactivar la sincronización del archivo, sincronización es forzar la inmediata escritura en disco por cada registro nuevo, algo fundamentalen un archivo de bitácora, lo cual lograría mejorar la velocidad y reducir sobrecargas en un equipo de rendimiento limitado que además cuenta con algún otro servicio además de un firewall, por ejemplo un Proxy caché, no tendría sentido si el equipo se utiliza solo como firewall. Aclaro que todo esto es posible hacerlo con syslog pero con ulog es más fácil, además no es muy recomendable utilizarsyslog ya que este maneja eventos de diferentes orígenes en un mismo archivo.

¿Como debemos registrar?
Lo deseable será que para cada registro se agregue, mediante la opción –ulog-prefix, una cadena de texto descriptiva que incluya la cadena en la que se detecto el evento (INPUT, OUTPUT, FORWARD o cadenas de usuario), el por que se registró, (New not Syn, nullflags, etc) y que acción se llevo acabo (DROP, REJECT, ACCEPT) Debe tenerse en cuenta también que una mala definición de las reglas seguramente degenerará en un archivo de log excesivamente grande con la información demasiado

dispersa o repetida y que resultará potencialmente inútil, por esto es conveniente definir la regla con la opción -m stare --state NEW. Es muy recomendable también no loguear tráfico broadcast o en sudefecto con la opción limit

¿Que debemos registrar?
Lo primero que debe decidir alguien que ha comprendido la importancia de los logs es ¿Que es lo que queremos loguear? Una buena práctica me parece que seria registrar en el log los siguientes eventos (se incluye como ejemplo la etiqueta que me parece adecuada): New not Syn [INPUT REJECT]: así para todas las cadenas y preferentemente sin la opciónlimit, esto ultimo puede hacer crecer el log bastante rápido pero nos ayudará a determinar, por ejemplo, que tal o cual host envía repetidamente New not Syn o darnos cuenta que nosotros mismos estamos generando segmentos de este tipo (mas adelante se menciona a que se llama New not Syn). WAN -> INPUT [INVALID DROP]: para registro de datagramas[1] en estado INVALID WAN -> INPUT [REJECT]: pararegistro de intentos de conexión a puertos bloqueados, del mismo modo todos los intentos del tipo LAN -> WAN, DMZ -> LAN, OUTPUT -> WAN, etc. Acceso WAN -> DMZ [FORWARD ACCEPT]: registro de conexiones externas a por ejemplo un acceso ssh a un servidor en DMZ, es decir que se registra una conexión externa perfectamente valida, lo mismo si la conexión proviene de LAN o del mismo firewall. WAN ->...