NetfilterFirewall es el nombre del proyecto, dentro de la solución que hemos creado en monodevelop, donde estamos programando lo necesario para gestionar las reglas a través de iptables.

En el momento actual la librería es capaz de crear una jerarquía de objetos que representa al siguiente fichero de configuración de iptables en el formato de iptables-restore:

Aún queda mucho camino por recorrer. Netfilter permite definir dos puntos de extensión para las reglas del firewall (match extensions y "target extensions") y yo he implementado la lógica para soportar eso programáticamente pero sólo he definido algunas de las extensiones que vienen en el paquete de netfilter (porque son bastantes). Así que cualquier regla que las use no podrá ser manipulada adecuadamente y de momento habrá que limitarse a crear reglas con las extensiones soportadas.

Estas clases no dependen de otras partes del proyecto así que podrían ser usadas fácilmente por otros proyectos. Si se diera el caso ayudaría mucho a mejorarla que alguien se pusiera a utilizarla.

Por lo pronto vamos a centrarnos en la captura y análisis de paquetes para la detección de llamadas y la modificación de reglas para permitir/denegar accesos a los servicios.

Me despido y sigo picando código.

Saludos.

Después de mucho tiempo, más información sobre el progreso de SharpKnocking. Hemos decidido que usaremos ulogd para hacer el registro de paquetes en modo OPRINT, luego este registro de paquetes lo monitorizaremos (salvo desinformación extrema) con un StreamReader en la parte del servidor.

En el payload de los paquetes irá el número de paquete, y posiblemente la IP de la fuente encriptada con una clave, aunque tenemos que ver como lo haremos.

Para probarlo he ido a meter las reglas en iptables para hacer el fordward a ulogd, pero hoy nuestro firewall preferido tiene un mal día.

Pero bueno seguimos en la brecha a ver si lo tenemos a tiempo.

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.

Pues esos, aquí seguimos, vivos, y escribiendo el código de esto a poquito a poco y con cariño y suavidad, como debe ser.

Entre los exámenes de febrero del Migue y tal la cosa por su parte se paró un poquillo pero ya vuelve a la brecha nuestro adicto al trabajo corporativo oficial

Actualizó a la última versión de mono porque su distribución (Fedora) trae una versión bastante anticuadilla, y siendo como es un usuario ávido del .Net de Hasfroch Corp. el pobre no podía soportar algunas cosas. Yo actualicé sólo Monodevelop, que hace las cosas bastante mejor que antes, por ejemplo el autocompletado ahora me anda (aunque eso era seguro problema de la versión instalada que tenía yo en mi Kubuntu) y también algunas cosillas útiles como sacar los TODO del código y tal. Todavía le falta un hervor, pero esta mejorando.

Yo estoy a punto de acabar el primer programa cliente de la "suite" SharpKnocking (si es que se le puede llamar así, me tomaré una pequeña licencia), de hecho me pongo a ello en cuanto acabe de postear esto.

Cuando lo acabe, me pondré ipso facto a comenzar la interfaz del servidor, que avisará al usuario de que se ha abierto un puerto, permitirá crear las llamadas que se reconocen para decidir si se abren, desactivar la apertura de puertos (modo "bunker"), etc.

Más en próximos post, chao.

Ya tengo avanzado el diseño de la parte que parseará la salida del comando iptables-save y convertirá la información a una estructura de objetos que podamos manejar cómodamente desde código. En un principio no voy a escribir el soporte para cargar todos los posibles comandos y opciones que soporta iptables ya que estamos en época de exámenes y de monento nos será más práctico poder cargar configuraciones básicas e irlo complicando más adelante cuando ya esté funcionando en condiciones.

Por otro lado en el tema del servicio (demonio) lo probaremos inicialmente usando un script bash que lo lance en el inicio de la máquina y lo deje corriendo en segundo plano. De esta manera nos será mas fácil comenzar a probar y tener algo de funcionalidad en marcha que ya mejoraremos cuando llegue su momento.

PD: Ya le voy cogiendo el truco al monodevelop y comienzo a ser algo productivo

Como al parecer el hosting del boss no permite algunas cosillas por cosas de seguridad, la galería de imágenes integrada en el motor de blogs que usamos no puede funcionar correctamente, así que para poder usar una galería donde mostrar algunas imágenes que ilustren el desarrollo del proyecto, he abierto un nuevo (de hecho el primer ) álbum en Picasa Web.

Podéis acceder al álbum desde aquí pero también siempre desde el enlace en el menú lateral.

Poco a poco habrá más imágenes, paciencia.

PD: Ya tenemos algo de "arte" propio para el proyecto, como se puede ver en el titulo de la página. El puño esta dibujado a partir de una foto de móvil de mi propio puño , y luego dibujado los contornos y el relleno con el programa de ilustración vectorial multiplataforma Inkscape, y retocado con Gimp. Software libre, como debe ser.

