Publicado el

Medidas de seguridad en WordPress

seguridadWordPress va genial, pero todo sea dicho, también puede ser un coladero si no se ponen medidas para hacerlo seguro. A continuación listo algunas de las medidas que se podrían aplicar para empezar a hacer de nuestro site, un sitio más seguro.

1. Eliminar el usuario «Admin»

Si vas a instalar un WordPress de cero, no uses «admin» como nombre de usuario. Tampoco «root» ni «administrador» ni cosas así. Si en su momento instalaste WordPress con el usuario «admin», lo mejor es que crees un nuevo usuario con permisos de Administrador (ésto puedes hacerlo fácilmente desde el panel de control de WordPress) y una vez creado, te loguees con tu nuevo usuario y elimines el usuario «admin». Tranquilo, al borrar el usuario te pedirá si quieres conservar los posts escritos por «admin» y a qué otro usuario atribuírselos. Sólo con ésto te evitarás más de un dolor de cabeza.

Ah, también ayuda usar un password complejo, a ser posible una combinación de mayúsculas, minúsculas, números y carácteres alfanuméricos.

Continuar leyendo «Medidas de seguridad en WordPress»

Publicado el

Actualizar automáticamente un servidor

updateÚltimamente he estado leyendo sobre cómo y cuando actualizar un servidor Linux (Fedora/CentOS/Red Hat en mi caso), de cara a aplicar los últimos parches de seguridad y mantener el sistema actualizado. Resulta que no soy el único que se pregunta sobre si hay algún tipo de guía, recomendaciones, o mejores prácticas para updatear sistemas.

Después de leer y leer, y ver las numerosas razones tanto a favor como en contra de los updates automáticos, la siguiente frase en la documentación oficial de Fedora resume cuándo habilitar las actualizaciones automáticas, por lo general:

«If the machine is a critical server, for which unplanned downtime of a service on the machine can not be tolerated, then you should not use automatic updates. Otherwise, you may choose to use them.»

Es decir, por norma general sería una buena idea habilitar las actualizaciones automáticas en todo servidor que no sea crítico, siempre y cuando tengamos la posibilidad de deshacer los updates instalados, o revertir los cambios, en caso de error.

Continuar leyendo «Actualizar automáticamente un servidor»

Publicado el

Maldet – Linux Malware Detect

virusMaldet (también conocido como LMD de las iniciales de Linux Malware Detect) es un detector de malware para entornos Linux compartidos, bajo licencia GNU GPLv2, que funciona desde el terminal.

Instalación

Podemos instalar Maldet de la siguiente manera:

1. Bajaremos el tarball de la página oficial:

[root@miServer tmp]# wget http://www.rfxn.com/downloads/maldetect-current.tar.gz

2. Descomprimiremos e instalaremos

[root@miServer tmp]# tar -zxcvf maldetect-current.tar.gz
[root@miServer tmp]# cd maldetect-1.4.2/
[root@miServer tmp]# ./install.sh

3. Ya estaremos listos para usar Maldet

Continuar leyendo «Maldet – Linux Malware Detect»

Publicado el

VPN entre dos servidores con openVPN

openvpntech_logo1Hoy vamos a montar una VPN entre dos servidores ubicados en dos CPDs distintos, para que puedan comunicarse entre ellos a través de un canal seguro. En mi caso, he usado el túnel VPN (Full TLS) para conectar dos servidores MySQL que replican los datos el uno del otro. De esta forma, los datos que se replican de la base de datos viajan por Internet a través de un canal privado y seguro.

He hecho las pruebas en el siguiente entorno:

  • OpenVPN 2.3.2 x86_64-redhat-linux-gnu

Un servidor CentOS 6.4 con 512MB de RAM, instancia de RackSpace (sí, 512MB de RAM, y estamos en 2013, sí).

  • Hostname: vpntest1
  • IP pública: 80.80.80.81
  • IP privada: 10.10.10.81

Un segundo servidor CentOS 6.4 con 512MB de RAM, instancia de RackSpace en un CPD diferente.

  • Hostname: vpntest2
  • IP pública: 80.80.80.82
  • IP privada: 10.10.10.82

Por defecto, los servidores vienen con selinux deshabilitado, iptables parado, y no pueden hacer ping entre sí mediante sus ips privadas pero sí mediante sus ips públicas. He seguido, en mayor parte, este fantástico tutorial que han hecho los técnicos de Rackspace.

También es importante configurar ntp en ambos servidor, para que tengan la hora sincronizada.

Continuar leyendo «VPN entre dos servidores con openVPN»

Publicado el

Monitorizar upload FTP desde script

Upload FTP¿Cómo podríamos saber si un fichero que está siendo subido por FTP ha acabado o no de subirse? Hay algunas posibles soluciones en esta conversación de SuperUser.com, la última de las cuales, es la que he usado.

Para los testeos, he usado un servidor vsFTPd (configurado tal y como expliqué aquí) sobre un servidor CentOS 5.4. Como no tenía ficheros grandes para hacer el test, he creado uno de forma instantánea, con el siguiente comando:

[root@adripc]# fallocate -l 100M test.img
[root@adripc]# ls -lah test.img
-rw-r–r– 1 root root 100M Jul 18 10:20 test.img

