Fin del soporte de seguridad de PHP en Debian 7

Actualizando una Debian 7 me encuentro con este mensaje de fin del soporte de seguridad de PHP, por lo que es conveniente migrar a Debian 8.

php5 (5.4.45-0+deb7u2) wheezy-security; urgency=medium

* PHP 5.4 has reached end-of-life on 14 Sep 2015 and as a result there
will be no more new upstream releases. The security support of PHP
5.4 in Debian will be best effort only and you are strongly advised
to upgrade to latest stable Debian release that includes PHP 5.6 that
will reach end of security support on 28 Aug 2017.

— Ondřej Surý <ondrej@debian.org> Sun, 04 Oct 2015 17:05:37 +0200

Cómo crear un blog de forma segura con WordPress

El Centro Criptológico Nacional (CCN) ha hecho pública su Guía CCN-STIC 640 Seguridad en WordPress, con el fin de ofrecer unas recomendaciones de seguridad mínimas a la hora de utilizar WordPress que, por deficiencias de configuración, en muchas ocasiones ha sido utilizado para materializar numerosos ataques.

La Guía comienza con un histórico de las distintas versiones que han ido apareciendo de WordPress (creado a partir del desaparecido b2/cafelog) y que debe su éxito, entre otros, a su licencia, su facilidad de uso y sus características como gestor de contenidos.

Instalación y actualización, seguridad en la base de datos, procedimiento para la instalación de plugins, bastionado de la cuenta de Administrador, el registro de actividad del sistema o las restricciones de acceso a directorios son algunos de los 22 capítulos que cuenta la Guía.

Además, recoge distintas secciones sobre la prevención de spam, las actualizaciones automáticas, la configuración de permisos, las copias de seguridad o la recuperación ante un compromiso de seguridad.

Por último, el documento realiza una mención especial a la seguridad personal como el uso de gestores de contraseñas, los antivirus, phishing , cortafuegos o seguridad Wi-Fi.

La guía está disponible en este enlace.

Protección para la vulnerabilidad XML-RPC de WordPress en nginx

En una entrada anterior expliqué cómo proteger el blog de un ataque a la vulnerabilidad XML-RPC en WordPress en un servidor Apache.

En esta entrada indico los campos que hay que añadir en cada configuración de los hosts de nginx para evitar este ataque. Simplemente hay que añadir

server {
#…..
location = /xmlrpc.php {
            deny all;
            access_log off; #Evitamos saturar el archivo de log
        }
#…..
}

Recuerda volver a cargar la configuración del servidor, ejecutando

sudo service nginx restart

Putty, SSH y claves RSA. Acceder a un servidor Linux desde Windows con Putty y claves RSA

En una entrada anterior expliqué cómo acceder por SSH a un servidor o equipo remoto sin introducir ni usuario ni contraseña entre equipos Linux o Unix (OS X incluido). En esta entrada voy a explicar cómo hacer lo mismo desde un equipo Windows, usando la aplicación de acceso remoto Putty.

Lo primero que tenemos que hacer es descargar e instalar Putty. Instala varias aplicaciones

Putty

Ejecutamos PuTTYgen para generar la clave pública/privada RSA (SSH-2) de 2048 bits. Selecciono estas dos opciones.

PuttyGen-Key-Generator

A continuación muevo el ratón por la zona vacía para generar aleatoriedad en la creación de las claves.

PuttyGen-Key-Generator

Y ya tengo generadas las 2 claves RSA.

PuttyGen-Key-Generator

Tras generar las 2 claves, las guardo, por ejemplo, en un directorio llamado “my_keys” en “Mis documentos”:

  • Clave pública: rsa-key-servidor
  • Clave privada: rsa-key-servidor.ppk

A continuación copio la clave pública haciendo clic con el botón derecho del campo que indica “Public key for pasting into OpenSSH authorized_keys file:”, usando los comandos “Seleccionar todo” y “Copiar”. Es importante comprobar que la clave empiece por el texto ssh-rsa AAAA.

PuttyGen-Key-Generator

Lo siguiente que tengo que hacer es acceder al servidor con el usuario que estoy configurando y pegar esta clave al final del archivo ~/.ssh/authorized_keys. En el peor de los casos, que no tenga creado el archivo ni el directorio .ssh, ejecuto los comandos:

# Creo el directorio
mkdir ~/.ssh
# Cambio los permisos para que solo pueda acceder el propietario
chmod 0700 ~/.ssh
# Creo el archivo vacio
touch ~/.ssh/authorized_keys
#Cambio los permisos del archivo
chmod 0644 ~/.ssh/authorized_keys

