Planeta RedIRIS

La mayoría de las veces los cortafuegos se ponen en modo «activo», empleándose com router de interconexión de las diversas redes,  algo diferente a los cortafuegos de «aplicación» o pasarela como  FWTK o en su versión comercial (Gauntlet), que diferenciaban bien el tráfico, después se paso a utilizar los cortafuegos como routers y de ahí a pensar que las iptables son un firewall…

Ahora con los cortafuegos de «capa 7» (¿ cuando ha tenido TCP/IP 7 capas?) , se pueden poner muchas veces en «modo  trasparente» y esto hace que en muchas situaciones donde antes «no pasaba nada» ahora no funcione el tráfico , como puede  verse en el siguiente en el que un equipo dentro de una misma red hacía de router para una red interna distinta de la «ruta por defecto» y que no presentaba «problemas» hasta que se incluyo un cortafuegos de «nueva generación» transparente y en medio..

En el siguiente esquema se muestra como estaban situados los equipos:

red_interna

En principio, no hay problemas hay un router y por defecto y el tráfico por defecto va al router y este llega va y vuelve sin problemas, el cortafuegos inspecciona el tráfico y no se ven problemas.

tráfico a internet

El tráfico de las máquinas pasa por el cortafuegos con destino al router , este envía los paquetes IP a internet y la vuelta viene por el mismo sitio.

Para acceder a la red interna se tenían muchas opciones, pero lo «más cómodo» fue que el router principal tuviera una ruta definida de forma estática a esta red interna empleando un equipo interno que conectaba con la otra red, de forma que el tráfico a la red interna se enrutara por el equipo interno que hacía de router:

tráfico asimétrico

Ahora bien esto creaba un tráfico asimétrico los paquetes «de ida» de las estaciones de trabajo se dirigían al router (es su router por defecto), de ahí el router las reenviaba al equipo en la misma red interna que hacía routing y de ahí a la red interna, ahora bien el router interno no empleaba el router principal para reenviar los paquetes IP de vuelta, ya que al estar las máquinas en la misma red se enviaban directamente.

Al poner el cortafuegos en modo transparente este solamente veía los paquetes de ida (dos veces eso sí), por lo que por ejemplo para permitir el tráfico HTTP/HTTPS permitía el primer paquete (SIN) , que inspeccionaba, pero después al no tener el paquete de SIN/ACK , los siguientes paquetes no los enviaba al estar esperando este SIN/ACK.

En los equipos la conexión TCP/IP se establecía (ya que llegaba el SIN/ACK) pero después al bloquear el tráfico el cortafuegos no se podían enviar datos, ¿la forma final para depurar y comprobar que estaba pasando esto ?, emplear en el equipo de usuario una captura de paquetes y ver que la direcciones MAC que se empleaban en la comunicación no eran las que tenían que ser, ya que aunque los paquetes se enviaban al router principal era el router interno el que enviaba después a nivel interno el trafico.

trafico_macs

Por defecto tcpdump no muestra la información de la direcciones MAC, por lo que hay que indicarlo con la opción -e y después comprobar en la tabla arp (arp -an ) a que equipo corresponde cada una de las MAC.

Se pueden establecer varias soluciones, que por diversos motivos se fueron descartando:

Poner rutas más especificas en los equipos de forma que no utilizarán el router principal para acceder a esta red sino que fueran directamente a la red interna, sin embargo los equipos se configuran por DHCPD y resulta que la opción de configurar varias rutas (RFC-3442 Classless Static Routes) no funciona en algunas de las estaciones de trabajo.