La idea es usar lsof para saber el PID del proceso de vsFTPd que está siendo usado para subir el fichero destino, y entoces monitorizar ese PID.  El problema que me he encontrado, al menos con el entorno de test que he usado, es que ese PID de subida puede cambiar durante la subida. No sé bien bien porqué razón, pero en mi caso cambia. Si cambia el PID entonces ya no podremos monitorizar ese PID, ya que el PID habrá finalizado (o no) pero no así la subida, que estará usando otro PID diferente.

En este caso, la solución es más sencilla aun, ya que bastará con símplemente ir consultando mediante lsof y en caso de devolver vacío, nos indicará que no hay ningún proceso usando el fichero y que por tanto, la subida ha finalizado. Así, nos dará igual que el PID cambie. Lo único importante es que durante la subida del fichero, ese archivo tendrá un PID asociado, mientras que cuando haya acabado el upload, no tendrá ningún PID y por tanto lsof devolverá vacío.

Continuar leyendo «Monitorizar upload FTP desde script»

Publicado el

Instalar SO remotamente con IPMI

remoteLas interfaces IPMI de los servidores Supermicro, nos permiten gestionar remotamente un servidor aun cuando éste está apagado, o como en el caso que nos ocupa hoy, incluso nos permiten hacer instalaciones remotas de sistemas operativos.

La idea es simple: la interfaz IPMI tiene autonomia propia, independientemente del estado del propio servidor. Así pues, podemos conectar vía web con la interfaz IPMI del servidor, y configurar en Virtual Media > CD-ROM Image, la ruta donde almacenaremos la imagen ISO con el sistema operativo. Esta imagen, deberemos almacenarla en un segundo servidor al cual se pueda acceder desde la interfaz IPMI (típicamente un servidor ubicado en la misma red).

Las pruebas han sido realizadas con una interfaz IPMI con las siguientes características:

  • Firmware Revision: 02.15
  • Firmware Build Time: 2013-01-18

El servidor donde se ha alojado la imagen, ha sido un servidor CentOS sin samba préviamente instalado. Así pues, ha sido necesario instalar y configurar samba para permitir el acceso a la ISO desde la interfaz IPMI. Si se tuviera un servidor Windows, este apartado se haría de forma diferente.

Continuar leyendo «Instalar SO remotamente con IPMI»

Publicado el

Nagios, añadir contacto/usuario

Apache HTTPEn ocasiones, es posible que se quiera que un determinado usuario reciba notificaciones de una máquina determinada monitorizada por nagios. Para ello, se podrá crear un nuevo contacto, asociado a la máquina de la cual se quiere que dicho contacto reciba alertas.

En primer lugar, se deberá crear el nuevo contacto, siguiendo la plantilla de contactos, contacts.cfg:

define contact{
contact_name username
use generic-contact
alias Nuevo Usuario
email [email protected]
}

Continuar leyendo «Nagios, añadir contacto/usuario»

Publicado el

Configuración básica de Apache

httpd ApacheEn este post se trata de dar una idea de los que pueden ser los primeros pasos a dar tras la instalación de un servidor Apache con PHP.

/etc/php.ini

En primer lugar, podríamos mirar el archivo de configuración del php en busca de las líneas correspondientes a la gestión de la visualización de los mensajes de error. Se recomienda que ambos parámetros estén a Off si se quiere evitar que tras un error en el servidor, se le muestre al usuario el código relativo al error, o incluso el fragmento de código php que lo ha provocado:

display_errors = Off
display_startup_errors = Off

Continuar leyendo «Configuración básica de Apache»

Publicado el

Cómo hacer SSH más seguro

Apache HTTPHay muchos posts en Internet hablando sobre cómo configurar SSH de forma correcta, para tener un entorno seguro; éste es otro de ellos.

La configuración de ssh en la máquina a la que queremos conectar, en entornos tipo Red Hat, se encuenta en /etc/ssh/sshd_conf. En este fichero de configuración, podremos realizar varias modificaciones para intentar tener un entorno SSH más seguro, como por ejemplo las que se describen a continuación:

Cambiar el puerto de acceso por defecto

Por defecto SSH usa el puerto 22, cambiando el puerto por otro conseguimos añadir una traba extra para alguien que quiere acceder a nuestro server a través de SSH, puesto que el puerto por defecto no responderá. Se recomienda usar uno mayor al 1024, por estar del 1 al 1024 reservados.

Port 12503

Continuar leyendo «Cómo hacer SSH más seguro»

Publicado el

Mysqlhotcopy

Para realizar backups de bases de datos MySQL, se suele usar el comando mysqldump. Este comando, se encarga de generar las consultas necesarias para recrear toda la estructura de tablas y su contenido, a base de sentencias SQL. Sin embargo, este comando, puede resultar muy lento, para bases de datos grandes.

Si se quiere hacer un backup de una base de datos con tablas MyISAM, desde la propia documentación oficial de MySQL se insta a usar mysqlhotcopy en lugar de mysqldump:

«If you are doing a backup on the server and your tables all are MyISAM tables, consider using the mysqlhotcopy instead because it can accomplish faster backups and faster restores»
Fuente: aquí

Continuar leyendo «Mysqlhotcopy»