Aquellos de vosotros que lleváis más tiempo visitando mi blog, os habréis dado cuenta de que he cambiado el software con el que gestiono mi galería de fotografías. Anteriormente usaba Gallery2 por su integración con WordPress mediante el plugin WPG2 (para el que desarrollé una mejora). Pero si bién era una solución válida, resultaba demasiado compleja. Era como matar moscas a cañonazos. Sólo necesitaba una mínima parte de las características de Gallery2.

Por eso, un día empecé a evaluar alternativas que se ajustaran mejor a mis necesidades. Las únicas características que me interesaban eran que pudiera organizar las fotografías en álbumes, que se pudiera mostrar los datos EXIF de las fotografías, poder etiquetarlas, valorarlas y comentarlas, que se integrara con WordPress y que fuera una herramienta libre. Finalmente encontré Zenphoto, que cumple con todas esas necesidades excepto la integración con WordPress. En su web lo definen como:

Zenphoto is an answer to lots of calls for an online gallery solution that just makes sense. After years of bloated software that does everything and your dishes, zenphoto just shows your photos, simply. It’s got all the functionality and “features” you need, and nothing you don’t. Where the old guys put in a bunch of modules and junk, we put a lot of thought. We hope you agree with our philosopy: simpler is better. Don’t get us wrong though –zenphoto really does have everything you need for your online gallery, and you’ll even stare in awe at some of the innovative innovations we innovated upon.

Con el plugin ZenphotoPress para WordPress conseguí poder añadir fotos de la galería en los posts de forma simple. Pero integrar la apariencia me lo tuve que currar yo, usando como guía este post de Steffen Rusitschka. Pero con ese método Google no indexaba las páginas de la galería, aunque se visualizaban correctamente, porque todas devolvían un status 404. Además, compartían el título (tag <title> del HTML) haciéndolo muy poco Search Engine Friendly. Para solucionarlo tuve que modificar un poco el código de Steffen. Este es el index.php de mi theme integrado con el WordPress:

<?php if (!defined('WEBPATH')) die(); normalizeColumns(3, 6); ?>
<?php require($_SERVER['DOCUMENT_ROOT'].'/wp-blog-header.php'); ?>
<?php
// set the HTTP status
status_header('200');
 
// add the zen headers to the wordpress header
function zentitle() {
  echo '&raquo; '.strip_tags(getGalleryTitle());
}
function addzen() {
  global $_zp_themeroot;
  echo '<link rel="stylesheet" type="text/css" media="screen, projection" href="'.$_zp_themeroot.'/css/master.css" />';
  zenJavascript();
  printRSSHeaderLink('Gallery','Gallery RSS');
}
add_action('wp_head', 'addzen');
add_action('wp_title', 'zentitle');
?>
<?php get_header(); ?>
 
<div class="index">
  <!-- Código original de Zenphoto -->
</div>
 
<?php get_footer(); ?>

Lo más extraño es que yo tengo las bases de datos del blog y de la galería separadas pero no he necesitado hacer lo que comenta Steffen de conectarnos a una base de datos y luego a la otra. Por eso, si comparáis mi trozo de códico con el de Steffen veréis que falta esa parte. Lo siguiente será integrar el login de las dos aplicaciones, para lo que he visto que hay plugins, pero de momento no lo he mirado.

Como las URL de los álbumes han cambiado, también he añadido reglas de redirección en el .htaccess para no perder los enlaces que pudiera haber desde otras páginas.

Al final he conseguido dejarlo bastante bien integrado y estoy muy contento, tanto del resultado como de la aplicación en sí. Tiene justo lo que necesito. Ni más, ni menos.