Forzar en el router interno a que el tráfico con destino la red de usuarios sea enviado al router principal, esto obligaría a emplear enrutamiento por fuente en este router (el routing normal suele ser por «destino») y configurar el router principal para que cuando le llegue este tráfico no se queje mucho (algo raro que una máquina de la misma red envíe trafico a traves de el en vez de directamente.

Al final se decidió establecer una red de conexión «punto a punto» (un /30) entre los dos routers, de forma que el router secundario no estuviera en la misma red que los equipos de usuarios, estableciendo incluso una VLAN separada, de esta forma el tráfico al final pase por el cortafuegos siempre y no haya problemas de conexión.

tráfico simétrico

Al final el tráfico pasa dos veces por el cortafuegos (qué se le va a hacer ), pero es un tráfico simétrico y el cortafuegos puede inspeccionarlo , comprobar que todo va correcto, no solo a nivel IP sino a nivel de aplicación y proteger de forma adecuada a los usuarios.

En el articulo  de la publicación de Web Security de la ACM Paul Vixie hace una defensa del uso de páginas estáticas a la hora de proteger los servidores WWW ante las distintas amenazas existentes tanto ataques de denegación de servicio como intrusiones , modificación de páginas WWW , etc lo que nos lleva a comentar el funcionamiento de Webber.

Desde hace mucho tiempo  (aproximadamente 1996 ) en RedIRIS se emplea un sistema para la generación de los contenidos en las páginas WWW llamado webber,  (sin referencia ninguna al corredor de formula ;-), que aunque odiado por muchos sigue todavía se mantiene, webber hace las funciones de gestor de contenidos (CMS como lo suelen llamar en ingles) generando las páginas HTML de forma uniforme en base a una plantilla y de forma estática.

Webber ha pasado por varios cambios inicialmente era un simple programa en Perl que en base a una plantilla fija y un texto HTML sin cabeceras (el contenido de la página), generaba una página HTML con una apariencia definida, cabecera, pie de páginas, etc. la tipica página de «Hola Mundo» en webber era más o menos:

#title= Hola mundo
#athor= anonimo
#wbbIn= 
Hola mundo<p>
¿Como estas ?

Donde los valores con corchete «#» indicaban el nombre de una variable  (que podía tener varias lineas) que después se rellenaba en la plantilla. Había varias variables definidas, title para el titulo, wbbIn para el contenido la página,  description para la descripción, keyword para las palabras clave , etc.   Además y para facilitar se tenían ficheros de plantilla para incluir valores que iban a ser comunes dentro de un subdirectorio , como «author» y se tenía «herencia», ya que las plantillas se procesaban por todo el arbor de directorios desde la raíz del código.

En una primera evolución se paso a separar las funciones en diversos procesadores, de forma que se pudieran tener varias plantillas (el nombre de la plantilla a utilizar era al final otra variable «webber» ), se pudieran incluir tablas de forma rápida, colocar menus,  separar el código fuente de las páginas finales, etc. Al final muchas funciones que la mayoría de las veces utilizamos pocas veces.

Siguiendo con la evolución y como al final la utilización del «vi» en sus diversas versiones era cada vez más compleja (entre otras cosas por la aparición de las distintas codificaciones, ISO-8859, UTF-8, etc) y porque las páginas WWW no solas las editaban usuarios «expertos» al final se creo una entorno de edición «web» para al menos poder editar las páginas WWW desde el servidor y después utilizar webber para generar el contenido en base a los ficheros estáticos.

Así el webber ha ido evolucionando dentro de RedIRIS tiene hasta página web en el servidor, pero su uso fuera de RedIRIS ha sido muy escaso , seguramente por la complejidad de montar unas páginas «desde cero» y el abuso de la terminología exotérica que tiene la documentación y es que como siempre lo documentar y actualizar las cosas nos da algo de pereza.

Aunque Webber ha sido código libre desde el principio, la gestión del código siempre ha sido algo complicada y por eso   a finales del 2014 decidimos migrar el repositorio de código de Webber a github de forma que el código de webber este disponible en esta herramienta.

Coincidiendo con la publicación de esta entrada en el GitHub esta la versión 3.0 preliminar del webber, que permite una mayor flexibilidad a la hora de definir la entrada y salida y elimina algunos procesadores antiguos no utilizados, al ser una versión preliminar algunas cosas no están pulidas del todo , aunque es bastante funcional.

Un pequeño ejemplo de funcionamiento:

Descargar el fichero de github en un directorio y descomprimirlo ,

Editar el fichero webber.wbb  y cambiar la entrada «wbbRoot»  , por ejemplo,

#wbbRoot=/home/usuario/webber-master

Grabar el fichero.

El fichero de configuración será ahora mismo mas o menos.

##where the webber standard root start
 #wbbRoot=/XXXX/XXXX/XXXX/webber-master/
 ## Where "standard" processors are located
 #wbbProcLib= $var(wbbRoot)/proc
 ## Version
 ## Template dir name
 #wbbTemplateName= wbbdir.cfg
 #wbbFileNameRegExp = ^(.+).wbb$
 #wbbFileLangRegExp = ^.+(es|en|ca|gl).wbb$
 # Default extension
 #wbbExtension = .html
 #wbbDebugFile= $var(wbbRoot)debug.txt
 ##wbbDebugFile = ./debug.txt
 #wbbDebug = 10
 #wbbRun=File::SetTarget File::ReadVars wbbPre wbbProc wbbPost File::WriteVar
 #File.WriteVar= wbbOut
 #wbbPre=
 #wbbProc= Webbo::webbo
 #wbbPost=
 #webbo.src=file:$var(wbbRoot)src/test.webbo
 #webbo.dst=wbbOut
 #wbbSourceRoot= $var(wbbRoot)src
 #wbbTargetRoot= $var(wbbRoot)html
 #wbbMakedir=1

Las variables tienen el siguiente significado:

1. wbbRoot : Base donde se encuentra el código de webber
2. wbbProc: Donde se encuentran los procesadores webber
3. wbbDebugFile : Path al fichero de debug
4. wbbDebug : Nivel de depuración
5. wbbTemplateName Fichero de «plantilla» utilizado para definir variables que afecten a todos los ficheros que haya en un directorio (y subdirectorios de el)
   wbbFileNameRegExp = Expresión regular para idenfitifcar los ficheros de fuentes webber
   wbbFileLangRegExp = Expresion regular para idenficar los ficheros de lenguaje
   wbbExtension = Extensión que tendran los ficheros destino
6. wbbSourceRoot= Base donde se encuentran los fuentes webber
   wbbTargetRoot= Base a partir de donde se escriben los ficheros webber
   wbbMakedir Fuerza la creacion de directorios si no existen
7. wbbRun: Listado de procesadores a ejecutar ya tiene  definido una serie de procesadores para tener el funcionamiento de webber 1.X por defecto,  los procesadores que se ejecutan son:
   • File::SetTarget : Define en base una serie de variables cual es el fichero que se va a escribir
   • File::ReadVars: Lee un fichero en formato webber y define las variables de forma apropiada
   • wbbPre , wbbProc , wbbPost : listas de procesadores a ejecutar, con compatibilidad con webber 1.X
   • File::WriteVar : Escribe en el fichero definido en la variable wbbTargetFile el contenido de una variable webber
   • De todos las tres colas de procesadores solo wbbProc contiene un procesador y es el Webbo
     • wbbProc = Webbo , Webbo es un procesador que reemplaza nombres de variables webber por su valor en un fichero / variable (apuntado en #webbo.src ) dejando el contenido final en webbo.dst , es utilizado a la hora tener una plantilla (ver el fichero src/(test.webbo) que después es rellenada, ahí se definen dos variables wbbIn y title
     • webbo.dst= wbbOut
     • webbo.src= file:$var(wbbRoot)src/test.webbo

Una vez modificada la variable wbbRoot para que apunte se puede hacer:

perl ./webber --config ./webber.wbb --help para ver el fichero de ayuda

con

perl ./webber --config ./webber.wbb --list-proc se puede obtener un listado de los procesadores instalados

y finalmente con:

perl ./webber --config ./webber.wbb src/* se procesan los dos ficheros ".wbb" que hay en el directorio src/ y se generan en el directorio html/ los ficheros "destinos.

En próximas entradas seguiremos detallando el uso de webber para la creación de páginas más complejas.