Mañana viernes 4 de Mayo de 2012 daré una charla dentro del “I Congrés de Sociologia i Ciències Polítiques de València”, titulada “Democracia, tecnología y control”. Será en el salón de grados de la facultad de Ciencias Sociales. Aquí está el horario de las ponencias.

En la charla utilizaré una presentación sencilla. He creado una versión ampliada con Prezi que supongo que resultará de más utilidad. Aquí la tenéis. Es mi primera presentación utilizando esa aplicación y no he tenido demasiado tiempo para preparala, así que ser indulgentes.

Cuando tenga el video disponible intentaré que esté disponible a través de esta misma entrada.

Las políticas que hemos definido en el post anterior se tienen que llevar a cabo mediante iptables. No voy a entrar en detalle sobre su funcionamiento; para los interesados recomiendo el manual de iptables y el manual de filtrado de paquetes de Joan Fuster (Monzó).

Dado que tenía montado un router con varios servicios en casa, ya conocía iptables y había trabajado con ella. Sin embargo, al intentar ampliar el número de redes, me he dado cuenta de que mis conocimientos eran demasiado superficiales, y que estaba dedicándome más al ensayo y al error que a una aproximación razonada del problema (por decirlo claro: que había estado varias tardes probando sin llegar a ningún sitio, y andaba bastante perdido).  Esto me llevó a plantearme el funcionamiento de iptables, ya que no sabía a ciencia cierta por dónde pasaban los paquetes, y dónde tenía que “meter mano” para conseguir lo que andaba buscando.

Como se ha dicho en mil sitios, iptables tiene tres tablas: FILTER, para el filtrado de paquetes; MANGLE, para realizar marcaje en los paquetes de comunicaciones, y NAT, para realizar… pues eso, NAT.Cada una de estas tablas tiene unas cadenas predefinidas. Una cadena es algo que se ejecuta cuando el paquete llega a un sitio determinado. Se llama cadena porque puede contener varias reglas, que se ejecutarán una después de otra, y que son las que podemos definir.

¿Cuándo se ejecutan cada una de esas cadenas? Eso es lo que no tenía claro, de manera que lo primero fue buscar un esquema de funcionamiento que relacionase las tres tablas y cada una de sus cadenas. Lo encontré en el manual de iptables, y lo reproduzco aquí en un formato un poco más aseado que de donde lo copié:

En verde he marcado la tabla FILTER, en amarillo la tabla NAT y en azul la tabla MANGLE. El texto en las elipses es el nombre de la cadena que se ejecuta. De este modo, podemos ver que se ejecuta antes la cadena FORWARD de la tabla mangle que la cadena FORWARD de la tabla filter. Este orden es importante a la hora de diseñar las reglas que utilizaremos.

En iptables se pueden crear cadenas definidas por el usuario, que se lanzarían desde las cadenas predefinidas, pero es algo que no voy a utilizar y no he entrado a mirarlo en detalle.

Ahora, con esta información, ya tengo más claro cómo hay que transformar las políticas de acceso en reglas de iptables. Por regla general, para las políticas de acceso utilizaremos la tabla FILTER. Para dar acceso a internet desde una sola IP utilizaremos la tabla NAT, y la tabla MANGLE va a ser útil para las políticas de QoS, con las que espero meterme algún día.

En fin, sigamos.

Una vez hecho el mapa de la red, tengo que decidir qué quiero. Este es un mapa simplificado de lo que rodea al router:

Y esto es lo que quiero que pase en la red:

• No se admitirán conexiones entrantes al router, excepto:
  • A algunos puertos determinados, desde Internet
  • Desde casa se podrá acceder a cualquier puerto del router
• No se permitirá tráfico desde redlibre a la red de casa, ni al router
• Desde casa y desde redlibre se tendrá acceso a internet

Supongo que sobre la marcha tendré que corregir alguna cosa, y hay algunos detalles que no he incluido por simplificar. Ahora, con iptables, tengo que poner en marcha esas políticas.

