internet, desarrollo, diseño web, sysadmin

La versión de Debian GNU/Linux con la que trabajaremos es la 4.0 etch.

Los pasos para instalar el sistema operativo dependerán de nuestro proveedor de hosting. Normalmente, dispondremos de un panel de control para poder instalar nuestro servidor. Partiremos, por lo tanto, de una instalación totalmente nueva y operativa, de la que tendremos la password de root y la dirección IP para poder conectarnos por SSH.

Nos conectamos a la máquina recien instalada. Lo primero que haremos, por seguridad, será cambiar la contraseña de root:

# passwd

Creación de un usuario no privilegiado

Creamos un usuario no privilegiado, el cual ejecutará el servidor web y los servidores de aplicaciones:

# useradd -d /home/usuario -s /bin/bash usuario
# mkdir /home/usuario
# chown usuario:usuario /home/usuario
# passwd usuario

Por comodidad, instalaremos la herramienta sudo y le daremos a nuestro usuario privilegios para poder utilizarla:

# apt-get install sudo
# export EDITOR=vi
# visudo

Y añadimos al final del fichero:

usuario ALL=(ALL) ALL

Podemos crear un fichero ~/.bash_profile para el usuario. Podemos utilizar como ejemplo:

PS1='\[\033[035m\]\u\[\033[033m\] \w\[\033[00m\]$ '
EDITOR=vi
RAILS_ENV=production
export PS1 EDITOR RAILS_ENV

Configuración de SSH

Editamos el fichero de configuración de SSH, /etc/ssh/sshd_config, de manera que:

• por seguridad, cambiamos el puerto TCP 22 por otro no estándar, por ejemplo el 30000.
• nos aseguramos de que la versión del protocolo es la 2.
• no será posible conectarse directamente como root.
• permitiremos la autenticación mediante password (a menos que definamos una relación de confianza).
• no permitiremos X11Forwarding.
• deshabilitaremos la autenticación vía PAM.
• deshabilitaremos las resoluciones inversas de DNS.
• permitiremos solamente el acceso por SSH al usuario que hemos creado anteriormente.

Es decir, en el fichero /etc/ssh/sshd_config deberemos comprobar las siguiente líneas:

Port 30000
Protocol 2
PermitRootLogin no
PasswordAuthentication yes
X11Forwarding no
UsePAM no
UseDNS no
AllowUsers usuario

Una vez editado, le indicamos al demonio sshd que lo relea:

# /etc/init.d/ssh reload

Antes de desconectarnos como root, deberemos probar a conectarnos con el usuario no privilegiado que hemos creado, ya que si no hemos editado correctamente el fichero de configuración de SSH podríamos peder el acceso a la máquina:

$ ssh -l usuario IP -p 30000

Configuración del firewall iptables

Si acabamos de instalar debian, la tabla de reglas del firewall estará vacia:

$ sudo -i
# iptables -L
Chain INPUT (policy ACCEPT)
target     prot opt source               destination
 
Chain FORWARD (policy ACCEPT)
target     prot opt source               destination
 
Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination

Editamos el fichero /etc/iptables.test.rules y pegamos:

*filter
 
 
#  Allows all loopback (lo0) traffic and drop all traffic to 127/8 that doesn't use lo0
-A INPUT -i lo -j ACCEPT
-A INPUT -i ! lo -d 127.0.0.0/8 -j REJECT
 
 
#  Accepts all established inbound connections
-A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
 
 
#  Allows all outbound traffic
#  You can modify this to only allow certain traffic
-A OUTPUT -j ACCEPT
 
 
# Allows HTTP and HTTPS connections from anywhere (the normal ports for websites)
-A INPUT -p tcp --dport 80 -j ACCEPT
-A INPUT -p tcp --dport 443 -j ACCEPT
 
 
#  Allows SSH connections
#
# THE -dport NUMBER IS THE SAME ONE YOU SET UP IN THE SSHD_CONFIG FILE
#
-A INPUT -p tcp -m state --state NEW --dport 30000 -j ACCEPT
 
 
# Allow ping
-A INPUT -p icmp -m icmp --icmp-type 8 -j ACCEPT
 
 
# log iptables denied calls
-A INPUT -m limit --limit 5/min -j LOG --log-prefix "iptables denied: " --log-level 7
 
 
# Reject all other inbound - default deny unless explicitly allowed policy
-A INPUT -j REJECT
-A FORWARD -j REJECT
 
COMMIT

Si hemos elegido para el demonio sshd un puerto diferente al 30000, tendremos que editar la línea del fichero que permite las conexiones SSH entrantes.

Cargamos el firewall con las nuevas reglas:

# iptables-restore < /etc/iptables.test.rules

Comprobamos que las reglas se han cargado correctamente.

# iptables -L

Comprobamos también que podemos conectarnos de nuevo por SSH. En caso afirmativo, podemos guardar las reglas:

# iptables-save > /etc/iptables.up.rules

Para que los cambios sean tenidos en cuenta al rearrancar la máquina, deberemos editar el fichero /etc/network/interfaces. Después de las líneas:

# The loopback network interface
auto lo
iface lo inet loopback

añadiremos:

pre-up iptables-restore < /etc/iptables.up.rules

Para comprobar que todo ha ido bien, rearracamos la máquina:

# shutdown -r now

Actualizaciones

Una vez conectados de nuevo, realizaremos una actualización de los paquetes de la distribución debian. Tendremos en cuenta que la lista de repositorios en los que se buscan las actualizaciones está en /etc/apt/sources.list. En principio no será necesario cambiar la lista de repositorios.

Actualizamos la lista de paquetes disponibles en el repositorio:

$ sudo aptitude update

Reconfiguramos los paquetes de locales. Para ello, editamos el fichero /etc/environment:

LANG=es_ES.UTF-8

y ejecutamos:

$ sudo aptitude install locales
$ sudo dpkg-reconfigure locales

Nos aparecerá un menú donde tendremos que seleccionar los locales:

es_ES.UTF-8 UTF-8

Como veis, he escogido el español de España (es_ES). Cada uno puede elegir el locale que le interese.

Ahora sí, actualizamos los paquetes de nuestra máquina (esto puede tardar un rato):

$ sudo aptitude upgrade
$ sudo aptitude dist-upgrade

Rearracamos:

$ sudo shutdown -r now

Y por último, instalamos los paquetes necesarios para la compilación, ya que los necesitaremos más adelante:

$ sudo aptitude install build-essential

Tutorial completo

• Rails en producción - Parte 1 - Introducción
• Rails en producción - Parte 2 - Configuración del servidor debian
• Rails en producción - Parte 3 - MySQL, Ruby y Rails
• Rails en producción - Parte 4 - Servidor web nginx
• Rails en producción - Parte 5 - Mongrels e instalación de nuestra aplicación
• Rails en producción - Parte 6 - Cluster de mongrels

La puesta en producción de una aplicación Rails no es trivial. Tanto si disponemos de un VPS como de un servidor dedicado, tendremos que instalar y configurar, a parte del propio servidor, un servidor web, un servidor de aplicaciones Rails y una base de datos.

Las posibilidades de elección son numerosas. A día de hoy, una de las arquitecturas más utilizadas para poner en producción una aplicación Rails sería la de la siguiente figura:

Es decir, utilizaremos:

• como sistema operativo, Debian GNU/Linux.
• como servidor web, nginx, mucho más liviano que Apache.
• como servidor de aplicaciones, mongrel.
• como base de datos, MySQL.

Las peticiones HTTP son recibidas por nginx, el cual se encarga de redirigirlas y balancearlas hacia los mongrels. Cada mongrel ejecutará nuestra aplicación Rails en el MRI, es decir, en el intérprete de Ruby tradicional. Finalmente, nuestra aplicación Rails se comunicará con la base de datos MySQL a través de ActiveRecord.

He dividido este tutorial en varias entradas:

• Rails en producción - Parte 1 - Introducción
• Rails en producción - Parte 2 - Configuración del servidor debian
• Rails en producción - Parte 3 - MySQL, Ruby y Rails
• Rails en producción - Parte 4 - Servidor web nginx
• Rails en producción - Parte 5 - Mongrels e instalación de nuestra aplicación
• Rails en producción - Parte 6 - Cluster de mongrels

La documentación que he utilizado ha sido, principalmente:

• Artículos de Slicehost.
• Deploying Rails Applications: A Step-by-Step Guide, de Ezra Zygmuntowicz, Bruce Tate y Clinton Begin.

El CERT ha publicado un documento alertando de deficiencias en el protocolo DNS que pueden permitir a un atacante el envenenamiento de las cachés. Es decir, el atacante podría reemplazar en el servidor afectado direcciones de sitios populares de internet por la dirección de un servidor malicioso.

Al parecer, estas deficiencias en el protocolo fueron descubiertas hace meses por Dan Kaminsky, de la empresa IOActive. Los proveedores de servidores de DNS fueron avisados y se pusieron a trabajar, en secreto, en parches para solucionar el problema.

El problema no se ha descrito con detalle todavía. La solución implementada en los parches consiste en aumentar el rango de puertos UDP posibles desde los que se pueden hacer consultas a los servidores de DNS. La única solución definitiva es utilizar DNSSEC, es decir, las extensiones de seguridad de DNS, lo cual no sería ni mucho menos trivial.

El revuelo que esta noticia ha causado tan grande que hasta la prensa generalista se ha hecho eco de ella.

Enlaces relacionados

• CERT: Multiple DNS implementations vulnerable to cache poisoning
• SecurityFocus: Alliance forms to fix DNS poisoning flaw
• ISC: DNS Cache Poisoning Issue
• 20 minutos: Un problema con las direcciones de las webs pone en riesgo la seguridad de internet
• El Mundo: Los gigantes de la Red se movilizan contra un grave agujero de seguridad
• El País: Un grave fallo de seguridad en la Red moviliza a las grandes compañías

Existen dos tipos de dispositivos de almacenamiento. Los que han fallado y los que están a punto de fallar.

– Dicho popular entre los administradores de sistemas.
(Visto en el blog de Jonathan Schwartz)

# Enlace permanente

Hace unos días Sun presentó el data warehouse más grande del mundo. Tradicionalmente este tipo de anuncios se centraba sobre todo en la capacidad de proceso y en el retorno de la inversión. Es decir, en lo que me cuesta y lo que obtengo a cambio.

En este anuncio me llama la atención que se hace especial hincapié en la ventaja medioambiental que esta solución supone frente a la solución de la competencia. En concreto, se comparan las emisiones de CO₂ y la basura generada durante el periodo de amortización de los equipos.

Pienso que los parámetros medioambientales tendrán cada vez una mayor importancia a la hora de determinar las inversiones relacionadas con las tecnologías de la información. De hecho, hace unos días McKinsey y el Uptime Institute publicaban un interesante estudio sobre la eficiencia energética de los centros de datos, según el cual, uno de los principales retos que van a tener muchas empresas es gestionar la eficiencia energética de su infraestructura de TI, no sólo por el gasto que eso supone, sino por la gran emisión de gases de efecto invernadero que los centros de datos producen.