Lo primero pedir disculpas por el largo lapso de tiempo en que no ha habido noticias nuestras en el blog del proyecto. Les pedimos a los evaluadores del concurso que sean condescendientes con nuestras humildes personas, hemos estado atareados, sobre todo mi compañero, para ser honestos.

Sin embargo, ya hemos empezado a escribir código, y empieza a haber algo de calor en las anteriormente frías salas del repositorio de subversion del proyecto.

Espero tener el cliente que realiza las llamadas para finales del mes de enero, y bueno Miguel también tendrá muchas cosas hechas para ese punto, una vez se haya hecho con las riendas de las herramientas de desarrollo.

Pese a su (leve, menos "hardcore" que yo ) linuxerismo, lleva mucho tiempo trabajando con Microsoft Visual Studio, que no esta nada mal, reconozcamoslo, pero que con la gran cantidad de ayudas a la programación te acostumbra a que te den demasiadas cosas hechas. ¡A estirar los músculos cerebrales Bosssss!

Saludos a todos.

En nuestro proyecto necesitamos controlar de alguna manera la llegada de tráfico entrante a los puertos de la máquina. El tráfico del que queremos ser notificados por lo normal serán paquetes que han sido descartados por el resto de reglas y están apunto de ser rechazados o descartados (en función de cual sea la última regla del fichero iptables). Tampoco recogeremos todo el tráfico descartado, ya que sólo nos interesa el tráfico que vaya a los puertos que se hayan configurado para ser gestionados para port knocking.

Tras consultar la página de manual de iptables (man iptables) me he dado cuenta de que iptables proporciona todo lo necesario y es posible que no tengamos que usar ninguna otra librería aparte (por ejemplo libpcap como ya había comentado).

Las dos opciones principales que hay son el target LOG y el target ULOG.

1 - Target LOG.

Iptables proporciona un target LOG que permite lloguear el paquete en el log del systema (/var/log/messages en mi fc3). También permite opciones para poner un prefijo al principio de la entrada de log lo cual sería muy útil para extraer del log las líneas que nos interesan. Esta opción es simple y bastaría con monitorizar el log, pero tiene el inconveniente de que dispara el tamaño de este log si no se acota que tipo de paquetes son logueados al ser rechazados.

Por otro lado limita la información disponible en el log ya que no loguea el cuerpo del paquete, loguea los datos básicos de ips fuente y destino, puertos y alguna cosa mas. Esto evitaría que pudieramos enviar desde un cliente un mensaje en los paquetes que utilizamos para "llamar a la puerta".

2 - Target ULOG

Otra opción que nos proporciona iptables es el target ULOG que permite loguear los paquetes y pasarlos al espacio de usuario a través de un socket netlink.

Esto requiere mezclar código c y c# para interconectar el uso del socket con c# así que en principio es más complejo, pero tiene la ventaja de que el proceso que se encargue de analizar los paquetes estará funcionando como aplicación de usuario (menos privilegios y por tanto mayor seguridad) y además podremos analizar el contenido de los paquetes de modo que los clientes cuando "llamen a la puerta" nos manden un mensaje troceado en los paquetes.

¿Que opción implementaré?

Dado que tanto una como otra son opciones válidas lo suyo sería implementar las dos y dejar que por configuración se elija la opción que se quiera. Así que comenzaré por investigar e implementar la primera y si me da tiempo podría implementar la segunda de manera que se puede especificar por configuración cual de las dos opciones usar.

Para implementar el proceso que vaya leyendo el fichero de log usaré las implementaciones de clases que se han introducido con la última versión de mono en el namespace System.ServiceProcess. Lo cual es una suerte ya que si funciona correctamente nos habrá simplificado mucho la tarea de crear el demonio de sharpknocking

Cuando disponga de algo de código de ejemplo que funcione lo comenzaré a subir a la forja para ir dándole uso.

Saludos.

Bien, durante los últimos días, yo y mi compañero hemos tenido las primeras conversaciones de diseño y planificación del proyecto.

Yo me encargaré principalmente de todos los aspectos de interfaz de usuario y programas clientes en general, mientras que Miguel Ángel se encargará principalmente de la parte de servidor, conexión con las librerías nativas que muy posiblemente tengamos que utilizar dependiendo de como resolvamos algunas cuestiones técnicas una vez que nos enfrentemos a ellas directamente.

Los principales componentes del programa sería los siguientes, según el diseño que propusimos finalmente:

• Tendremos un programa cliente, que nos permitirá realizar una llamada desde cualquier ordenador, que por supuesto cumpla los requisitos para la ejecución del mismo (léase Mono - o .Net quizá).

