Eso no nos convierte aún oficialmente en Ingenieros en Informática ya que falta esperar las actas de junio y pedir el título.

Pero aún así, ahora hay que decidir que hacer con nuestras vidas, aunque por mi parte siempre ha habido y habrá un huequecito para seguir desarrollando este proyecto.

Mi plan para los próximos meses es terminar el dichoso refactoring que llevo tanto tiempo haciendo en la librería iptables-sharp (antes iptables-net), hacer una pequeña aplicación gráfica que la use y escribir más tests unitarios para ella (hay 0 actualmente ).

Esta versión de la librería es en algunos aspectos más limitada que la versión que hay colgada en el tar.gz en googlecode pero promete mejor mantenibilidad y más facilidad para añadir soporte de extensiónes, antes era demasiado difícil.

Esto es todo, de momento ...

https://forja.rediris.es/svn/csl2-isknocking

Update Lo de migrar al otro repositorio se va a retrasar ya que tenemos algunas pegas que resolver primero. De momento seguimos con el de google code.

La siguiente estadística lo ilustra:

Y donde además se puede ver como se reparten los sistemas operativos teniendo más visitas desde windows que desde linux, pero como usan firefox no importa (yo este post lo estoy escribiendo desde mi windows).

Quizás estas estadísticas nos ayuden a notar a lo largo de la evolución del concurso y del proyecto si nuestros esfuerzos atraen la atención de la comunidad o no.

Saludos.

Nuestros objetivos son en parte algunos de los objetivos no finalizados del año pasado, más algunos que no habíamos ni siquiera tomado en cuenta, más las cosas que se nos han ido ocurriendo por el camino.

Para empezar terminaremos el refactoring y documentación que estaba planeado para la base de código para seguir con la librería que nos permite modificar las reglas de iptables desde código manejado.

A todo lo que hay que hacer hay que unir el handicap de que no tengo conexión en casa por lo que sólo puedo acceder al correo y a subir código cuando estoy en la escuela :S (la culpa es de telefónica que no me pone línea en mi casa), pero a cambio tengo ilusión y ganas de seguir adelante con el proyecto el cual será mi última actividad como alumno este curso académico ya que me queda poco para acabar la carrera.

Un saludos a todos los nuevos y antiguos participantes

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

Saludos.

PD: Malditos spammers ...

¡Bienvenido y a programar! XDXDXDXD

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.

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.

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

Y bueno, algún bug corregiremos para que se vea bien bonita la presentación.

Saludos, y gracias.

Ahí, tenemos colgado un tgz con la versión 0.1 y hemos estado creando algunas páginas en el wiki y recopilando ideas de cosas por hacer en la página de TODO.

La url es:

http://code.google.com/p/sharpknocking

También hemos realizado un poco de tratamiento de excepciones para intentar evitar que el firewall se quede con las reglas que introducimos restaurando un backup de las mismas que realizamos al principio del inicio del daemon.

Ahora queda el paso final, testear los programas en funcionamiento y buscarles las cosquillas para que no peten cuando menos oportuno es

¿Recuerdan que se comentó que se usarían reglas del firewall en conjunción con ulogd para monitorizar los paquetes que nos interesan? Pues bueno, eso resultó ser un completo fracaso, dado que los plugins de salida que ofrecía ulogd no nos daba toda la información sobre el payload del paquete que nosotros necesitamos (o necesitábamos o pensamos necesitar )

Total, que hubo que descartarlo y buscarse otra solución (sobre lo cual juraría haber posteado ya en este nuestro blog, pero bueno, debe ser un momento de deja vú o como se diga )

Nuestro salvador en este aspecto ha sido tcpdump. Este programa es un programa analizador de tráfico de red, en consola. Un wrapper de libpcap, si mal no lo tengo entedido. La cuestión es que durante las últimas dos semanas moví mi foco de trabajo de la interfaz gráfica hacia las entrañas del daemon de reconocimiento de secuencias.

Y he hecho un buen trabajo creo, pues he creado la infraestructura que permite tratar la información ofrecida por tcpdump, convertirla a un formato sencillo de utilizar y enviarlo a un sistema de autómatas para la detección de secuencias.

Del algoritmo concreto que usarán estos autómatas se encargará Miguel Ángel, pues yo vuelvo a mis interfaces para integrar la comunicación entre el daemon y la interfaz de configuración, hacer un icono de notificación que viva alegremente en el área de notificación (no tan trivial como debería) y supongo que algo más.

Así que nada, más noticias pronto.

El siguiente fragmento de código es usado para insertar al principio de la cadena input una regla que redirija todos los paquetes a una cadena llamada SharpKnocking-INPUT donde están las reglas que aceptarín o denegarán el paquete en función de si le hemos dado acceso o no. Es un ejemplo de como usar la librería para alterar las reglas del firewall.

De tal modo que al ejecutar un programa con ese trozo de código para inicializar las líneas nos quedaría el siguiente conjunto de reglas (muestro la salida del comando iptables-save):

Así es como vamos a dejar las reglas del cortafuegos al inicio (también podríamos conservar las existentes e insertar nuestra cadena delante de las existentes). Sobre la marcha podremos ir añadiendo las ips aceptadas antes del drop final de la cadena y puede que incluyamos la opción de insertar nuestrar reglas sin eliminar las existentes.

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.

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.

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.

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.

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.

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.

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.

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!

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.