Y en este archivo “authorized_keys” tengo que pegar al final del archivo la clave pública copiada en el paso previo.

A continuación tengo que configurar Putty. Lo ejecuto.

En la sección Session introduzco los datos del servidor remoto: IP o host (campo “Host Name (or IP address)“) y puerto (campo “Port“).

Putty-RSA-login-configuration

En la sección Connection -> Data introduzco el nombre de usuario (campo “Auto-login username”) en el servidor remoto para el que estoy configurando las claves.

Putty-RSA-login-configuration

En la sección Connection -> SSH -> Auth le indico la ubicación de la clave privada (extensión .ppk) creada previamente.

Putty-RSA-login-configuration

Ya solo me queda guardar la sesión con un nombre determinado, que en este caso será la IP del servidor al que me quiero conectar, ya que es un servidor de la red local y lo identifico fácilmente. Para ello voy a la sección Session, selecciono una sesión existente (o creo una nueva introduciendo el nombre en el campo “Saved Sessions“) y hago clic en el botón “Save“.

Putty-RSA-login-configuration

Ya tengo todo configurado. Para conectarme automáticamente al servidor bastará con que haga doble clic sobre la sesión guardada.

Más información:

:wq

Acceder por SSH a un servidor o equipo remoto sin introducir ni usuario ni contraseña

Cuando nos conectamos a un servidor para poder administrarlo lo solemos hacer por SSH (espero que no uses telnet u otros métodos no seguros 😉 ). Tras instalarlo, para acceder usamos un usuario y una contraseña y empezamos a administrarlo.

Una de las implementaciones más habituales es OpenSSH (OpenBSD Secure Shell), un proyecto que nació en el año 1999 y cuya finalidad, tal y como indican en su web es:

OpenSSH is a FREE version of the SSH connectivity tools that technical users of the Internet rely on. Users of telnet, rlogin, and ftp may not realize that their password is transmitted across the Internet unencrypted, but it is. OpenSSH encrypts all traffic (including passwords) to effectively eliminate eavesdropping, connection hijacking, and other attacks. Additionally, OpenSSH provides secure tunneling capabilities and several authentication methods, and supports all SSH protocol versions.

Esta implementación está presente, tanto la parte de cliente como la de servidor, en la mayoría de máquinas no Windows: BSD (OpenBSD, FreeBSD, NetBSD,…), Cygwin, Mac OS X a partir de la versión 10.1, IBM AIX, Sun Solaris, máquinas Cisco, Novell NetWare, máquinas Dell, HP-UX, máquinas Juniper y todos los Linux.

La suite OpenSSH reemplaza rlogin y telnet con ssh, rcp con scp y ftp con sftp. También incluye la implementación del servidor, sshd, y otras utilidades, tales como ssh-add, ssh-agent, ssh-keysign, ssh-keyscan, ssh-keygen y sftp-server.

Como podemos ver es una suite de comunicaciones segura, muy completa y de uso muy extendido.

En este artículo explico como configurar un equipo con alguno de los sistemas operativos en los que podemos instalar OpenSSH y con el cuál queremos acceder desde una consola a un servidor mediante SSH sin tener que introducir contraseñas.

Para esto utilizaremos autentificación de clave pública; es decir, tenemos una clave pública y otra privada que usaremos para autentificarnos ante otros sistemas, como en este caso ante un servidor remoto.

Lo primero que hacemos en el equipo local es generar el conjunto de claves pública y privada. Para ello usamos el comando ssh-keygen, que permite la creación de claves de autentificación. Nos pedirá la ruta y el nombre del archivo que le vamos a dar a la clave privada (a la pública le añade la extensión .pub) y una contraseña de acceso para cuando queramos acceder a la clave privada. Si estáis en un equipo local controlado por vosotros podéis dejarla vacía.

ssh-keygen

Generating public/private rsa key pair.
Enter file in which to save the key (/home/usuario/.ssh/id_rsa): /home/usuario/.ssh/usuario_local
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/usuario/.ssh/usuario_local.
Your public key has been saved in /home/usuario/.ssh/usuario_local.pub.
The key fingerprint is:
7f:6d:24:8b:d5:9c:8e:03:13:6c:dc:09:f2:c7:f2:ec usuario@equipo
The key’s randomart image is:
+–[ RSA 2048]—-+
| ..oo . |
| =..o |
| = o |
| * o . |
| o S . = . |
| + + + + |
| E + o o |
| . . . |
| |
+—————–+