Tengo pendiente desde hace un tiempo montar un nodo de Valenciawireless para dar servicio a la zona donde vivo. Hice una prueba rápida, dio problemas, y hasta ahora no me había podido poner en serio con el asunto.

Para montar el nodo necesito dos cosas: configurar la red, y configurar políticas de QoS (calidad de servicio) para priorizar el ancho de banda de mi tráfico particular; no quiero que porque haya mucha gente conectada al nodo empeore la conexión a internet de mi ordenador. De QoS hablaré en otro post… cuando tenga las cosas más claras.

Ahora estoy en el proceso de configurar la red. Lo primero ha sido hacer un esquema de cómo tengo las conexiones en casa, por aclararme las ideas. Ha resultado ser algo así:

Las máquinas que aparecen en el gráfico son estas:

• mosca: el portatil que hace de servidor, router, firewall y emule-tutiplén.
• mantra: mi portatil
• brondo: mi ordenador de sobremesa (que algún día ira a la basura, por lo poco que lo utilizo)
• petuneta: el ordenador de mi novia

La duda que tengo es si funcionará bien el esquema que da a servicio a RedLibre (en la parte superior derecha del gráfico) El router no traslada tráfico a ningún sitio, podréis ver que no está conectado a nada. Su función es proporcionar conexión de tipo infraestructura a los clientes de Redlibre, y hacer de servidor dhcp, diciendole a los clientes que la puerta de enlace por defecto es la tarjeta wifi del servidor que tengo en casa. Hasta donde sé eso debería funcionar, pero me da mal fario.

Intentaré echarle un vistazo la semana que viene a ver si consigo tener conexión y salida a internet desde la red de los invitados. Cuando tenga eso listo, tendré que conectar el sistema a Redlibre. Y después, preparar QoS que creo que va a ser lo más complicado: me va a tocar parchear el núcleo, y eso es algo nuevo para mi.

A ver si consigo tener todo listo para primavera, que en el parque de debajo de casa se empieza a estar bien.

Al revisar el correo local del servidor que tengo instalado en casa (Ubuntu 8.04 server, migrado de la siete y pico) me he dado cuenta de que tenía un puñado de correos de crontab avisandome de que /var/log/messages había desaparecido. Puesto a revisarlo me he dado cuenta de que además de ese fichero, existen otros bastante importantes como auth.log. Revisandolos, he descubierto que hay algunos cuantos listos intentando acceder a mi servidor ssh, probando con usuarios y contraseñas al azar.

No creo que hubiese pasado nada (no tengo un password muy estándar) pero más vale prevenir: tras bucear un poco, he encontrado la utilidad denyhosts. Esta aplicación revisa los logs y bloquea los ordenadores que acceden de forma errónea, tras un número determinado de intentos. Estaba dispuesto a pegarme un poco con algún script de shell, ya que había visto hace un tiempo una solución hecha “a mano” para lo mismo, así que me ha sorprendido gratamente el encontrarla, ya que hacer justo lo que quería.

Instalarla no puede ser más fácil, sólo hay que seguir dos pasos:

1. Instalar denyhosts (apt-get denyhosts)
2. Editar /etc/ denyhosts.conf . Es muy sencillo y autoexplicativo, y en principio no hay que tocar nada. Yo lo he hecho porque me conozco, así que he rebajado un poco la segurida por si me empeño en meter la pata a la hora de conectarme.

Al rato, ya tenía mi primer informe de denyhost donde me indicaba los atacantes bloqueados de la noche anterior. Parece que la cosa va bastante bien, a ver si así me ahorro algún susto:

From: DenyHosts <nobody@localhost>
To: root@localhost
Subject: DenyHosts Report
Added the following hosts to /etc/hosts.deny:
222.215.119.33 (unknown)
87.238.89.132 (132.net-2.pl-medusa.net)
219.159.186.81 (unknown)
125.46.36.89 (hn.kd.ny.adsl)
117.120.8.46 (unknown)
60.248.36.227 (mail.liveabc.com)

