SSH (Secure SHell) es a un tiempo el nombre del protocolo y el programa que nos permite acceder a maquinas remotas de forma segura y gestionarlas por completo mediante un intérprete de comandos.

Hechas las presentaciones, vaya por delante lo de siempre: un servidor completamente seguro es el que está encerrado entre muros de hormigón sin ningún tipo de conexión. Obviamente, así no sirve para nada, entonces tendremos que buscar el correcto equilibrio entre conectividad y seguridad. Como me toca acabar el año configurando nuevos servidores, os dejo una pequeña guía para asegurar el acceso por SSH.

Lo primero, modificar el fichero de configuración de SSH que encontrareis en /etc/ssh/sshd_config y agregamos las siguientes líneas (en muchos casos las encontrareis comentadas).

Protocol 2
LoginGraceTime 20
PermitRootLogin no
MaxAuthTries 2
MaxStartups 3
AllowUsers pepito

La primera línea le indica que unicamente se puede hacer uso de la versión 2 del protocolo de comunicación. La primera versión tiene algunas vulnerabilidades conocidas y está obsoleta por lo que lo recomendable es no usarla si no se necesita.

El LoginGraceTime hace referencia al tiempo en segundos que la pantalla de login permanecerá abierta, en el ejemplo hemos dejado 20 segundos, un tiempo más que suficiente para indicar usuario y contraseña.

Con PermitRootLogin establecido a no evitaremos que el usuario root pueda autenticarse a través de SSH para acceder al servidor. El problema es que los sistemas Linux y Unix crean al usuario root, lo que garantiza a un atacante que ya conoce el usuario, sólo queda la contraseña. De esta forma será mucho más complicado, obviamente no uses nombres conocidos o estarás en el mismo caso.

Otro de los límites que podemos imponer es definir la cantidad de veces que podemos fallar al autenticarnos. Con MaxAuthTries definimos el número de intentos, con 1 sería más que suficiente, pero a los que nos toca andar con varios servidores a la larga terminas equivocándote la primera vez de ahí que lo defina con 2 intentos. Lo que ocurrirá después del segundo fallo es que se cerrará la conexión.

Con MaxStartups se indican la cantidad de conexiones simultaneas que se permiten, en este caso hemos optado por 3, un número razonable para aquellos servidores a los que se accede por SSH únicamente para su administración. Con esto evitaremos que un ataque por fuerza bruta pueda realizar miles de conexiones simultaneas para atacar.

Y por último, pero no menos importante, AllowUsers. Con esta directiva le indicamos al SSH que usuarios exclusivamente se pueden identificar en el sistema. También podemos aumentar la seguridad definiendo desde que redes puede acceder un determinado usuario. Basta con poner los nombres de los usuarios separados por espacios, si se quiere indicar un host podemos hacerlo poniendo el usuario seguido del símbolo @ y el host (Ej: pepito@127.0.0.1).

Con esto ya tenemos nuestro SSH un poco más seguro. Guardamos el fichero y reiniciamos el servicio.

Lo segundo que haremos para evitar que nos ataquen será instalar Fail2ban, un programa controla los logs y que nos permite vetar todas aquellas IP’s que fallan un determinado número de veces. El baneo se realizará usando el firewall, así que lo que hace realmente Fail2ban es crear y borrar reglas en función de la información que se registra en los logs.

El requisito para instalar Fail2ban es tener Python, tenéis disponibles paquetes compilados para instalar o podeis tirar de repositorios. Una vez instalado tan solo es necesario configurar las reglas que queremos tener activas, tenéis bastante información en su web y un archivo de configuración de prueba en /etc/fail2ban/jail.conf

Para los que nos dedicamos al desarrollo de software es de vital importancia poder hacer un seguimiento de todos los cambios que realizamos en una aplicación, sobre todo cuando se trata de trabajar en equipo con distintos programadores realizando distintas tareas, e incluso llevar un control de los cambios que realizan distintos equipos dentro de un mismo software.

Cuando el proyecto está bajo el paraguas del software libre, herramientas como las proporcionadas por www.sourceforge.net son de mucha ayuda. Entre ellas se encuentra el uso de Subversion o CSV para la gestión de versiones. Personalmente prefiero subversion.

Este es un pequeño HOWTO de como configurar subversion corriendo bajo Apache, se presupone que se tiene instalado Apache, Subversion, el módulo DAV para Apache y las herramientas de administración de Subversion.

Lo primero que debemos hacer es crear un directorio para nuestro repositorio. Nuestro directorio principal para guardar nuestro control de versiones sobre subversion será /var/subversion/, dentro crearemos un subdirectorio donde se almacenarán los datos con subversion:

# mkdir /var/subversion/repositorio