• Tendremos, en el ordenador que queremos proteger, por una parte una librería, encargada de, posiblemente, parsear los logs de iptables que nos permitirán saber si una determinada secuencia de paquetes han llegado, y por otra parte, una interfaz que nos permita definir dichas secuencias, y comunicar a iptables que abra los puertos indicados si llega, y que cree el log que permita reconocer la secuencia.

Con eso, deberíamos tener nuestro sistema de portknocking listo.

Como leí en algún sitio, para que un software llegue a funcionar correctamente, se necesitan al menos dos implementaciones, la primera de ellas nos pondrá en conctacto con el problema, y la segunda nos permitirá resolverlo con el conocimiento adquirido de los problemas que presentó la primera, de una manera posiblemente más elegante y eficiente. Por supuesto, esto es un concepto general, y esperemos que resovlamos los problemas que aparezcan de un plumazo

Durante las próximas semanas esperamos tener los primeros retazos de código, para ir abriendo boca.

Saludos.

¡Ya está habilitada la forja para el proyecto!.

De momento no subiremos archivos durante esta semana ya que aún andamos un poco escasos de tiempo y quedan cosas por planificar y postear en este santo blog.

Así que apuntaros el enlace: https://forja.rediris.es/projects/csl-csknocking/

Saludos.

Modificación de las reglas del firewall

Queremos hacer un sistema de control de acceso a puertos así que lo primero que necesitaremos es la capacidad de modificar el fichero de configuración de iptables para introducir las reglas de acceso que nos permitan tal comportamiento.

Hay que modificar el fichero con cuidado para no dejar el sistema vulnerable, pero por otro lado hay varios programas de usuario para configurar ràpidamente las reglas del firewall. Así que cuando tengamos una primera versión del programa tendremos que investigar y ver que ocurre.

Si nuestra aplicación es incompatible con los wizards que editan las reglas de firewall quizás tengamos que considerar la opción de proporcionar nosotros mismos un mecanismo de configuración de reglas del firewall.

Captura de paquetes

Una vez que tengamos las reglas del sistema preparadas para que todo paquete entrante se bloquee, sin ofrecer ni siquierea un mensaje icmp de error, necesitamos un mecanismo que permita a un usuario remoto usar una secuencia secreta de llamadas que abrirá un puerto para que pueda conectarse a un determinado servicio.

Cada llamada puede ser un ping o cualquier otro tipo de tráfico dirigido a uno de los puertos cerrados. De modo que el sistema tiene que monitorizar la llegada de paquetes a un conjunto dado de puertos y comprobar el orden de llegada. Esa sería la llamada secreta que podría abrir un puerto para conexión por ssh, por ejemplo.

De este modo podríamos usar una de estas dos opciones:

• Configurar las reglas del firewall para que loguee los paquetes rechazados que llegan a los puertos que están involucrados en la llamada. Habría que monitorizar y tratar los cambios en el fichero de log dado.
• Usar una librería de captura de paquetes. Esta opción tiene la complejidad añadida de tener que realizar un wrapper en c# para mono de la librería en cuestión para que podamos utilizarla.

Yo inicialmente pienso que deberíamos usar una librería de captura de paquetes ya que la opción de parsear el log no es programáticamente tan interesante como el uso de la librería que requerirá realizar un wrapper en c# para usarla desde mono y que nos abstraiga de las complejidades de la misma. La opción de ir parseando el log es además una opción poco recomendable ya que no tiene un formato estándard.

Una librería bastante conocida es libpcap (http://www.tcpdump.org/) muy utilizada por aplicaciones como snort, nessus y netfilter. Pero conllevaría incluir una nueva librería a la lista de dependencias de la aplicación.

Aunque otra elección podría ser el demonio ulogd del proyecto netfilter (http://www.netfilter.org). éste demonio se encarga de funciones de log de paquetes , así que es una opción importante a considerar ya que es parte del mismo proyecto que iptables.

Hasta aquí mis dos ideas iniciales. Pronto mi compañero montará la forja y podremos iros contando cosas con un poco de código de base.

Yo soy el otro desarrollador del proyecto, y bueno, la idea de usar Jaws para el sitio web del blog fue mía, así que espero que les guste

Según vaya el proyecto iremos posteando, así que si están interesados en seguir el desarrollo, entrad regularmente o añadid la fuente de Atom o RSS con los botones del final de la página.

¡Saludos!

Éste es el blog para el proyecto sharpKnocking.

El proyecto trata sobre realizar un sistema de port knocking implementado en c# sobre mono en linux.

El port knocking es un modo de aumentar la seguridad de un sistema ocultando los puertos abiertos en una máquina modificando las reglas del firewall.

Para poder alcanzar un puerto es necesario realizar una secuencia de llamada para que permita conexiones entrantes.

En éste blog iremos realizando un seguimiento del estado del proyecto.