La aparición a mediados de 1998 de los VirtualHosts basados en nombre en la versión 1.3 del servidor web de Apache significó un cambio importante en el mundo de los servidores web ya que permitía configurar webs en diferentes dominios, todos ellos compartiendo la misma dirección IP. Tampoco hay que olvidar que esa mejora fue posible gracias a que los navegadores (por aquel entonces disponíamos de Netscape Communicator 4.5 e Internet Explorer 4.0 [1]) implementaron la versión 1.1 del protocolo HTTP, según la cual el navegador debe enviar el nombre del dominio al que se están conectando en la cabecera Host, usada por los servidores web para discriminar que a VirtualHost deben enviar la petición.

Desgraciadamente, las webs seguras nunca han podido beneficiarse de esta mejora por la forma en que funciona el protocolo HTTPS (HTTP sobre SSL). La cabecera Host que permite al servidor discernir el host virtual al que va dirigida la petición del usuario está a nivel HTTP, debajo del cual tenemos SSL y su negociación. En esa negociación es cuando el servidor envía al cliente su certificado X.509 y el navegador comprueba la validez del certificado comparando el campo CN del certificado con el nombre del dominio al que se está conectando. Por tanto, el servidor debe enviar el certificado correcto, y por tanto del host virtual correcto, al navegador antes que este le pueda indicar mediante la cabecera Host el dominio al que se quiere conectar. La única solución es usar VirtualHosts basados en dirección IP.

Sin embargo, si los diferentes dominios que tenemos en el servidor son subdominios que comparten el second-level domain, o SLD, podemos conseguir que todos ellos dispongan de web segura usando una única dirección IP. Por ejemplo www.example.com y mail.example.com tienen el SLD example.com en común.

Para conseguirlo, también es imprescindible el uso de un Wildcard SSL Certificate (he decidido no traducirlo porque ninguna de las tradicciones que se me han ocurrido me acababa de gustar), que es un certificado SSL en el que el nombre del dominio contiene un comodín. Por ejemplo: *.example.com. De esta manera, indicamos al navegador que este certificado es válido para cualquier subdominio de example.com. No voy a explicar como se generan los certificados SSL ya que buscando un poco por google se encuentran multitud de páginas al respecto. Si le vamos a dar un uso personal, podéis crear un self signed certificate. La única diferencia con los tutoriales que podáis encontrar es que como dominio introduciremos “*.<dominio>” (Por ejemplo: *.example.com).

Configuración del servidor web de Apache

Voy a suponer que en nuestro servidor tenemos configurado un servidor web Apache2 con varios host virtuales (www.example.com, mail.example.com y un servidor WebDAV para el Subversion en svn.example.com), y que el servidor sólo dispone de una dirección IP.

Lo primero que hay que hacer es poner el servidor web a escuchar en el puerto 443 (puerto estándar de HTTPS) y configurar un host virtual sobre ese puerto:

Listen 443
<VirtualHost *:443>
  ServerName *.example.com
  ErrorLog /var/log/apache2/https-error.log
 
  # Possible values include: debug, info, notice, warn, error, crit,
  # alert, emerg.
  LogLevel warn
 
  CustomLog /var/log/apache2/https-access.log combined
  ServerSignature Off
 
  SSLEngine On
  SSLCertificateFile /path/to/certs/example.com.pem
  SSLCertificateKeyFile /path/to/private-keys/example.com.key
</VirtualHost>

Con esto ya tenemos la capa SSL configurada. El certificado indicado en el parámetro SSLCertificateFile es el Widlcard SSL Certificate que hemos creado anteriormente. A partir de aquí, el “truco” está en el uso creativo del mod_proxy, que conseguiremos añadiendo la siguiente configuración dentro del hosts virtual que acabamos de crear:

  <Proxy *>
    Order deny,allow
    Allow from all
  </Proxy>
 
  # Proxy requests to ourselves preserving the Host header
  ProxyPass / http://localhost/
  ProxyPassReverse / http://localhost/
  ProxyPreserveHost on

Con esta configuración estamos reenviando todas las peticiones que nos lleguen a este host virtual por HTTPS hacia el propio servidor, pero cambiando el protocolo de HTTPS a HTTP. Es importante destacar la última línea, que le indica al servidor web que debe mantener la cabecera Host al hacerse la petición a sí mismo, gracias a la cual no tendrá ningún problema a la hora de determinar que página quiere ver el usuario.