Ahora debemos crear la estructura de subversion para almacenar las versiones y asignarle permisos para poder acceder:

# svnadmin create /var/subversion/repositorio/
# chmod 777 -R /var/subversion/repositorio/

Con esto ya tenemos listo el repositorio, ahora debemos generar el acceso a través de URL, para ello usaremos el módulo de Apache WebDav. Editaremos el fichero de módulo DAV de Apache (en Devian lo encontraremos en /etc/apache2/mods-available/dav_svn.conf), al final del fichero incluiremos las siguientes líneas:

# Acceso repositorio SVN

DAV svn
AuthType Basic
AuthName “Servidor Subversion”
SVNPATH /var/subversion/repositorio

En “Location” debemos poner la URL por la que queremos acceder al repositorio y en SVNPATH debemos colocar la ruta absoluta hacia el directorio que contendrá los ficheros de nuestro repositorio. Con esto ya debería estar funcionando nuestro repositorio con Subversion, basta con enlazarlo desde cualquier IDE que soporte control de versiones y comenzar a guardar las versiones de vuestros proyectos.

Como subversion no es sólo lo que he comentado, existe un estupendo manual donde podéis encontrar todas las funciones que ofrece este gestor de versiones.

Algo muy frecuente, más de lo que parece a pesar de que el sentido común indique lo contrario, es que los usuarios de un servidor de correo intenten enviar auténticos “ladrillos” a través del correo electrónico. Para la mayor parte de los usuarios 100 KB o 100 MB les suena más o menos a lo mismo e intentarán enviarlo a través del correo sin siquiera pararse a pensar si es o no razonable.

Un amigo hizo una buena comparación para que se vea la diferencia, en el caso de los 100 MB es como si se intentase enviar por correo postal una lavadora, a todo el mundo le parecería una autentica barbaridad.

Para evitarlo, podemos limitar el tamaño máximo de los correos que son enviados con Qmail. Para ello nada más sencillo que indicar el tamaño máximo en el fichero /var/qmail/control/databytes que se quiere establecer expresado en bytes. Por ejemplo para limitar el tamaño de los correos a 10 MB escribimos en el fichero 10485760 .

Guardamos el fichero y reiniciamos el servicio, con esto ya estará establecido el límite máximo del tamaño del correo. El usuario recibirá un mensaje o un correo de aviso de que no puede enviar más “ladrillos” por email.

A través de Barrapunto, llego a una noticia de MuyComputer donde se comenta que la venta de netbooks con Linux está siendo un fracaso. Para ello alegan que hace unos meses un directivo de MSI confirmaba que las ventas de netbooks con Linux no iban bien y que más del 90% de los Acer Aspire One y del Toshiba Satellite NB100 se venden con Windows XP.

Por su parte Dell y Asus llegan a la misma conclusión, depués de achacar que el boom inicial de Linux fue debido a que el hardware apenas podría ejecutar XP con soltura, y que encuanto el hardware ha evolucionado los fabricantes siguen ofreciendo aquello que los usuarios demandan. Para añadir más leña al fuego, todo apunta a que los netbooks podrían tener un hardware suficiente para poder ejecutar Windows Vista.

Por una parte puedo entender que los usuarios prefieran los malo conocido que lo bueno por conocer, pero con esto nos alejamos del concepto inicial de netbook. El netbook está pensado para ser un equipo totalmente centrado en el acceso a la nube, donde el usuario mantiene todo lo que necesita (correo electrónico, perfiles de redes sociales, fotografías, videos, documentos, etc).

¿Para que necesita un usuario un hardware potente, cuando la única misión del netbook es acceder a los servicios que viven en la nube? Parece incluso ridículo elevar el precio de un netbook por un hardware capaz de hacer correr un sistema operativo que consume demasiados recursos o con una gran cantidad de almacenamiento cuando no se va a almacenar nada.

El problema radica en que el usuario final se ha planteado la compra de una netbook como un portatil tradicional, con un menor tamaño lo que lo hace más transportable, pero con un precio más reducido. La mayoría de los usuarios que compren un netbook, al menos de momento, pensando en hacerlo el sustituto de un portatil tradicional, se están equivocando y acabará provocando una visión distorsionada sobre la calidad del producto.

Entonces, ¿qué debemos tener en cuenta a la hora de comprarnos un netbook? Lo principal sus posibilidades de acceso, bien mediante redes wifi, conexiónes de red, Wimax, 3G, etc. Esa es la principal característica, y para acompañarlo un sistema operativo que consuma pocos recursos (y ahí Linux lleva las de ganar) y una buena memoria RAM capaz de permitirnos mantener unas cuantas ventanas del navegador abiertas con los distintos servicios.