Hace un par de días llamé a un amigo y lo encontré trabajando con el ordenador intentando montar una web. No es informático: trabaja de guía turístico y quería montar una página para ofrecer sus servicios. Había contratado alojamiento, un dominio, y estaba empezando a editar un index.html para la página inicial. También había “adquirido” una copia de Dreamweaver y pensaba montar su sitio web a mano, con esa herramienta.

Creo que le llamé justo a tiempo, porque montar una web así hoy en día es una locura. Merece la pena si quieres algo muy especial y tienes dinero para que te lo haga una empresa especializada, pero para un negocio personal el trabajo es tremendo, el mantenimiento va a ser horrible, y las funcionalidades mínimas. Le recomendé que instalase un CMS y se dedicase a cambiar el diseño y a generar contenido. Como no tiene ni idea de lo que es un CMS, quedé en que se lo explicaría en un correo y le mandaría algunos ejemplos de lo que se podía hacer. Como ya tengo página personal (montada también sobre un CMS) voy a aprovechar para escribirlo aquí y así lo tengo listo para cuando algún otro amigo decida meterse en estos líos.

Qué es un gestor de contenidos

Lo primero es contar lo que es un gestor de contenidos. En la wikipedia hay algo de información, que yo resumiría en lo siguiente: al final, en Internet todo el mundo quiere hacer lo mismo: montar una tienda online, crear un blog, publicar un periódico… Lo que sucedía al principio es que cada uno preparaba su aplicación específica. Si el tendero del barrio quería tener una página web, contrataba a una empresa que se la diseñaba y programaba (y que le costaba un dineral). Si alguien quería una página personal, la editaba a mano e iba incluyendo cosas. El problema de esto es que se repetía mucho trabajo, ya que, aunque duela reconocerlo, todas las tiendas en internet son parecidas y todas las páginas personales, blogs, etcétera tienen la misma funcionalidad.

Como esto era así, en un momento dado alguien tuvo una idea genial: preparar un programa que se pudiese reutilizar para diferentes páginas web. Permitía configurarlo (cambiar menús, añadir artículos, ocultar/mostrar diferentes secciones…) y cambiar el diseño (colores, tipos de letra, etc…). Si alguien quería crear una página web, no tenía que programar nada: sólo instalar el gestor de contenidos y dedicarse a editar los contenidos (añadir artículos e información) y a cambiar el diseño para dejarlo a su gusto. Utilizando un mismo programa, se podían crear dos webs totalmente diferentes y personalizadas. Por ejemplo,  esta web y esta otra utilizan el mismo programa base.

Esto sería, simplificándolo un poco, un gestor de contenidos o CMS.

Utilizar un gestor de contenidos a la hora de montar una página web en vez de programarla desde cero nos da las siguientes ventajas:

• Tiene mucha funcionalidad incluida desde el principio, sin tener que programar nada.
• Se administra desde Internet: no hace falta ningún programa especial (ni comprarlo, ni instalarlo) y lo puedes hacer desde cualquier ordenador con conexión.
• Es muy sencillo añadir y modificar contenido sin romper nada.
• Es estándar, por lo que puedes encontrar mucha información en Internet (foros, tutoriales) y en un momento dado, es más sencillo encontrar a alguien que te eche una mano
• Se puede configurar para que el diseño sea propio (menús, secciones, etc.) . Además, mantiene la coherencia de diseño en todo el sitio web.
• Son ampliables. Si necesitas una funcionalidad que no viene “de serie”, se puede añadir mediante módulos o plugins. Hoy en día hay plugins para todo en los principales CMS: desde foros, a tiendas virtuales o galerías de fotos y vídeo.

Lo malo… bueno, lo malo que se me ocurre es lo siguiente:

• Son difíciles de personalizar más allá de los límites que proporciona el gestor de contenidos: por ejemplo, si un gestor de contenidos no permite configurar la posición de los menús, y queremos que en nuestra página. Si nos emperramos en hacer algo para lo que el gestor de contenidos no está preparado, podemos volvernos locos.
• Al ser aplicaciones estándar, están más expuestas a fallos de seguridad: si alguien descubre un fallo en la aplicación, lo podrá usar en muchos sitios web.  Aunque también es verdad que esas aplicaciones suelen ser más seguras porque se depuran mucho más los errores.