Para que las aplicaciones web puedan distinguir si la petición que les llega a entrado por HTTP o HTTPS, configuraremos el host virtual para que añada la cabecera X_FORWARDED_PROTO a las peticiones que se hace a sí mismo:

  # Add the X_FORWARDED_PROTO=https to allow applications to identify
  # proxyed https connections
  RequestHeader set X_FORWARDED_PROTO https

Ya sólo queda un detalle, necesario únicamente si vamos a usar esta configuración para proteger un WebDAV. El problema de esta configuración con WebDAV viene a la hora de intentar hacer un ‘svn mv‘, por ejemplo. Este comando indica el destino en la cabecera HTTP Destination. Como el cliente se esta conectando a https://svn.example.com/repo/etc, la cabecera tendrá ese valor. Pero el host virtual que tiene la configuración de WebDAV sólo está configurado para HTTP por lo que espera que la cabecera Destination empiece por http://svn… Para solucionar la inconsistencia entre la cabecera esperada y la recibida echaremos mano del mod_rewrite:

  # Workarrounf for WebDAV Destination header
  RewriteEngine on
  RewriteCond %{HTTP:Destination} ^https://(.*)$
  RewriteRule . - [env=DESTINATION:http://%1,PT]
  RequestHeader set Destination %{DESTINATION}e env=DESTINATION

Resumen de la configuración

Una vez explicadas las diferentes partes de la configuración, os pongo toda la configuración tal cual se debe escribir en los ficheros de configuración del servidor web para que no haya problemas de “¿y esto donde va?, ¿dentro o fuera del virtualhost?” :

Listen 443
<VirtualHost *:443>
  ServerName *.example.com
  ErrorLog /var/log/apache2/https-error.log
 
  # Possible values include: debug, info, notice, warn, error, crit,
  # alert, emerg.
  LogLevel warn
 
  CustomLog /var/log/apache2/https-access.log combined
  ServerSignature Off
 
  SSLEngine On
  SSLCertificateFile /path/to/certs/example.com.pem
  SSLCertificateKeyFile /path/to/private-keys/example.com.key
 
  <Proxy *>
    Order deny,allow
    Allow from all
  </Proxy>
 
  # Workarrounf for WebDAV Destination header
  RewriteEngine on
  RewriteCond %{HTTP:Destination} ^https://(.*)$
  RewriteRule . - [env=DESTINATION:http://%1,PT]
  RequestHeader set Destination %{DESTINATION}e env=DESTINATION
 
  # Add the X_FORWARDED_PROTO=https to allow applications to identify
  # proxyed https connections
  RequestHeader set X_FORWARDED_PROTO https
 
  # Proxy requests to ourselves preserving the Host header
  ProxyPass / http://localhost/
  ProxyPassReverse / http://localhost/
  ProxyPreserveHost on
</VirtualHost>

Conclusiones

Personalmente veo está configuración como una solución válida para servidores personales en los que se suelen usar self signed certificates o de CAcert. Para pequeñas empresas (con unos pocos dominios) puede ser una solución, pero los Widlcard SSL Certificates de autoridades certificadoras comerciales (cuyos certificados raíz vienen en los navegadores) no son baratos. Dependiendo del hosting creo que saldría más barato contratar IPs adicionales para el servidor y certificados individuales que no usar el Widlcard SSL Certificate en un servidor con una sóla IP.

En empresas medianas o grandes, puede justificarse el uso de Widlcard SSL Certificates si tienen un gran número de subdominios que quieren asegurar ya que puede suponer un ahorro, pero no veo el motivo de tenerlo todo sobre una sóla dirección IP. Por tanto, no veo que la configuración aquí explicada sea aplicable en este tipo de empresas.

A mi, esta solución me está funcionando muy bien y de momento no he encontrado ningún problema.

Notas adicionales

[1] Para los nostálgicos, ¿os acordáis de la guerra de navegadores?

DomainKeys Identified Mail, o DKIM, es un sistema de autenticación que permite verificar que el correo realmente proviene de quien dice provenir. Como los spammers suelen falsificar los remitentes de los correos que mandan, también veremos como esa verificación nos puede servir como un método más para luchar contra el correo no deseado.

DKIM recuerda bastante al Sender Policy Framework, o SPF, cuya finalidad es que los servidores puedan verificar que el servidor que les está entregando un correo está autorizado a hacerlo. Es decir, si el servidor mx.example.org está intentando entregar un correo con remitente [email protected] a mi servidor, este usará SPF para verificar si mx.example.org está autorizado a gestionar el correo de ese dominio. La idea es buena pero, por la forma en que se hace, tiene problemas cuando hay redirecciones o forwards. Para más información, podéis leer la introducción a SPF del proyecto OpenSPF o el artículo de la Wikipedia [en inglés].

Quería introducir un poco SPF para poder compararlo con DKIM ya que ambos tienen finalidades similares y usan el sistema de DNS para publicar la información necesaria. Pero así como SPF publica en DNS qué servidores pueden o no enviar correo de un dominio, DKIM publica una clave pública que se usará para verificar que el correo se originó desde un servidor legítimo, evitando el problema de los forwards. Pero nos estamos avanzando un poco…

¿Cómo funciona?

Simplificando bastante: a la hora de enviar, el remitente firma el mensaje y añade esa firma al correo. Entonces, cualquiera de los servidores por los que pasa el correo, puede comprobar su autenticidad verificando la firma. Aunque cualquiera de los servidores puede, la comprobación normalmente se realiza en el servidor destinatario.

Profundizando algo más, DKIM se basa en sistemas muy usados y conocidos como son la criptografía asimétrica, las funciones de hash y, como ya habíamos anticipado, DNS. Para entender mejor su funcionamiento, vemos la infraestructura que hay que configurar para que pueda funcionar:

1. El administrador del dominio de correo debe generar un par de claves asímetricas.
2. Seguidamente, configurará la clave privada en sus servidores de correo, que la usaran para firmar los mensajes.
3. Finalmente, publica la clave pública como un registro TXT en la zona DNS de su dominio para que los servidores que quieran comprobar la autenticidad de los correos puedan obtenerla.

Ahora ya podemos ver el proceso con más detalle: el servidor remitente calcula el hash del correo teniendo en cuenta el cuerpo y algunas cabeceras, y cifra ese hash con la clave privada generando la firma que se añade al correo. Cuando un servidor quiera verificarlo, como necesitará la clave pública para hacerlo, consultará al sistema DNS para obtenerla y poder realizar la comprobación. Si el correo se originara desde un servidor ilegítimo, como no tendría la clave privada adecuada, la comprobación de la firma fallaría poniendo en evidencia al servidor como posible spammer o phisher.

Como la comprobación no se basa en quién nos está entregando el mensaje sino en quién lo originó, este esquema no sufre de los problemas de SPF con los forwards. Sin embargo, al estar basado en firma digital, tiene problemas con las modificaciones que pueda sufrir el correo durante su transmisión. Por ejemplo, si se añade un disclaimer después de que se haya firmado, la verificación fallará.

Para más información sobre DKIM os remito su web, donde encontrareis multitud de documentación, y, como nó, a la Wikipedia.

Como referencias, decir que tanto Yahoo! como Gmail son dos grandes ejemplos de ISPs que usan DKIM en sus servidores.

DKIM en SpamAssassin

Finalmente, veamos como podemos configurar SpamAssassin para sacar provecho de este sistema. Estoy dando por supuesto que usamos Debian Etch y que ya tenéis el MTA (Postfix o similar) y el SpamAssassin instalados y configurados. Sólo mostraré la configuración a realizar para que se empiecen a comprobar las firmas de DKIM. Desgraciadamente, la versión que viene con Etch no es del todo adecuada por lo que deberemos añadir el repositorio de backports a nuestro source.list. Una vez añadido, actualizaremos la lista de paquetes e instalaremos libmail-dkim-perl, con todas sus dependencias, desde backports:

  server:~# aptitude update
  server:~# aptitude -t etch-backports install libmail-dkim-perl

Ahora sólo falta habilitar el plugin Mail::SpamAssassin::Plugin::DKIM descomentando la correspondiente línea en el fichero /etc/spamassassin/v312.pre. Recordad reiniciar spamd, amavisd-new o el content-filter que uséis para que se aplique la nueva configuración.

Como ejemplo, veamos las cabeceras de un correo enviado desde gmail:

X-Spam-Status: No, score=-0.124 required=4.5 tests=[AWL=-0.185,
	BAYES_20=-0.74, DKIM_SIGNED=0.001, DKIM_VERIFIED=-0.001,
	DNS_FROM_SECURITYSAGE=0.001, HTML_MESSAGE=0.001, P0F_Unknown=0.8,
	SPF_PASS=-0.001]
...
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=gamma;
        h=domainkey-signature:received:received:message-id:date:from:to
         :subject:mime-version:content-type;
        bh=JvMz4j1uNftb2YwcCYFAjZF73T5HtaC0paeyk3KqFao=;
        b=s2/id2fqmQMef9gWIvn6jhs09lz9nnyOrwepQtQQdzd6Bj8iB/7b2G3PN+bLcOW0k1
         kTs7ew+y8P1rROBlA+T8CpsYirWL0gSp6YZidyhN2SHJVg9ZXQ7oWq6czAcqs/y3871n
         l4Wnm53EqPPNn4Tqos6ruDghAfyJ/deBxFY3Q=
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:to:subject:mime-version:content-type;
        b=U6s9wCp2Q5U7DC0WcQGJ6S6hNwTNmPUiklMd0RtMgB+pJzvP8T/NaqT43Q4QyaukPz
         ig4b3S0/QF3B6uOctVvYQE9YAlgbilx+QxthVzhtc9xvyfePgF63RoebvK28hNlL5VUn
         +0cdEBbEOqkPzo1d1j5XaDGDUV6W/0xHRZb2o=
Received: by 10.210.65.2 with SMTP id n2mr4808273eba.65.1224441206376;
        Sun, 19 Oct 2008 11:33:26 -0700 (PDT)
Received: by 10.210.113.2 with HTTP; Sun, 19 Oct 2008 11:33:26 -0700 (PDT)
Message-ID: <[email protected]>
Date: Sun, 19 Oct 2008 20:33:26 +0200
From: "Gmail user" <[email protected]>
To: [email protected]
Subject: DKIM test
MIME-Version: 1.0
Content-Type: multipart/alternative;

Como podéis ver, con la puntuación que le dá SpamAssassin por defecto no mejoramos la discriminación de spam: +0.001 por venir firmado que se compensa con -0.001 porque la firma es correcta. En la lista de correo de spamassassin-users podemos encontrar algunas sugerencias (y sus actualizaciones).

Conclusiones

DomainKeys Identified Mail es otro sistema pensado para verificar el origen del correo que, como el resto de alternativas, tiene sus ventajas e inconvenientes. Y hemos dado unas pinceladas sobre como se puede usar para ayudar a nuestro sistema anti-spam. En un futuro post, explicaré como configurar nuestro Postfix y Bind para que nuestro correo use DKIM.

Yo, personalmente, pienso que más que intentar parchear el protocolo SMTP, debería tomarse la decisión de hacer “borron y cuenta nueva” y diseñar un nuevo protocolo de transmisión de correo teniendo en cuenta todo lo aprendido hasta ahora y especialmente pensado para no permitir el spam.

Recientemente expliqué como Fail2Ban podía ayudarnos a ponérselo más difícil a esos script-kidies que se dedican a intentar entrar por SSH en nuestras máquinas realizando ataques de fuerza bruta.Hoy vamos a ver como usar esa misma herramienta para proteger de esos ataques a los servicios de correo. La configuración que voy a explicar supone que estamos usando Postfix como MTA, Cyrus como servidor POP3 e IMAP y SASL para autenticar a los usuarios.

Servidor SMTP

Como ya he comentado, lo que queremos es proteger el MTA de ataques de fuerza bruta: si alguien consiguiera averiguar unas credenciales correctas podría usar nuestro servidor para hacer relay. Dentro del paquete de fail2ban en Debian tenemos casí toda la configuración que nos hace falta. De hecho, se define el filtro sasl, pero la expresión regular no es del todo correcta. Para solucionarlo, crearemos el fichero /etc/fail2ban/filter.d/sasl.local (tal y como se recomienda en /usr/share/doc/fail2ban/README.Debian.gz<(code>) con el siguiente contenido.

[Definition]
failregex = : warning: .*+\[<HOST>\]: SASL (?:LOGIN|PLAIN|(?:CRAM|DIGEST)-MD5) authentication failed

Es la misma línea que en sasl.conf pero con ligeras modificaciones, como la eliminación de la marca de final de línea ($) en la expresión regular.

Activaremos la regla sasl modificando/creando el fichero /etc/fail2ban/jail.local:

[sasl]
enabled  = true

Para que se aplique la nueva regla, debemos recargar la configuración:

 server:~# fail2ban-client reload
 <pueden salir unos warnings>

 server:~# fail2ban-client status
 Status
 |- Number of jail:      2
 `- Jail list:           sasl, ssh

Si alguno de los comandos da un error de “Could not find server“, es que el servidor de fail2ban no está arrancado.

Servidores POP3 e IMAP

Por coherencia, si protegemos el servidor SMTP debemos hacer lo propio con los servidores de POP3 e IMAP. Si no, como los tres servicios comparten la base de datos de usuarios, podrían usar uno de los servicios desprotegidos para averiguar la contraseña por fuerza bruta. Como los mensajes de error de autenticación no indican el servicio que ha usado el usuario para conectarse, vamos a tratar los servidores POP3 e IMAP en conjunto. Esto es, al detectarse errores de autanticación se bloquearan todos los servicios.

Para realizar esta configuración, empezaremos creando el filtro en /etc/fail2ban/filter.d/cyrus.local con el siguiente contenido:

[Definition]
failregex = : badlogin: .*\[<HOST>\] (?:plaintext|LOGIN|(?:CRAM|DIGEST)-MD5|NTLM) .*SASL\(-13\): authentication failure
ignoreregex =

Y acabamos añadiendo las reglas necesarias al final del fichero /etc/fail2ban/jail.local:

[pop3]
enabled  = true
port     = pop3
filter   = cyrus
logpath  = /var/log/mail.log

[pop3s]
enabled  = true
port     = pop3s
filter   = cyrus
logpath  = /var/log/mail.log

[imap2]
enabled  = true
port     = imap2
filter   = cyrus
logpath  = /var/log/mail.log

[imaps]
enabled  = true
port     = imaps
filter   = cyrus
logpath  = /var/log/mail.log

Debemos definir una regla por puerto porque la versión 0.7.5 de fail2ban (la que tenemos en Etch) no soporta que se indique más de un puerto por regla. Versiones más recientes, como la versión 0.8, parece que si lo soportan (Si alguien lo comprueba, que me lo comente.  Gracias).

Como siempre, recargad la configuración y comprobad que se estén usando las reglas recién definidas.

Conclusiones

Fail2Ban es una gran medida disuasoria y con estas configuraciones conseguimos frenar en gran medida los ataques de fuerza bruta contra los servicios autenticados de correo: con la configuración por defecto, el servidor no aceptará conexiones de ese cliente durante diez minutos tras tres intentos fallidos.

Aunque la seguridad es necesaria, suele ser incómoda. Pensad en el usuario que intenta configurar su Outlook Expres en casa pero se le ha olvidado la contraseña (como si la hubiera recordado durante más de diez segundos… cuanto daño ha hecho la opción “Recordar contraseña”…) y tras varios intentos os llama. Como el servidor le ha bloqueado el acceso por un tiempo, aunque le podáis dar la contraseña correcta, deberá esperar. Dependiendo de como sean vuestros usuarios, es posible que debáis jugar un poco con los parámetros bantime y maxretry.

Como véis, no resulta muy complicado dotar de algo más de seguridad a nuestros servidores si conocemos las herramientas adecuadas y como usarlas.

Para eliminar cualquier duda que pueda haber surgido de mi reciente post sobre mi relación con los equipos de desarrolladores, con los que me llevo bastante bien, os presento el siguiente video de “Abraza a un desarrollador”. La mayoría de los que trabajéis en el mundo de las TI (una forma más cool de decir Informática ), por no decir todos, seguro que os veréis identificados.

Via: Beer Planet

Hoy quiero reflexionar, y me gustaría conocer vuestras opiniones al respecto, sobre si los equipos de desarrollo deben tener o no acceso al entorno productivo de un sistema informático. Como soy muy puntilloso en lo que a terminología se refiere (y los que me conocen lo saben muy bién), empezaré con un poco de introducción para fijar conceptos.

Entendemos por entorno como el conjunto de servidores necesarios para que nuestras aplicaciones funcionen. Es decir, en una aplicación web de tres capas, cada entorno lo formarían el servidor de base de datos, el servidor de aplicaciones y el servidor web.

Los sistemas medianamente complejos suelen disponer de vários. Típicamente, tres:

• Desarrollo: sobre el que los programadores realizan los cambios.
• Preproducción: que suele usarse para la integración de los cambios de los diferentes equipos, pero puede usarse también para pruebas de despliegue (deployment) y para pruebas de QA.
• Producción: al que los usuarios se conectan para usar las aplicaciones. Este es el entorno en el que se produce el negocio y por tanto el más crítico.

Al disponer de estos entornos, cualquier cambio suele pasar por los tres: se programa en desarrollo, se comprueba en preproducción y finalmente se despliega en el productivo para ponerlo a disposición de los usuarios.

Una vez introducidos los conceptos, mi opinión es que si los desarrolladores tienen acceso al entorno productivo, es posible que puedan sentirse tentados a realizar cambios directamente en él, saltándose el ciclo normal del cambio, debido a la presión de los usuarios y es posible que pueda provocar problemas  en un entorno que debería ser, por encima de ninguna otra cosa, estable. Estoy seguro que si un cambio provocara un problema, sería de forma involuntaria, pero errar es humano.

Por otra parte, es cierto que el proceso de resolución de incidencias puede complicarse ya que el desarrollador no puede monitorizar el sistema mientras reproduce la incidencia. Pero creo que los entornos de preproducción, correctamente mantenidos, se podrían usar para esto. Además, soy de la opinión de que los ficheros de log, correctamente usados, pueden ser de gran ayuda para la resolución de incidencias. Lo complicado está en determinar qué es necesario registrar: si loggueamos de más, el seguimiento y estudio puede complicarse por la cantidad de “ruido” que hay; y si nos quedamos cortos no dispondremos de la información suficiente para diagnosticar el problema.

He aquí el dilema: por la estabilidad del entorno productivo es mejor que no tengan acceso, pero esto puede dificultar la resolución de incidencias. Personalmente opino que las ventajas de que no tengan acceso superan con creces los inconvenientes, pero soy consciente de que por mi trabajo como administrador de sistemas puedo tener una visión sesgada del problema.

Y vosotros, ¿que opináis? ¿Deben o no tener los equipos de desarrollo acceso a producción?

Continuando con mis posts sobre seguridad, tema que me apasiona, hoy voy a explicar como implantar un sistema de One-Time-Password en nuestros servidores Linux.

Como se puede sobreentender de su nombre, los sistemas de One-Time-Password son sistemas de autenticación en los que cada contraseña se utiliza una única vez. Esto nos puede resultar útil en el caso de que debamos hacer login en situaciones comprometidas: usando un protocolo con el que las credenciales viajan en claro (sin cifrar) por la red, desde un equipo del que no podemos asegurar su integridad (que no tenga keyloggers instalados, por ejemplo), etc.

Aunque existen tres formas de implementar sistemas OTP, desde un punto de vista práctico existen dos tipos:

• Basados en secuencia: cada vez que usamos una contraseña esta deja de ser válida y el sistema nos pedirá la siguiente en el proximo login. Mientras no hagamos login, el sistema nos seguirá pidiendo la misma.
• Basados en relojes sincronizados: la contraseña va cambiando con el tiempo, se use o no. El principal requisito de estos sistemas es que el servidor y el generador de la contraseña deben estar sincronizados en el tiempo.

El sistema que os presento es OPIE, que está basado en secuencia, es una implementación de S/Key. Si elegí este fué por sencillez de implementación ya que todo el software necesario esta disponible desde los repositorios oficiales de Debian. Pero le he encontrado dos “problemas”: la página del proyecto no funciona (al menos mientras estoy escribiendo este post) y que no hay desarrollos nuevos desde 1998.

(more…)

Como me suele ocurrir a menudo, mientras navegaba un poco por youtube he encontrado por casualidad un vídeo divulgativo donde se explica cómo funciona Internet para los no técnicos.

La verdad es que está bastante bien, pero hay determinados momentos que no me han gustado tanto. Uno de ellos es cuando aparece el router por primera vez: por la forma en que lo explican parece que el router funciona de forma transparente, mientras que en la realidad los paquetes deben ir destinados al router para que este los dirija hacia el siguiente salto. Otro de esos momentos es cuando hablan del ping de la muerte, ya que me parece un poco sensacionalista y más cuando hace algunos años que los fabricantes solucionaron la vulnerabilidad.

Pero a parte de estos detalles me parece muy interesante.

Una de las principales preocupaciones de cualquier administrador de sistemas es la seguridad de sus servidores, y más particularmente de las intrusiones. La principal medida que se suele usar para evitarlas es el uso de Firewalls, pero siempre debemos dejar abiertos los puertos por los que da servicio (un servidor al que no nos pudiéramos conectar no es muy útil ), y si esos servicios son autenticados, pueden ser sujetos de ataques de fuerza bruta para averiguar contraseñas. Uno de los principales servicios que sufren este tipo de ataques es el de SSH y para protegerlo disponemos de fail2ban.

Fail2ban es un servicio que vigila una serie de ficheros de log y cuando detecta intentos fallidos bloquea la dirección IPdesde la que se han realizado añadiendo una regla de iptables.

Para instalarlo, en Debian basta con un "aptitude install fail2ban". La configuración por defecto trae activada la protección de SSH y a parte de bloquear la IP infractora envía un correo a root. A parte de la protección de SSH, trae configuraciones para apache, postfix, qmail, vsftpd, etc. y soporte para otros sistemas de firewall a parte de iptables.

Fail2ban no nos asegura una protección total, es sólo una medida más para ponérselo más difícil a los que intentan entrar de forma no autorizada en nuestro servidor, principalmente contra script-kiddies.

“The adventures of Ace, DBA” es el título de una tira cómica que descubrí a principios de verano cuyo protagonista es Ace, un DBA de Oracle. El aspecto es similar al de xkcd, como reconoce el autor, y hay alguna tira que es para troncharse. Eso sí, no es para el público en general ya que el humor es muy geek, y en algunos casos puede ser difícil pillar la gracia totalmente si nunca has trabajado con Oracle.

La lástima es que desde finales de Agosto no ha publicado ninguna tira nueva.