Publicado el

Cómo configurar un registro SPF

emailSPF, o Sender Policy Framework, es un estándar usado para verificar que los correos electrónicos enviados desde un determinado dominio, proceden de servidores de correo autorizados para dicho dominio.

Es decir, con telnet (u otros métodos), podríamos enviar un mail usando cualquier dirección de correo electrónico como origen. Así por ejemplo, yo podría enviar un mail haciéndome pasar por [email protected], o [email protected]. Aquí (y en muchos otros sitios) explican cómo.

El registro SPF, pues, sirve para ayudar a determinar a un servidor de correo, si el mail que acaba de recibir ha de descartarse o entregarse en el inbox.

Continuar leyendo «Cómo configurar un registro SPF»

Publicado el

Instalar yum en Red Hat 4

old manBueno, hoy me he encontrado con un (muy) antiguo server Red Hat 4 que no tenía yum instalado. Hace un tiempo ya me pasó algo parecido, así que he decidido crear un post para documentar cómo lo solucionamos.

Lo primero es verificar que no tenemos yum instalado. Para eso, como root, podemos ejecutar:

[root@myOldServer ~]# yum
bash: yum: command not found
[root@myOldServer ~]# whereis yum
yum:
[root@myOldServer ~]# rpm -q yum
package yum is not installed

Posteriormente, nos aseguramos de la versión y la arquitectura de nuestro servidor, para saber qué paquetes exactos necesitaremos:

[root@myOldServer ~]# uname -m 
x86_64
[root@myOldServer ~]# cat /etc/redhat-release 
Red Hat Enterprise Linux ES release 4 (Nahant Update 6)

Continuar leyendo «Instalar yum en Red Hat 4»

Publicado el

VLANs y múltiples alias de red en Red Hat 6

networking vlanPara poder trabajar con VLANs tageadas en un servidor Red Hat Enterprise 6.0 con múltiples alias de red, tendremos que esforzarnos un poco. En mi caso, he partido de un servidor con una única tarjeta de red (eth0) configurada con 10 alias, todo IPs del mismo rango, del siguiente estilo:

eth0:0 192.168.1.2
eth0:1 192.168.1.3
...
eth0:10 192.168.1.12

Por supuesto, el servidor contaba con un default gateway configurado en cada uno de los alias:

GATEWAY=192.168.1.1

Con este servidor en producción, y con mucho sudor frío, he pasado a configurar el rango 10.0.0.2-10.0.0.25 en el servidor, con default gateway 10.0.0.1, todo perteneciente a la VLAN 30, y todo tageado, también usando la misma interfaz eth0, y lo más importante, manteniendo la configuración de red original (es decir, acabaremos teniendo el servidor configurado para trabajar con 2 rangos de IPs diferentes, uno de ellos perteneciente a la VLAN 30).

Por cierto, si estás pensando en seguir los pasos aquí descritos en un servidor en producción, te recomendaría testearlos primero en un entorno de test, y tener un plan B para recuperar la conectividad con el servidor en caso de cometer algún error.

Continuar leyendo «VLANs y múltiples alias de red en Red Hat 6»

Publicado el

Backups en un Cluster MySQL (PXC 5.6)

datacenterDespués de montar un clúster PXC o Galera Cluster (versión 5.6 en servidores CentOS 6.5), igualmente querremos hacer backups de nuestros datos. Para ello, bastará con realizar un backup de uno de los nodos, puesto que todos los nodos contendrán exactamente la misma información. Aunque en realidad no es tan fácil…

Problemas con los backups en un cluster Galera

Hemos de tener en cuenta que los backups, en algún punto, realizarán un FLUSH TABLES WITH READ LOCK, que hará que ese nodo no permita escrituras y por tanto, no se podrán realizar escrituras en el cluster durante ese tiempo [Fuente 1 y Fuente 2]. La explicación es que una escritura al cluster devolverá ok cuando se haya replicado a todos los nodos del mismo. Por tanto, si un nodo no puede escribir, todo el cluster no podrá escribir.

A ésto hay que sumarle que por defecto un backup en PXC/Galera no guardará los «Global Transaction ID«, necesarios para poder dar de alta nuevos nodos de forma rápida (ahorrándonos el SST inicial) a raíz de ese backup. [Fuente, transp. 44]

Continuar leyendo «Backups en un Cluster MySQL (PXC 5.6)»

Publicado el

Fecha de creación de un fichero en Linux