Acabamos de generar 2 claves de tipo RSA de 2048 bits:

  • /home/usuario/.ssh/usuario_local. Es la clave privada, que debemos de mantener segura en nuestro equipo.
  • /home/usuario/.ssh/usuario_local.pub. Es la clave pública, que llevaremos al servidor.

Copiamos la clave pública al servidor. Para ello ejecutamos en nuestro equipo el comando scp, mediante el cual copiamos la clave pública al servidor remoto.

scp -P 22 ~/.ssh/usuario_local.pub usuario_remoto@miequiporemoto.com:/home/usuario_remoto/.ssh/usuario_local.pub

The authenticity of host ‘[miequiporemoto.com]:22 ([11.22.33.44]:22)’ can’t be established.
ECDSA key fingerprint is 75:c5:23:ad:5a:f1:22:3b:f1:ef:a2:5e:f8:8a:2d:ab.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added ‘[miequiporemoto.com]:22,[11.22.33.44]:22’ (ECDSA) to the list of known hosts.
usuario_remoto@miequiporemoto.com’s password:
usuario_local.pub 100% 398 0.4KB/s 00:00

En el equipo remoto añadimos la clave pública al archivo “authorized_keys” del usuario remoto. Para ello ejecutamos en el equipo remoto

cat ~/.ssh/usuario_local.pub >> ~/.ssh/authorized_keys

Solo nos queda crear un shortcode en el archivo del equipo local ~/.ssh/config para poder acceder de una forma rápida al servidor. Para ello anadimos en este archivo las siguientes líneas:

Host miservidor
Hostname miequiporemoto.com
Port 22
User usuario_remoto
IdentityFile ~/.ssh/usuario_local

Y para acceder al equipo remoto desde el equipo local solo tenemos que ejecutar

ssh miservidor

Más información:

:wq

Protección para la vulnerabilidad XML-RPC de WordPress

Llevo unos días con el servidor en el que se aloja este blog y otros (todos desarrollados en WordPress) caído por intervalos, con un consumo tan alto de CPU que a veces no podía ni conectarme a la máquina para poder administrarla.

Cuando conseguí conectarme y ejecutar un htop (un top mejorado) había una gran cantidad de procesos de Apache, que por separado consumían pocos recursos pero todos juntos estaban tirando la máquina.

Al detener el servicio de Apache pude ver que la máquina se estabilizaba; es decir, algo estaba sobrecargando el servicio de Apache.

Tras analizar la últimas entradas del log había una gran cantidad de peticiones por segundo desde diferentes IP que ejecutaban

“POST /xmlrpc.php HTTP/1.1”

Este ataque es conocido desde hace tiempo y se aprovecha de una funcionalidad de WordPress que implementa XML-RPC.

La solución es sencilla, y simplemente hay que desabilitar la llamada al PHP xmlrpc.php mediante una configuración de Apache en el .htaccess en cada uno de los sitios creados con WordPress:

# protect xmlrpc
<Files xmlrpc.php>
Order Deny,Allow
Deny from all
</Files>

Si quieres habitar alguna IP para poder usar las funcionalidades del xmlrpc.php simplemente hay que permitir el acceso a esas IP:

# protect xmlrpc
<Files xmlrpc.php>
Order Deny,Allow
Deny from all
Allow from 11.22.33.44
Allow from 55.66.77.88
</Files>

Sobre los sistemas automáticos de seguridad en el transporte ferroviario

Me imagino que tendréis información de sobra sobre el accidente ferroviario ocurrido en la tarde del 24 de julio cerca de Santiago de Compostela. Parece que el descarrilamiento del tren se debió al exceso de velocidad al tomar la curva. Los medios de comunicación, con sus habituales todólogos, ya se están encargando de lapidar al maquinista (me recuerda a la mítica portada de la mirada del asesino que no era), por lo que yo casi que paso de analizar nada de esto. No me voy a poner a analizar los sistemas ERTMS, ASFA, incompatibilidades entre ellos, ausencia,…

Solo quiero dejar una reflexión/pregunta: ¿Cómo es posible que en el año 2.013, en el que ya es legal que un coche circule sin conductor o un avión aterrice con control automático, con las ingentes cantidades de dinero que se invierten en el transporte ferroviario, sea posible que un error humano pueda provocar una catástrofe como ésta y que no esté todo automatizado para reducir la velocidad, detener el tren o tomar las medidas de seguridad adecuadas? Al final pagará el maquinista del tren, pero las responsabilidades deberían de buscarse mucho más arriba, sobre todo en los técnicos y políticos que permiten estas situaciones.