Al fin se acabó el cuatrimestre y vuelvo a disponer de más tiempo para el proyecto. Así que os pongo al día.

Ya soy un desarrollador productivo en monodevelop. Tal como ha contado Luís ahora estamos usando la última versión compilada desde el svn así que el autocompletado y muchas otras cosas funcionan como deben y yo les estoy sacando provecho para poner a punto las clases que cargarán y generarán las reglas para iptables.

He tenido que darle muchas vueltas a la página del man, a la salida del comando 'iptables --help' y a varios tutoriales pero ya casi he terminado.

A la hora de la implementación en un primer momento realicé unas cuantas clases genéricas con todas las propiedades necesarias para crear las opciones de las reglas. Eso da la ventaja de que era rápido de implementar pero hacía muy trabajoso todo tipo de chequeos de seguridad además que a quien le tocara usarlas se iba a despistar un poco que toda propiedad fuera string u object.

Así que me decidí a realizar una implementación con más clases para poder usar tipos específicos para los métodos get y set de las propiedades. Mis clases genéricas se volvieron abstractas para que no se puedan instanciar y obligar a implementar ciertos métodos de conversión de cadenas y chequeos de seguridad de tipos. Por cada tipo de opción, extensión y comando (son los tres tipos de elementos con que uno forma las reglas de iptables) hay una clase que lo modela y que implementa los métodos de la clase padre que comprueban que se usan los tipos correctos al crearlas.

Así por tanto la siguiente regla (típica en una fedora core 6):

-A RH-Firewall-1-INPUT -p icmp -m icmp --icmp-type any -j ACCEPT

Correspondería a la siguiente estructrura de referencias y tipos, que comprenderéis mejor cuando generemos la documentación, pero de momento es útil como ejemplo de lo que estamos haciendo:

Notación: Las flechas indican una referencia a un objeto. Los paréntesis indican que la referencia es a un tipo abstracto pero que realmente hay asignado (boxed) un tipo derivado. Los corchetes son para acceder listas de elementos. Todo lo que está deltante de un punto es un tipo y lo que hay detrás puede ser otro tipo o una propiedad.

Aquí se ve que abusando un poco de los conceptos he creado un objeto IpTablesRule que es la base para definir no sólo las condiciones de la verdadera regla, si no también la acción a realizar con esa regla, que en este caso es añadirla al final de la cadena de reglas de entrada llamada RH-Firewall-1-INPUT (nombre generado por el configurador de fedora).

Ahora sólo me queda probarlas y pulir los fallos. Estas clases pueden ser útiles para modificar las reglas de iptables existentes, así que si tengo tiempo intentarí crear una pequeña interfaz gráfica para probar y de paso gestionar las reglas de mi máquina.

Hay que tener en cuenta que no se ha implementado todo lo necesario para soportar las dos posibles extensiones de reglas existentes. No se ha implementado soporte para usar targets' definidos a medida (ejemplos de targets: DROP, REJECT) ni match extensions' (son las extensiones que he comentado anteriormente). En el caso de las extensiones se han implementado las imprescindibles ya que son un gran número y cada una tiene su conjunto de opciones particular y en el caso de los targets se han implementado todos los que vienen definidos de base.

En todo caso mi siguiente movimiento consiste en ver como capturar los paquetes entrantes para detectar las secuencias de llamada.

En un post anterior comenté varias opciones y la que primero intentaré estará basada en netfilter y el target ULOG para las reglas. El único problema es que quizás me tenga que programar en c una cola donde se vayan copiando los paquetes que entran por la regla de log y luego realizar un wrapper en C# para poder usarlo. Pero esto no lo sabré seguro hasta que me meta en faena.

Bueno, esto es todo por el momento.

Un saludo.