A continuación un ejemplo práctico para limitar el acceso a ciertas rutas, en función de la IP de origen.

En este caso se limitará el acceso al sistema de login de Spacewalk, para ello creé el archivo /etc/httpd/conf.d/zzz-spacewalk-security.conf con el siguiente contenido:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

<Location /rhn/LoginSubmit.do*>
        Order deny,allow
        Deny from all
        Allow from localhost
        Allow from NBMAD001.my-company.com
</Location>
 
<Location /rhn/ReLoginSubmit.do*>
        Order deny,allow
        Deny from all
        Allow from localhost
        Allow from NBMAD001.my-company.com
</Location>
 
<Location /rhn/help/*>
        Order deny,allow
        Deny from all
        Allow from localhost
        Allow from NBMAD001.my-company.com
</Location>

Cuando un servidor está detrás de un proxy, la IP del cliente que ve el servidor es la IP del proxy. Si bien esto no afecta directamente al servicio, no es útil por varias razones como por ejemplo:

1. En los logs no se registra la IP correcta del cliente.
2. No es posible implementar ningún sistema, basado en IP, para limitar los ataques de fuerza bruta contra el sistema de login.
3. Si desea usar usar algún módulo de localización geográfica como por ejemplo el módulo ngx_http_geoip_module de NIGNX.

Para lograr esto, es necesario:
1.- Usar el parámetro real_ip_header, del módulo ngx_http_realip_module de NGINX, para modificar la cabecera que contiene la IP del cliente.
2.- Configurar HAProxy para que añada la cabecera X-Forwarded-For o X-Real-IP.
3.- Configurar NGINX para que reemplace el parámetro fastcgi REMOTE_ADDR con la IP de la cabecera X-Forwarded-For o X-Real-IP.

Aprovechando que he montado un nuevo volumen Raid1 con dos discos duros Hitachi HGST_HTS721010A9E630 en mi servidor personal en Madrid he decidido migrar algunos contenedores desde el viejo volumen en Western Digital, especialmente porque el throughput del nuevo volumen de discos Hitachi es muy superior al volumen con discos Western Digital.

En algunos casos he optado por hacer instalaciones limpias, en lugar de mover el contenedor de volumen; como por ejemplo el contenedor que corre el nodo de NexctCloud en Madrid. Así que he aprovechado la ocasión para documentar el proceso en forma de post.

Algunas Consideraciones previas:

1. El servicio de NextCloud está clústerizado en los nodos Madrid/Sevilla. Aunque debido a que la línea de Madrid es mucho mejor (300MB/300MB frente a 30MB/3MB), no se hace balanceo; por defecto todo el tráfico es enrutado hacia el nodo de Madrid, por lo que a efectos prácticos el servicio no dispone de alta disponibilidad (se precisa intervención humana para cambiar la DNS).
2. Las comunicaciones entre los nodos de Madrid y Sevilla tiene lugar a través de un túnel VPN montado con OpenVPN.
3. La base de datos es un clúster multimaster de MariaDB 10.1 con un nodo en Madrid y otro en Sevilla además de un Árbitro en Madrid para evitar situaciones de split-brain. Lo idóneo sería contar con una tercera ubicación donde colocar el Árbitro, aunque de momento con este sistema no he tenido problemas en 2 años a pesar de tener numerosas caídas, especialmente del nodo de Sevilla.
4. El clúster multimaster de MariaDB esta alojado en otro contenedor, por lo que solo es necesario permitir el login desde la IP del nuevo contenedor de NextCloud; es decir, este punto no se toca en está entrada.
5. La replicación a nivel de archivos se consigue a través de GlusterFS, con un brick en Madrid y otro en Sevilla.
6. Los nodos del GlusterFS corren dentro del propio contenedor de NextCloud. Para evitar la caída del servicio se añadirá un nuevo nodo al clúster de GlusterFS, y una vez el nuevo servidor este configurado, sincronizado y operativo se eliminará el viejo nodo.
7. Redis se usa como cache local para gestionar los bloqueos transaccionales, es decir, no existe un clúster de Redis por los motivos expuestos en el punto 1.

El cliente SSH por excelencia para Windows es PuTTy, el cual usa certificados en formato PPK, esto no es un problema en si mismo pero si un poco engorroso cuando los usuarios solicitan acceso a un servidor y te adjuntan su llave pública ¡en formato PPK!

Es cierto que puedes usar PuTTYGen para pasar de un formato a otro, pero a mi me resulta muy engorroso. Personalmente veo más fácil y rápido usar ssh-keygen desde consola para transformar certificado PPK a certificado OpenSSH.

El uso es bastante sencillo: ssh-keygen [-i|-e] -f file, donde:

• -i: lee un certificado, público o privado, no cifrado e imprime el equivalente en formato OpenSSH.
• -e: lee un certificado, público o privado, cifrado e imprime el equivalente en formato OpenSSH.
• -f: indica el archivo a leer

Ejemplo:

Esta entrada es una guía para desplegar un clúster de MariaDB en CentOS 7, aunque es aplicable para cualquier otra distribución (Debian, Ubuntu, Suse…).

Añadir el repositorio de MariaDB

El primer paso es agregar el repositorio de la versión de MariaDB y para la distribución donde se hará el despliegue, en este caso de MariaDB 10.1 para CentOS 7.

1
2
3
4
5
6
7
8
9

cat << EOF >> /etc/yum.repos.d/MariaDB.repo
# MariaDB 10.1 CentOS repository list
# http://downloads.mariadb.org/mariadb/repositories/
[mariadb]
name = MariaDB
baseurl = http://yum.mariadb.org/10.1/centos7-amd64
gpgkey=https://yum.mariadb.org/RPM-GPG-KEY-MariaDB
gpgcheck=1
EOF

La mayoría de desarrolladores, ¡e incluso algunos DEVOPS!, tienen la horrible costumbre de desactivar la verificación de certificados mediante git config http.sslVerify "false" para trabajar con servidores que usan certificados autofirmados y de esta forma evitar los errores del tipo:

1
2
3
4

C:\Users\antonio.guillen\Projects
λ git clone https://git.my-company.com/antonio.guillen/pymagit.git
Cloning into 'pymagit'...
fatal: unable to access 'https://git.my-company.com/antonio.guillen/pymagit.git/': Peer's certificate issuer has been marked as not trusted by the user.

Este post no tiene por objetivo enumerar los posibles problemas que puede traer desactivar las comprobación de certificados, saludos man-in-the-middle, sino indicar la forma correcta de trabajar en estas circunstancias. Y no, ejecutar git config http.sslVerify "false", no es la forma correcta de trabajar.

Java usa un almacén de Autoridades Certificadoras (CA), Java trustStore, que es mantenido por la Java Development Kit (JDK). Cuando una aplicación Java se conecta a un servicio SSL/TLS, lo primero que hace es comprobar si el certificado está firmado por alguna de las CA albergadas en la trustStore. En caso de que el certificado no pueda ser validado por la trustStore en los logs se registrará un error similar a PKIX path building failed... unable to find valid certification path to requested target.

Para comprobar si, efectivamente, los problemas de conexión se deben a la falta de una CA en la trustStore, se puede usar la clase de Java SSLPoke en dos sencillos pasos:

1. Descargar SSLPoke.class
2. Ejecutar java SSLPoke host port

A continuación un ejemplo, usando SSLPoke para validar una trustStore que aun no contiene la correspondiente CA.:

El método oficial para recuperar el acceso como administrador de SQL Server es:

1. Logar con la cuenta de administrador local.
2. Detener la instancia de SQL Server.
3. Iniciar la instancia en modo de usuario único.
4. Cambiar la contraseña de sa o agregar al rol de sysadmin cuentas de usuarios del dominio o locales.

Mediante consola

Si el servidor donde está instalado el SQL Server carece de interfaz gráfica, o simplemente prefieres la consola:

1. net stop MSSQLSERVER$InstanceName, para detener la instancia InstanceName.
2. net start MSSQLSERVER$InstanceName /m, para iniciar la instancia InstanceName en modo de usuario único.
3. SQLCMD -S ServerName\InstanceName, para conectar a la instancia InstanceName del servidor ServerName. El binario de SQLCMD.EXE se suele localizar en C:\Program Files\Microsoft SQL Server\MSSQL11.MSSQLSERVER\MSSQL\Binn.
4. Cambiar la contraseña de sa o crear un nuevo usuario sysadmin:
   • ALTER LOGIN sa WITH PASSWORD = 'NewPassword';, para cambiar la contraseña del usuario sa por NewPassword.
   • Crear un usuario y añadirlo al rol de sysadmin del SQL Server:
     • CREATE LOGIN [MyCompany\username] FROM WINDOWS;, para crear el login para el usuario username del dominio MyCompany.
     • ALTER SERVER ROLE sysadmin ADD MEMBER [MyCompany\username];: otorgar el rol de sysadmin al usuario username del dominio MyCompany.
5. net stop MSSQLSERVER$InstanceName y net start MSSQLSERVER$InstanceName, para detener y volver a iniciar la instancia en modo multiusuario.

Conceptos

El charset es un conjunto de símbolos y codificaciones, es decir, la forma en que la base de datos guarda internamente los datos. Mientras que el collation es el conjunto de reglas que se aplican para comparar caracteres en un charset, es decir, indica a la base de datos como debe comparar los datos.

A continuación hago una traducción libre de un extracto de la documentación de MySQL Character Sets and Collations in General:

Suponga que tenemos un alfabeto de cuatro letras: A, B, a, b. Asignamos a cada letra un número: A = 0, B = 1, a = 2, b = 3. La letra A es el símbolo, el número 0 es el código para A y la combinación de las cuatro letras y sus códigos es el juego de caracteres (charset).

Suponga que queremos comparar dos cadenas de valores, A y B. La forma más sencilla de hacerlo es mirar sus códigos: 0 para A y 1 para B. Como 0 es menor que 1, diremos que A es menor que B. Lo que acabamos de hacer, es aplicar un collation a nuestro charset. El collation es un juego de reglas (en este caso solo una): “campara los códigos”. Llamamos a este collation, el más simple de todos los collation posible, collation binario (binary collation).

Pero, ¿qué ocurre si queremos decir que las minúsculas y las mayúsculas son equivalente? Entonces nosotros tenemos al menos dos reglas: (1) tratar la letras minúsculas a y b como equivalente de A y B; (2) compara los códigos. Llamamos a este collation insensible a mayúsculas y minúsculas (case insensitive) y es un poco más complejo que un binary collation.

El servicio de Directorio Activo es un servicio distribuido que precisa que los clientes deben ser capaces de descubrir de forma dinámica los DC (Domain Controller). Este proceso de localización de los DC se puede realizar mediante dos tipos de protocolos:

• Protocolos que hacen uso de broadcast, como NetBIOS y mailslot. Nota: Es normal que la difusión de los broadcast esté limitada en grandes redes.
• Protocolos que no hacen uso de broadcast, como DNS y LDAP.

En ambos casos, el proceso de descubrimiento es similar y se divide en dos fases:

1. Los DC publican información sobre ellos mismos mediante DNS o NetBIOS.
2. Los clientes buscan esta información para determinar los posibles DC y envían mensajes, LDAP ping o mailslot ping, para determinar la disponibilidad de los mismos.