Para montar la página de un pequeño negocio, o una página personal, las ventajas de un CMS superan con creces a los inconvenientes.

Qué gestor de contenidos utilizar

Lo primero, hay que saber qué gestores de contenidos hay.

Para sitios web de propósito general (sería el caso de mi amigo):

• Joomla
• Drupal
• Textpattern

Para blogs y páginas de publicaciones:

• WordPress (el CMS de esta página)  
• Movable type

Los motivos para elegir uno u otro pueden ser muy técnicos (rendimiento, extensiones disponibles, posibilidad de gestionar varios sitios web, etcétera). No he hecho un análisis a fondo de los diferentes gestores, pero he probado Joomla y la verdad es que me siento muy cómodo con él. He oído comentarios sobre que Drupal está mejor hecho “por dentro” (pero también que era mucho más complicado de utilizar al principio) y que TextPattern es mucho más elegante y limpio en el código que genera. A pesar de eso, mi recomendación personal para mi amigo sería utilizar Joomla: es razonablemente potente y sencillo de utilizar, y para lo que el quiere, tiene de sobra. OJO: la versión 1.0 da problemas en alojamientos compartidos, es importante utilizar la versión 1.5

Cómo utilizar un gestor de contenidos

Es lo más sencillo del mundo: instalar el gestor de contenidos, personalizarlo y añadir contenido a la web.

Para instalar un gestor de contenidos necesitamos que el proveedor de alojamiento nos proporcione dos cosas: soporte para PHP y soporte para base de datos; estas dos cosas las ofrecen prácticamente todas las empresas. La instalación suele consistir en dejar caer unos ficheros en el servidor, preparar una base de datos (que suele ser mySQL) y acceder al sitio web donde se muestra una pantalla de configuración que nos pide los datos adicionales y nos va guiando hasta que tenemos todo listo. Este proceso no suele costar más de diez minutos, aunque si es la primera vez, puede que necesites dos o tres horas para dejarlo todo en su sitio.

Personalizarlo es algo más complicado, ya que en este paso es donde vamos a definir el aspecto final que tendrá la página web. Lo bueno es que podremos dedicarle el esfuerzo que queramos. Recién instalado el gestor de contenidos ya tendremos una página web funcional. A partir de ahí, podemos descargar e instalar sin mucho esfuerzo alguna plantilla que mejorará bastante el aspecto (aquí, por ejemplo, hay un buen directorio de plantillas joomla).  Luego, se puede modificar esa plantilla o crear una nueva para que nuestra página se muestre como queramos.

Por último, lo que más faena tiene, es dotar a la web de contenido: escribir artículos, poner cosas interestantes, hacerla atractiva para la gente que queramos que la visite. Pero eso es algo que tenemos que hacer de todas formas, usemos el gestor de contenidos o no.

Todo esto, que suena muy complicado, no lo es tanto. Lo mejor es probar a instalarlo, jugar un poco con el gestor y acostumbrarse al manejo. Joomla Spanish es un buen sitio para empezar.También es buena idea leer algún tutorial como este. Una forma sencilla de probar joomla es instalarlo en el propio ordenador, pero quizá nos complique más la vida (hay que instalar un servidor web, un servidor de bases de datos, php…) así que creo que es más sencillo probar directamente en el servidor.

A partir de aquí, como casi todo lo de informática, hay que empezar a probar, jugar con el gestor de contenidos y empezar a experimentar y a equivocarse. Siempre vamos a perder menos tiempo que haciendo la web desde cero.

A estas alturas no voy a ponerme a explicar lo que es OpenId, sólo citar que:

OpenID es un sistema de identificación digital descentralizado, con el que un usuario puede identificarse en una página web a través de una URL (o un XRI en la versión actual) y puede ser verificado por cualquier servidor que soporte el protocolo.

(Aquí y aquí podéis encontrar más información)

