SharpKnocking

Debido a la gran cantidad de spam que ha vuelto a entrar en este santo blog a través del sistema de trackback de los comentarios los hemos desactivado totalmente.

De cualquier modo tampoco nadie comentaba nada , así que todos contentos.

Saludos.

PD: Malditos spammers ...

Nos hemos propuesto volver a participar en el concurso de software libre este año y para ello hemos elegido para participar otro nombre para nuestro proyecto, ya que son muchas las mejoras planeadas. Así que tras una dura deliberación ha sido iSharpKnocking, con el cual participaremos, si nos dejan, en la segunda edición del concurso.

A muchos les parecerá extraño que queramos participar habiendo estado en la final del año pasado y pensarán que los 15 minutos de fama ya pasaron. Pero en nuestro caso es una forma de reafirmar la existencia y continuidad de este proyecto y de promover el concurso de software libre, además de que nos gusta lo que hacemos y que el resultar ganadores del concurso nunca fue ni será nuestro objetivo (y ser finalistas menos ).

No va a ser fácil ya que ahora disponemos de menos tiempo libre, pero tenemos ilusión por conseguir las metas que nos propusimos en su momento y que aún no se han materializado.

Si se quiere realizar un seguimiento del proyecto lo mejor es leer/rssear este blog, seguir el wiki en Google Code y/o descargar la versión test 0.1 para trastear con ella y ponernos unos cuantos issues .

Respecto al código fuente estamos haciendo muchos cambios últimamente para modularizar el código que tenemos y permitirnos más flexibilidad. De modo que una estructura básica de modulos es actualmente:

• IptablesNet: Librería para interactuar con iptables en c# aprovechando las características de tipado fuerte para resolver la mayoría de errores en tiempo de compilación.
• Developer: Librería de elementos comunes que pueden ser reutilizados en cualquier proyecto.
• SharpKnocking.Daemon: Servicio de captura de llamadas y análisis.
• SharpKnocking.Doorman: Manager de configuración y gestor de llamadas.
• SharpKnocking.PortKnocker: Aplicación cliente para llamadas.

El código fuente se puede obtener del repositorio svn en Google Code o del repositorio svn en la forja de rediris, aunque este último lo tenemos un poco abandonado de momento, pero lo actualizaremos habitualmente cuando comencemos a avanzar.

Un saludo para todos y esperemos pasarlo igual de bien que el año pasado.

Y el proyecto sigue adelante.

Durante este largo tiempo de silencio hemos estado muy ocupados poniendo en pié nuestras bases existenciales y refactorizando el código de la primera versión de SharpKnocking ya que nuestros futuros requerimientos no encajaban con la base de código. Pero nuestro tiempo libre ha escaseado mucho este verano, por lo que nos ha pillado el siguiente curso

También estrenamos nueva versión de jaws pasando de la 0.5.3 a la 0.7.3 y la verdad es que hemos notado el cambio, ¡adiós spammers de referers y comentarios!

Aún estamos un poco aturdidos por el mes de septiembre, pero ya iremos recuperando el ritmo.

Ha llegado el verano y es hora de organizarnos para ver en que gastaremos las energías dedicadas al proyecto.

Desde la final del concurso hemos estado rumiando la idea de refactorizar el código actual ya que son muchas las cosas que tienen que ir entrando y la base de código actual no se ajusta adecuadamente a lo que queremos hacer, por lo que durante este verano planeamos refactorizar profundamente el código hasta quedar satisfechos.

También tenemos otra pequeña novedad, estrenamos lista de correo de desarrollo: http://mail.ilikecoffee.net/mailman/listinfo/sharpknocking-devel_ilikecoffee.net

Invitamos a todos los que están interesados a que la sigan para estar al tanto del estado del proyecto o que nos escriban para cualquier otra cosa. Pero tengo que avisar de que vamos a escribir en inglés, ya que queremos intentar llegar a la mayor cantidad de gente posible con éste proyecto y a que el inglés es el lenguaje de facto para la mayoría de proyectos de software libre.

También invito a aquellos que se atrevan a probar SharpKnocking 0.1 en sus máquinas a que nos dejen los bugs en el tracker o que los manden a la lista, preferiblemente en inglés (aunque sea patatero, no hay problema mientras se entienda).

Saludos.

Bueno, ya han pasado varios días, pero es que estamos muy liados haciendo cosas que fuimos dejando aparcadas antes de la final y nos estamos comenzando a meter en época de parciales tras lo cual llega la época de examenes.

Obtuvimos el segundo premio de nuestra categoría en el concurso siendo el primero para el otro proyecto participante: Porting de Gcc a la arquitectura del microcontrolador 16f877.

Tanto Luís como yo estamos contentos con los resultados así como seguimos planeando nuevas caracteristicas para la siguiente release de SharpKnocking que estamos empezando a planificar para algún día entre Julio y Septiembre.

Desde aquí quiero mandar un gran saludo para todos los finalistas del concurso (que bien lo pasamos) y esperamos ver como todos nuestros proyectos crecen juntos

Hoy he arreglado un bug muy muy feo que impedía la correcta comunicación entre el cliente de configuración, Doorman y el demonio KnockingDaemon y que provocaba que no se pudiese usar correctamente el modo interactivo.

Estando esto andando puede que nos quede una presentación curiosa en la final hehe.

Saludos.

PD: He subido unas cuantas capturas a la galería de imágenes

Pues nada, sin duda en el periodo final de la codificación de un proyecto para su evaluación es sin duda el momento ideal para que el repositorio se caiga.

Esperemos que se arregle pronto, pero de mientras, para poder seguir trabajando nos hemos mudado a Google Code https://sharpknocking.googlecode.com/svn/trunk/. En cuanto la forja del concurso está operativa, pasaremos allí los cambios.

En otro orden de cosas, muchos cambios en todo. Ya tenemos makefiles para el proyecto, generados automáticamente por Monodevelop (en los últimos tiempos ha visto mejoras significativas en cuanto a features, por cierto). Se comprueba que se están ejecutando las cosas, los permisos necesarios para ejecutar los programas, y muchos otros cambios, por lo que esta cogiendo el punto de cocción necesario para que este presentable.

¡Suerte a todos, y saludos!

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.

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

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.