A lo largo de estos meses me han preguntado si tal o cual netbook era un buen equipo. Y mi respuesta siempre ha sido la misma, ¿vas a utilizarlo para acceder a Internet y usar todos los servicios que están disponibles en la nube sin hacer uso de los programas de escritorio, excepto en casos puntuales? Si la respuesta es SI, entonces adelante lo que necesitas es un netbook, en caso contrario busca un portatil con mayores prestaciones, seguro que no terminarás defraudado con las posibilidades del producto.

Según W3Counter, una empresa estadísticas, Linux ya casi alcanza el 2% de los usuarios de internet. Estas estadísticas globales se basan en muestras recogidas de más de 9.000 sitios web con 22 millones de visitas individuales.

Mac se acerca ya al 5%, mientras que los sistemas de Microsoft pierden terreno, el nuevo sistema operativo Windows Vista, solo le ha quitado cuota a sus predecesores, así Windows XP baja al 78% en abril de 2008, mientras que en mayo de 2007 tenía casi un 85%.

La asociación cultural olholivre celebra en A Coruña unas jornadas sobre Software Libre durante esta y la próxima semana. Las charlas y talleres se celebrarán en dos emplazamientos: la CSA Atreu y la Casa das Atochas, ambas en MonteAlto.

Una de las formas de mejorar el rendimiento de un servidor con páginas web en PHP es la instalación de un sistema cache como módulo del intérprete de PHP instalado en el servidor. El uso de estos sistemas puede mejorar el rendimiento del servidor entre un 20% y un 50%. Entre los sistemas más populares que podemos encontrar se encuentran Zend Optimizer, IonCube o eAccelerator.

Vamos a centrarnos en éste último y veremos como instalarlo paso a paso sobre un servidor Linux desde los fuentes. Para poder compilar correctamente eAccelerator debes tener instalado phpize, en Fedora puedes obtenerlo usando yum install php-devel, en Debian apt-get install php-dev.

Lo primero es descargar el paguete correspondiente a la última versión de eAccelerator (en este caso la 0.9.5.3). Podemos elegir descargarlo en .tar.bz2 o .zip, usaremos el .tar.bz2 y lo descargamos, descomprimimos y entramos en el directorio:

wget http://bart.eaccelerator.net/source/0.9.5.3/eaccelerator-0.9.5.3.tar.bz2

tar jvxf eaccelerator-0.9.5.3.tar.bz2

cd eaccelerator-0.9.5.3

Una vez dentro del directorio, vamos a empezar a compilar los fuentes. Si sólo tienes un intérprete de PHP instalado (suele ser lo más habitual) puedes ejecutar:

phpize

./configure

make

En caso de tener más de una instalación deberás indicar donde se encuentra la que quieres usar. Sustituye la ruta en la primera línea (/usr/php) por aquella donde tengas instalado PHP:

PHP_PREFIX="/usr/php"

$PHP_PREFIX/bin/phpize

./configure –enable-eaccelerator=shared –with-php-config=$PHP_PREFIX/bin/php-config

make

Realizado esto ya tenemos el módulo preparado para su instalación, ejecutamos:

make install

Una vez terminada la instalación se nos mostrará la ruta donde se ha copiado el módulo del eAccelerator que debemos configurar en el php.ini, si todo ha ido bien debes tener algo como esto:

Installing shared extensions:    /usr/lib/php/modules/20080501/

Ahora debemos indicar en el php.ini nuestro nuevo módulo para que sea cargado con el intérprete. Abrimos el php.ini, si no sabes donde está localizado ejecuta phpinfo(). Editamos el archivo y buscamos una sección llamada "Dynamic Extensions". Buscamos una directiva llamada extension_dir y la definimos con la ruta donde guardamos las extensiones:

extension_dir = "/usr/php/modulos/"

A continuación agregamos las siguientes líneas que incluyen el nombre del módulo y su configuración:

extension="eaccelerator.so"

eaccelerator.shm_size="16"

eaccelerator.cache_dir="/tmp/eaccelerator"

eaccelerator.enable="1"

eaccelerator.optimizer="1"

eaccelerator.check_mtime="1"

eaccelerator.debug="0"

eaccelerator.filter=""

eaccelerator.shm_max="0"

eaccelerator.shm_ttl="0"

eaccelerator.shm_prune_period="0"

eaccelerator.shm_only="0"

eaccelerator.compress="1"

eaccelerator.compress_level="9"

Guardamos el php.ini y ahora debemos crear el directorio temporal que usará eAccelerator, definido en la configuración que acabamos de agregar al php.ini como eaccelerator.cache, este directorio debe tener permisos de escritura:

mkdir /tmp/eaccelerator/

chmod 777 /tmp/eaccelerator/

Termidamo esto ya tenemos eAccelerator intalado en nuestro servidor. Sólo falta reiniciar apache para que la nueva configuración tenga efecto.