Quería disponer de un servidor OpenId propio, ya que no me gusta depender de otros servicios para gestionar mi propia identidad. Tras estudiar las opciones disponibles, al final me decanté por phpMyID. Se trata de dos scripts en PHP que se configuran con relativa facilidad: basta con dejarlos caer en el servidor, editar un par de parámetros y generar la contraseña. La parte más difícil viene si al intentar autentificarnos muestra un error “Missing expected authorization header”. Esto es debido a que PHP no puede leer las cabeceras HTTP, y para solucionarlo sólo tenemos que subir el archivo .htaccess que proporciona la distribución de phpMyID y en el que previamente habremos descomentado una de las tres opciones disponibles (yo probé con la primera).

Con estos pasos tenemos un servidor OpenId monousuario funcionando en cinco minutos.

Una vez configurado el script, la dirección para autentificarnos es http://nuestrositioweb/MyID.config.php. Esto queda muy feo, ya que si lo utilizamos, por ejemplo, para identificarnos a la hora de escribir un comentario en un blog,  cuando los lectores pulsen sobre nuestro avatar o nuestro nombre irán a una página bastante simple que dice “This is an OpenID server endpoint”, sin mucha más información. Para corregir esto se utiliza la delegación: en una página determinada, que es la que queremos que visiten los usuarios, se añaden dos tags html que indican dónde está realmente el servidor OpenId que nos autentifica.

Los tags son <link rel=”openid.server”…/> y <link rel=”openid.delegate”…/> Podría haberlos añadido a mano, pero como utilizo WordPress en esta página, me pareció que la solución más limpia era instalar un plugin que realizase esa delegación. He utilizado OpenID Delegate WordPress Plugin, también muy sencillo de instalar (dejar caer el archivo) y de configurar (poner en los dos primeros campos que aparecen en su sección de administración la dirección del script phpMyID).

Con esto he conseguido que la dirección de mi página personal me sirva para autentificarme con OpenID. Rápido, fachile e divertente. Gracias Señor Siege.

Tras unas semanas de prueba he llegado a la conclusión de que la velocidad de subida que tengo en mi casa es insuficiente. Las veces que he accedido yo para comprobar la velocidad o hacer algún retoque en la plantilla me ha resultado exasperante, y eso que hay que tener en cuenta que no estaba conectado el emule o bittorrent (para compartir contenido sin derechos de autor, desde luego ) ni está operativo del todo el nodo de redlibre: cuando lo esté, con la VPN y algún cliente conectado, puede resultar muy incomodo acceder a mi web.

Dado que quiero usar esta dirección para temas profesionales, he decidido pagar tres euros al mes y quitarme problemas. He contratado alojamiento en dhapcenter, que resulta muy barato y tiene un panel Plesk con el que se manejan los dominios con bastante facilidad. Monté en su día una web profesional, Psiconsultaonline (otro día hablaré de ella) y salvo algún que otro problemilla por ser alojamiento compartido quedé muy contento. Además, la empresa está en Paterna, cerca de donde vivo, así que puedo acercarme en persona a cantarle las cuarenta a alguien si la cosa se pone fea. Otra ventaja es que en caso de que una catástrofe natural afecte al servidor (terremoto, huracán, impacto de meteorito) no me importará: tendré cosas más importantes de las que preocuparme.

El cambio ha tardado un poco porque en Agosto las cosas van muy despacio y dar de alta el dominio ha costado casi una semana, pero por fin estoy por allí.

Ahora a seguir retocando, que todavía queda algún “Komentarien” y alguna “Kategorien” que clama al cielo. No sé si lo haré a las bravas o utilizaré el método bueno del gettext. Eso se queda también para otro post.

Llega un momento en la vida de todo informático en el que hay que tener una página personal.

Hasta ahora me había resistido pero quiero empezar a compartir algunos proyectos, chorradas informáticas o no informáticas a las que me dedico en casa, inquietudes varias, y se hacía necesario tener un sitio que ha resultado ser este. Está todo un poco patas arriba, pero ya iré dejando todo ordenado.

Por ahora estoy en mi propio servidor, en mi casa, así que no esperéis mucha velocidad. Pero qué mejor sitio que mi casa para hablar de mi.

Pasar, tomaros un cafetito y ya os iré contando.