Configuración inicial de un servidor CentOS

5 febrero 2015 at 13:07 by Adrián Pérez

centosHace ya unos años, y sin ningún software de administración tipo Puppet/Chef/Ansible, creamos un documento para que todos los técnicos pudieran decir la suya respecto a los pasos a dar tras instalar un sistema operativo Linux (CentOS en nuestro caso), con tal de no olvidarnos ninguno e ir mejorando entre todos este proceso de configuración inicial de un servidor. Eso significa que si tú, amado lector, tienes cualquier sugerencia de mejora, no dudes en dejarla en los comentarios.

Hoy en día, ese documento, muy pensado para instalaciones CentOS 6, tanto en entornos Cloud Computing como para en máquinas propias, es algo parecido a lo que listo a continuació.

NOTA: No te tomes todos los puntos al pie de la letra, seguramente querrás valorar si lo que propongo a continuación tiene sentido en tu entorno antes de aplicarlo, y seguro que más de un punto es mejorable.

1. Actualización del SO

Tras la instalación, es una buena idea forzar un update para estar a la última de los paquetes de nuestro SO.

yum update

2. Deshabilitar selinux

Selinux es una herramienta útil, pero que no compensa, y proporciona más dolores de cabeza de los que pretende solucionar. Es por eso que proveedores como RackSpace o Hetzner proveen sistemas con Selinux deshabilitado de fábrica. Si aún así quieres trabajar con Selinux, seguramente este sea el momento de configurarlo adecuadamente. En caso contrario, símplemente deshabilitalo tal y como sigue:

vi /etc/selinux/config
SELINUX=disabled

Tras deshabilitarlo, será necesario reinciar el sistema para activar los cambio. Así pues, reinicia para evitar tener problemas con los próximos pasos.

Medidas de seguridad en WordPress

16 octubre 2014 at 10:24 by Adrián Pérez

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.

Actualizar automáticamente un servidor

12 marzo 2014 at 12:09 by Adrián Pérez

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.

Maldet - Linux Malware Detect

26 febrero 2014 at 16:34 by Adrián Pérez

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

VPN entre dos servidores con openVPN

2 octubre 2013 at 16:02 by Adrián Pérez

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.

Monitorizar upload FTP desde script

19 julio 2013 at 11:11 by Adrián Pérez

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.

Instalar SO remotamente con IPMI

29 mayo 2013 at 19:31 by Adrián Pérez

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.

Nagios, añadir contacto/usuario

13 julio 2012 at 12:10 by Adrián Pérez

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 nuevo.usuario@mimail.com
}

Configuración básica de Apache

24 abril 2012 at 19:13 by Adrián Pérez

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

Cómo hacer SSH más seguro

13 febrero 2012 at 13:04 by Adrián Pérez

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