timeHace un tiempo tuve la necesidad de ver la fecha de creación de un fichero en un servidor Linux. Conocía las fechas atime, ctime y mtime, pero no tenía muy claro cómo ver la fecha en la que el fichero se creó, puesto que por defecto, la salida del comando «ls -l» muestra la fecha de modificación del mismo.

Finamente he llegado a un blog donde explican perfectamente cómo sacar la crtime (o CReation Time). La idea es usar el comando «stat» con «debugfs». Para ello, primero tenemos que tomar como referencia la raíz del sistemas de ficheros que contiene el archivo a inspeccionar.

Continuar leyendo «Fecha de creación de un fichero en Linux»

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

Gitolite: gestión de permisos en Git

gitEs muy posible que queramos tener un control de usuarios y permisos en nuestro repositorio git centralizado, si por ejemplo, tenemos a varios equipos de varios desarrolladores trabajando cada uno con un repositorio diferente. Afortunadamente, existen varias soluciones a este problema pero yo me he quedado con gitolite, por su facilidad de gestión y sus posibilidades.

NOTA: En este post se irá cambiando del servidor (miServer) a mi PC local (miPC). Se irá comentando a lo largo del post a qué entorno se hace referencia, pero si te pierdes, fíjate en el inicio de cada comando ejecutado (ej: [root@miServer ~] vs [adri@miPC])

Instalación

Añadimos el repositorio EPEL para nuestro servidor con el repositorio central, un CentOS 6:

[root@miServer ~]# wget http://dl.fedoraproject.org/pub/epel/6/x86_64/epel-release-6-8.noarch.rpm
[root@miServer ~]# rpm -Uvh epel-release-6-8.noarch.rpm

Instalamos git y a posteriori gitolite, que en mi caso, me ha instalado y/o actualizado bastantes paquetes, la mayoría relacionados con perl:

[root@miServer ~]# yum install git gitolite3.noarch

A continuación, crearemos un usuario de sistema, para gitolite, al que en el ejemplo hemos llamado «git», y que será el usuario de sistema con el que interactuarán los usuarios con el repo:

[root@miServer ~]# useradd --system --shell /bin/bash --home /home/git git

Continuar leyendo «Gitolite: gestión de permisos en Git»

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

RDNS PTR IPv6 en AWS Route53

Cloud Amazon Route53Título duro y críptico donde los haya, pero si estás aquí es por una razón: quieres saber cómo configurar una zona Reverse DNS donde crear tus registros PTR de tus direcciones IPv6 con Amazon Route 53.

Primero de todo, para poder gestionar tú mismo los registros PTR, deberás confirmar que te pueden delegar la gestión del RDNS. Para ello, deberás confirmar con tu ISP que efectivamente, te puede delegar la gestión de los RDNS de tu rango de IPs públicas, ya que en otro caso, no podrás auto-gestionarte el RDNS.

Reverse Zone Name

Tras confirmar que el ISP nos podrá delegar la gestión del RDNS, lo primero que haremos, será pedirle a nuestro ISP que nos dé el nombre de la reverse zone que deberemos crear. El nombre de la zona, será la parte fija de nuestra IP pública, al revés, acabada en «.ip6.arpa». Ejemplo:

IPv6 range: 1234:5678:9ABC::/48
Reverse zone name: C.B.A.9.8.7.6.5.4.3.2.1.ip6.arpa

Con estos datos ya podremos entrar en el panel de AWS para la gestión de Route53.

Continuar leyendo «RDNS PTR IPv6 en AWS Route53»

Publicado el

Configuración de IPv6 en CentOS

IPv6Vamos a ver cómo configurar un servidor para trabajar tanto con ipv4 como con ipv6, en Linux, sin entrar en detalle de lo que es ipv6, pero repasando algún que otro concepto.

Formato de una dirección IPv6

Lo primero, una ipv6 es una ip formada por 8 grupos de 4 dígitos hexadecimales cada uno, tal que así:

AAAA:AAAA:00BB:AAAA:0000:0000:0000:0000

Se pueden omitir los 0’s de inicio de cada grupo. Así, la IP anterior, quedaría así:

AAAA:AAAA:BB:AAAA:0000:0000:0000:0000

También se puede dejar de incluir los grupos que sean todo 0s, símplemente indicándolo con «::». Hay que tener en cuenta, que únicamente podremos usar una vez el «::» puesto que en otro caso, no sería posible saber a cuantos grupos de ceros se refiere el «::». En nuestro caso, la ipv6 quedaría así:

AAAA:AAAA:BB:AAAA::

Decir que podemos usar cualquiera de éstos formatos para indicarle una ipv6 a nuestro servidor.

Continuar leyendo «Configuración de IPv6 en CentOS»