seguridad, mfa y demás hierbas

Aún recuerdo la primera contraseña que utilicé en serio. Fue para la cuenta en el servidor Unix de la universidad y tenía ocho caracteres que formaban una palabra que no podía deducirse de mi persona. Me sentía completamente seguro. Luego aprendes lo que de verdad significa la seguridad aplicada a la tecnología y los sistemas informáticos y recuerdas aquella primera contraseña con cariño.

Y llega el día en que una buena contraseña (+50 caracteres de todo tipo) ya no es suficiente y descubres la autenticación con dos factores (o 2FA).

usando factores de autenticación

La autenticación con múltiples factores, un escalón por encima de la 2FA implica utilizar dos o más evidencias (o factores) para autenticar a alguien. Las opciones son: conocimiento, algo que sabe, como una contraseña; posesión, algo que tiene; e inherencia, algo que se es.

Contándolo rápidamente y usando el ejemplo de una cuenta de email, el 2FA sería utilizar dos factores, es decir, un factor más además de la contraseña (ese algo que conoces) para verificar que, efectivamente, eres quien dices ser. Así, podemos usar algo que tenemos o algo que somos. Como personalmente estoy en contra del uso de medidas de autenticación biométricas (a ver como cambias de iris…), usaremos algo que tenemos, algo como una contraseña temporal u OTP.

la app de google

Hace ya tiempo que google (quién sino) sacó una app para darte todas las contraseñas temporales que necesitases y, de paso, para que asegurases tu email a la vez que te liaban un poco más en su ecosistema de móvil, apps, email, calendarios y cualquier tipo de servicio que puedas imaginar. Esta app, google authenticator, validaba tu acceso dándote un número de seis cifras que tienes que introducir cada vez que accedas a tus cuentas. Todo muy seguro.

Y parecía que si querías usar un segundo factor de autenticación, o bien ponías tu número de teléfono en todas partes para que te enviasen un email o estabas fuera. Porque si intentas salir del yugo de google, terminar instalando una app así es un gran paso atrás. También hicieron una app para chrome pero, de nuevo, como utilizo firefox no podía usarla.

gauth

El truco radica en que el algoritmo sobre el que descansa la app es público y está perfectamente definido en el RFC 6238 y cualquiera puede usarlo. Tanto es así que un tal Gerard Braad se hizo su propio autenticador de dos factores, lo llamó gauth authenticator y lo publicó en github. Y, no contento con eso, hizo apps para firefox, firefox os, chrome, chromeOS, webOS y android.

Gauth almacena la información de la clave (la descriptción y la clave secreta) en la cache del navegador y lo vincula al perfil con lo que si cambias de navegador, de dispositivo o entras en el modo anónimo, las claves serán diferentes.

uso y disfrute

A mi, con mi tontería, se me han ocurrido tres formas de usar gauth en todos mis dispositivos porque claro, no voy a instalar una app en el móvil o en chrome para tener TOTP. Para disfrutar de la experiencia completa, recomiendo usar un gestor de contraseñas donde guardar los MFA. En mi caso concreto, utilizo keepass y tengo los ficheros en mi nube privada, disponibles desde cualquier lugar.

1. usa la web de gauth

Tan sencillo como eso, accedes a la web de gauth, introduces la clave (obviamente, no es una buena idea meter una descripción muy profusa) y ya puedes tener tu código.

2. instala el código en tu servidor

Te hace falta un dominio, un puñado de bytes disponibles y un git clone. Yo, además, le puse autenticacion extra usando el .htaccess. Una vez hecho esto, accedes a la URL de tu servidor y configuras las claves.

3. <modo paranoico on>

Esta opción también la uso para las claves que necesito en el móvil y con algunas del trabajo, aquellas que considero que merecen especial protección. Consiste en descargarme el código y descomprimirlo en local, ya sea el ordenador o el móvil. Obviamente, los dispositivos donde hago esto tienen el almacenamiento cifrado, ya ni lo considero una medida extra sino que va de serie.

Una vez instalado gauth en local, lo abro desde Firefox y añado las claves. Es lo más parecido a un google authenticator casero que he podido emular.

conclusiones

La única conclusión posible es que, en un mundo tan digitalizado y accesible, que tus datos dependan de una contraseña que seguramente es demasiado sencilla de averiguar es un riesgo.

 

instalando mattermost en debian stretch

¡Me encanta el olor a software libre por las mañanas! Y más cuando una aplicación privativa que me gusta se vuelve un dolor de muelas por sus restricciones. Entonces es el momento de buscar alternativas de software libre.

mis requerimientos

  • open source
  • alternativa a slack
  • multiplataforma: linux, windows, android…
  • sin limitaciones en cuanto a mensajes, ficheros, etc…
  • instalable en un servidor que ya esté funcionando con otros servicios

el caso

Slack, la plataforma para facilitar el trabajo en equipo es una herramienta muy útil pero, cuando llevas un tiempo utilizándola en su versión gratuíta empiezan a aparecer los problemas, como no poder recuperar conversaciones porque has excedido el máximo y sólo te muestra las últimas diez mil. Y un día, sin saber cómo, te encuentras abriendo duckduckgo y buscando 'slack open source alternatives'. Y ahí es cuando descubres Mattermost.

las alternativas

Mattermost es una alternativa a slack pero de software libre, su misión es la misma, su interfaz es terriblemente similar y no tiene las limitaciones de aquella pero no es la única alternativa. Durante un tiempo barajé la opción de zulip pero tiene un requerimiento que choca frontalmente con los míos:

(Zulip Requirements)

Mis servidores son limitados y por eso trato de aglutinar en ellos servicios similares y, en este caso, ni quería ni podía utilizar una máquina para la mensajería.

La única desventaja que le vi a Mattermost es que utiliza nginx como proxy inverso y yo utilizo apache pero se puede cambiar fácilmente, como veremos.

instalación de mattermost

Todo el proceso descrito en esta entrada se ha obtenido de la documentación oficial de Mattermost.

creación de la base de datos

El servidor de bases de datos también está instalado y configurado por lo que únicamente tendremos que crear una base de datos y un usuario nuevos.

Estos datos de conexión se utilizarán más adelante al configurar el Driver de Mattermost.

Mattermos, al fin

Instalaremos Mattermost en /opt y apuntaremos el virtual host de apache2 a ese directorio.

la columna de una tabla es demasiado grande

Si falla y da este error, {"level":"error","ts":1557928148.6244338,"caller":"sqlstore/supplier.go:811","msg":"Failed to create index Error 1709: Index column size too large. The maximum column size is 767 bytes."}, cambiar configuración en mariadb:

apache2

Crear el subdominio matter.example.com apuntando al servidor donde lo vas a instalar. En mi caso, en dicho servidor ya hay un apache funcionando y no necesito instalar software adicional. En caso de utilizar, como recomienda Mattermost, nginx tendría dos servicios operando sobre el mismo puerto y eso no termina bien nunca.

A partir de esta modificación, apache no sólo funcionará como servidor web sino que también hará de proxy inverso para redirigir el tráfico al puerto que escucha Mattermos, el 8065.

Creamos el VirtualHost para Mattermost, en principio vacío y luego, tras solicitar el certificado a letsencrypt, con la configuración de proxy.

Tras ejecutar estos comandos tendremos un nuevo virtual host redirigiendo el tráfico al puerto de Mattermost, adornado con un bonito certificado de Let’s Encrypt.

Configuración de mattermost

Ahora sólo nos queda abrir el navegador en https://matter.example.com y configurar el usuario administrador. También es necesario configurar el servidor de correo según el apartado Configuring Mattermost Server.

 

[Truco] cambiar la contraseña de una partición cifrada en debian stretch

Se nos llena la boca (a mí el primero) diciendo que tenemos que cifrar los dispositivos de almacenamiento, sobre todo los portátiles y los discos duros externos, para luego tener una única contraseña durante toda la vida útil del dispositivo.

En mi trabajo no tengo instalado linux en la estación de trabajo por directrices de la empresa pero, en cambio, sí que tengo una máquina virtual con VirtualBox que utilizo como sistema operativo principal, tanto que tengo un montón de alarmas de vbox para que no le de tantos recursos :-D. La cuestión es que el volumen de esa máquina virtual está cifrado desde el momento en que instalé debian y, pasado cierto tiempo, toca cambiar la frase de paso.

Cambiar la contraseña de LUKS puede hacerse mediante gnome-disks (en el paquete gnome-disk-utility) o, más fácil, desde la consola.

Lo primero es saber sobre qué partición quieres actuar, porque se puede dar el caso de que tengas varias particiones cifradas, incluso con diferentes contraseñas (ese es un nivel de paranoia al que aún no he llegado).

Ese fichero es la base de datos de volúmenes cifrados y, en este caso, sólo hay una partición que manejar, sda5.

A continuación, ejecutamos el comando que cambia la frase de paso sobre la partición correcta:

Cuando dentro de unos meses vuelva a cambiar la contraseña, ya no tendré que buscar más que aquí :-D.

 

[truco] mariadb se va de paseo (MySQL server has gone away)

O dicho en el idioma de los errores de sistema, ERROR 2006 (HY000) at line 21232: MySQL server has gone away.

El lío

mariadb

mariadb

El error me apareció cuando intentaba importar la base de un wordpress en una instalación de MariaDB 10.1.37-0+deb9u1. Tengo que decir que el fichero SQL no es muy diferente al montón de importaciones que he hecho con MySQL, tiene un tamaño aproximado aunque sí que ha habido ficheros varios megas más grandes en el mismo servidor. Lo inusual del error, el que no fuese un error de sintaxis del fichero me hacía sospechar de la configuración de MariaDB.

La solución

Hay que aumentar una variable del sistema que se encarga del tamaño máximo del buffer donde se almacenan los paquetes, max_allowed_packet. Basta con añadir (o modificar) el valor y ponerlo a algo tremendo para que no falle, en este caso, 2 GB.

Tras aplicar el cambio, ya se puede importar sin problema volcados de wordpress o de lo que sea.

 

WordPress Multisite, Let’s Encrypt Wildcard y dominios redirigidos

Inciso: Dabo, te lo dije, te advertí que no pararía hasta terminar sabiendo cómo hacer funcionar esto 🙂

Tengo varias web, varios WordPress y un puñado de dominios. Es, creo yo, lo habitual cuando te mueves por estas aguas y a cada proyecto, idea o viaje místico le asocias un dominio y un espacio en internet. La mayoría no llega a ningún sitio pero eso no es lo importante. Al final, te juntas con un puñado de webs en un WordPress Multisite, con varios dominios apuntando a varios de sus subdominios y con unas ganas locas de ponerles a todas un bonito certificado SSL patrocinado por Let’s Encrypt.

El escenario

example.com es el dominio principal de un WordPress Multisite que alberga una veintena de webs en su propio subdominio, loquesea.example.com y, algunas de ellas, además, tienen un dominio propio que apunta al subdominio. Así tenemos, por ejemplo, example1.com que apunta a ex1.example.com y example2.net que apunta a ex2net.example.com.

Y un día quieres que todos los dominios tengan su propio certificado de Let’s Encrypt y es un problema porque como todos los subdominios dependen del mismo dominio principal y Let’s Encrypt no soporta wildcards, no hay mucho que hacer.

Así que te planteas hacer que sea Apache (2.4) el que se coma el marrón y te pones a mirar cómo hacerlo. El VirtualHost ya tiene declarado el dominio y los subdominios y también cuenta con el certificado para si mismo. Y no encontré la forma de meterle el resto de certificados, ni declarando otros VirtualHosts para que cada dominio tuviese su certificado, ni de ninguna forma.

Al final lo dejas por un tiempo porque no, ni apache es la solución ni Let’s Encrypt soporta wildcards y ya estás bastante cansado de batallar con molinos multisite.

La solución

El 13 de marzo, con dos meses de retraso sobre la fecha previstas, Let’s Encrypt anuncia que soporta wildcards y empiezas con las pruebas.

Primero, el VirtualHost de apache debe reconocer todos y cada uno de los dominios y subdominios, incluídos los dominios asociados:

Luego, se invoca a cerbot con los parámetros adecuados:

Con el parámetro --manual deberemos añadir un registro TXT _acme-challenge con una clave al DNS de cada uno de los dominios especificados para que sean capaces de comprobar que realmente eres el propietario del dominio.

Los dominios a incluir en el certificado se especifican por separado, todos ellos, con un -d, incluyendo el wildcard para los subdominios de example.com.

Se cambia la declaración del certificado porque es un fichero diferente, se reinicia apache y esta parte está lista. Cada dominio y subdominio tiene un certificado nominal válido, firmado por Let’s Encrypt y se puede acceder a cada uno, por HTTP y HTTPS.

En WordPress es una buena idea activar el plugin Really Simple SSL que convierte todas las peticiones HTTP en HTTPS para que todo el contenido esté cifrado.

Bonus track: redirigir las peticiones HTTP a HTTPS

Añadir estas pocas líneas al VirtualHost de apache:

Sólo he necesitado un año y pico y que Let’s Encrypt admitiese los wildcard para poder tener los dominios funcionando a mi gusto. Y si, seguro que hay una docena (o más) de mejores formas de hacerlo pero, sinceramente, no he encontrado ninguna otra.

 

De owncloud a nextcloud y tiro porque me toca…

Tener tu propia nube, ya sea en un servidor casero (de las raspi en adelante) o en algún servidor alquilado, es sencillísimo desde la llegada de Owncloud. De hecho, mi nube cuenta ya con un par de años y más de 20 GB de ficheros a cuestas. Pero desde que me enteré que uno de los fundadores dejaba la empresa que está detrás de la nube (otro ejemplo más de cómo monetizar el software libre) por discrepancias con la dirección de Owncloud Inc. y fundaba nextcloud junto con gran parte de los desarrolladores de la primera, empecé a interesarme por la otra nube.

Hace una semana tuve la oportunidad de instalar una nube en el trabajo y elegí nextcloud, en parte porque estoy a favor de los forks porque suelen ser mejores que los originales y también para probarla en un entorno de producción serio. Llevaba, además, un tiempo dándole vueltas a la idea de migrar de owncloud a nextcloud pero, primero la vagancia innata que hay en mi y segundo la duda de si funcionarían los plugins que utilizo y la app del móvil, me mantenían quieto.

Por supuesto, la instalación desde cero de nextcloud es tan sencilla como la de su predecesora y fue grato comprobar que el entorno está más pulido y mejorado y que los plugins y clientes son los mismos o superiores. Aún no lo sabía pero iba a saltar de una nube a otra.


Tengo que advertir que, aunque este proceso me haya funcionado puede no hacerlo para el resto del mundo y que declino toda responsabilidad en los fallos y problemas que pueda acarrear.


La migración en si es realmente sencilla aunque haya que mezclar diferentes manuales porque no hay un procedimiento actualizado de migración de owncloud a nextcloud (o, al menos, yo no lo he encontrado). Al final hice caso a un hilo del foro de nextcloud en donde decían que hay que borrar (o mover) todo el contenido de owncloud menos config y data y descomprimir nextcloud para, a continuación, actualizar via web o con occ. No era mucho pero es un buen punto de partida.

Como me definieron como vago, utilicé el actualizador web de nextcloud, accediendo a https://minube.example.com/updater/.

El proceso de actualización fallaba en un punto en el que solicitaba un secreto, una clave que se encuentra cifrada en el fichero config/config.php y que pedía descifrada. La solución pasaba por generar una nueva clave, guardarla cifrada en el fichero config.php y pasársela en claro al actualizador.

Tras hacer esto, la actualización finaliza sin problemas.

Después de comprobar que todos los ficheros estaban donde se suponía, que los usuarios siguen ahí y los clientes de escritorio de owncloud se conectan correctamente a nextcloud (si, flipante), respiré tranquilo.

Los últimos remates fueron la activación de los plugins de calendario, contactos, galería y grauphel (imprescindible para la vida moderna), adaptar el tema para que quede bonito, cifrar los ficheros e instalar al nueva app en el móvil que, dicho sea de paso, es mucho mejor y ofrece más configuración que la de owncloud.

 

Apurando plazos con hacienda, errores, certificados y linux

Desde el año pasado (creo) la AEAT (hacienda, para el que no sea de siglas), tiene un programa Java que sustituye al programa PADRE. Al final creo que se cansaron de mantener varios sistemas para cumplir telemáticamente con el fisco y lo hicieron en Java. Yo me lo imagino tal que así:

INTERIOR, TARDE OSCURA DE INVIERNO EN UN EDIFICIO DE CRISTAL Y ACERO. UN GRUPO DE GENTE CON CORBATA (HOMBRES TODO) DISCUTE.
–Es un coñazo rehacer el programa ese año tras año. ¡Está en visual basic!
–Pues otra vez montar un Citrix para que se conecten los cuatro idiotas de linux, no. ¡Se quejaban de que no era una solución libre!
–Pues a ver qué hacemos…
–Un momento, que le pregunto a mi cuñao por whatsapp, que sabe mucho de estas cosas… Que busquemos una solución multiplataforma… Que se hace una vez y sirve para todos los sistemas operativos… Algo web, fácil, rápido y basado en estándares abiertos…
–Suena bien…
–Espera, que sigue. Dice que pidamos que lo hagan en java, que es todo eso y más.
–¡Cojonudo! Ahora sólo hay que montar que concurso para que se lleve un amiguete y que hagan una web con todo eso. Mándame los whatsapps que tengan siglas o cosas de esas, que quedarán muy bien en el concurso. Y a ver quien tiene narices ahora de quejarse…

Si, es una pantomima y es muy personal pero no creo que se aleje mucho de la realidad.

Si, además, eres de esas personas que apuran los plazos cuando se trata de pagar (bienvenido/a al club) y la web te de un error del certificado justo después de pagar y antes de declararte al día de tus obligaciones, a día y medio del plazo final, entonces no le encontrarás la gracia por ningún lado.

Usamos el Macbook con Linux Mint y todo fue bien hasta el paso siguiente tras haber pagado. Cuando sólo te falta confirmar tu identidad con el certificado electrónico, nos saltó un popup con el error «Error message: El almacén no contenía entradas». Muy clarito todo.

error-aeat2

Así que tocó revisar certificados, ficheros del programa y volverse loco para acabar concluyendo que la culpa es de java. ¿De quién sino?

El maldito programa o al menos la parte final que muestra el justificante de la operación y del pago, sólo funciona con java, java, el java de adobe, el de java.com. Linux Mint trae, por defecto, openjre, que es una opción muy válida para casi todo el mundo menos para hacienda por lo que tocó borrar openjre, bajar java-java, instalarlo y, para que el maldito programa lo reconociese sin mucho esfuerzo, crear un enlace en /usr/bin/java apuntando al binario de la nueva versión.

Después de eso, repetir, alegar que ya se había pagado y terminar el proceso no sin antes mentar mil veces a la familia directa del águila que señaló java-java como una solución multiplataforma.

PD a los que lo dejáis todo para el último día… ¡corred insensatos! ¡Sólo quedan unas horas! 🙂
PD2 no hay ningún enlace a la web de java-java porque aún me dura el cabreo.

 

Aprendices de sysadmin

Resulta que tres elementos que conocemos, admiramos y queremos (y en ocasiones padecemos, ¿eh, presionator? :)) se han juntado para darle forma a un blog llamado Aprendiz de Sysadmin que ha abierto sus puertas hace un mes. @fpalenzuela, @itzala74 e @israelmgo van a escribir sobre administración de sistemas en varios entornos y ya tienen un par de entradas de cada, bastante interesantes.

Pero lo mejor está llegando porque ya han comenzado con la guía Hardening en sistemas Linux con un capítulo sobre el proceso de instalación de un debian cifrado. Viendo el índice de esa guía lo mejor está por llegar.

Así pues, ¡bienvenidos!

 

Instalación de un repositorio debian con reprepro

Lenny Updated

Cuando se pega mucho (pero mucho, mucho) con debian, lleva un momento en que empieza a hacer o modificar paquetes y es entonces cuando el uso de un repositorio personal es una buena idea. Hace unos años, crear y sobre todo mantener un repositorio de paquetes de debian era doloroso por los scripts que había que ejecutar, puesto que funcionaban una de cada dos veces y estaban llenos de parches. Afortunidamente han surgido unos cuantos programas que facilitan mucho la tarea de instalación y sobre todo de mantenimiento de los repositorios y, dentro de todos ellos, mi favorito es reprepro.

No es excesivamente pesado, se maneja completamente desde la línea de comandos y el cifrado de los ficheros que contienen las sumas MD5 (los ficheros Release) es transparente. También, la configuración de cada repositorio es sencilla y mediante ficheros de texto y toda la información de los paquetes se almacen en una base de datos Berkeley, por lo que no es necesarios ningún SGBD.

Tener los repositorios disponibles para un sólo equipo no es muy inteligente así que se suelen instalar bajo servidores web o ftp. Los repositorios de mi red están en ranas, mi servidor raspberry NAS, así que por motivos de rendimiento y recursos preferí instalar un servidor pure-ftpd antes que un apache2. Como ambos pillan fuera del ámbito de esta guía, os dejo los enlaces de configuración de ambos:

Instalación

Instalamos conjuntamente reprepro y pure-ftpd.

pure-ftpd

Configuramos pure-ftp según se explica en los enlaces superiores y configuramos unas cuantas cosas más.

  • crear usuario ftp con directorio /media/nas/ftp/.

  • asignar permisos a mi usuario en el directorio de los repositorios.

reprepro

Toda la configuración y gestión del repositorio con reprepro se realiza como un usuario sin privilegios, salvo el de escribir en el directorio de los repositorios.

Dada la versatilidad de reprepro puedo crear tantos repositorios como quiera. Si, por ejemplo, quiero tener los repositorios de cada proyecto organizados, puedo crear dentro de /media/nas/ftp un directorio, proy01, que contenga los repos proy01, partners y apps. Para el segundo proyecto crearía proy02 con los repos proy02 y extras y así… Cada proyecto con sus paquetes y, probablemente, un repo general con debian, con jessie, wheezy y sid dentro.

  • debemos crear una llave gpg de 2048 bits con que firmar los paquetes.

  • exportamos la parte pública de la llave a un fichero asc.

  • creamos el fichero de configuración del repo nimhix.

Las líneas más jugosas son Architectures, donde indicamos que arquitecturas están soportadas, Components, donde se enumeran las ramas del repo y SignWith, donde especificamos la clave pública que se usará para firmar los paquetes. Codename es el nombre en clave del repositorio y si, en este caso viene de la serie Justified.

  • creamos el repositorio y los enlaces. Si estamos en el directorio principal del repositorio (donde se ve el directorio conf), no es necesario pasar el argumento -b.

Gestionando paquetes

Todos los ejemplos se ejecutan desde el directorio principal (al mismo nivel que conf). De no ser así, el argumento -b es tu amigo. 🙂

Listar paquetes del repositorio

Añadir nuevos paquetes (o versiones actualizadas)

Borrar paquetes

Y con esto ya tenemos cuantos repositorios necesitemos. Actualmente es ranas quien sirve los paquetes en mi red local, así que el gasto de recursos está bastante contenido (con pure-ftpd). Si, además, configuras samba para “tirar” los paquetes en el directorio del ftp, lo tienes todo más a mano.

 

Firefox is back

Después de casi diez años usando la versión debianizada del mejor navegador que ha surcado internet, Mozilla Firefox, acabo de ver en los paquetes de debian que ya está de vuelta en los repositorios, al menos en la rama testing (si, lo sé pero es uno de esos vicios confesables...). Una gran noticia para los que no sabemos movernos sin esta gran pieza de software, ya sea en su estado normal o encebollado.

diego@tola:~$ apt-cache search firefox-esr
firefox-esr – Mozilla Firefox web browser

Han marcado como transitional a iceweasel y basta con hacer una actualización de paquetes para que se instale limpiamente, con los 450 MB restantes, por supuesto. Ha sido un detalle que hayan hecho coincidir el cambio con la mayor fiesta cristiana fuera del mes de diciembre y así nos ha pillado, por sorpresa y cara de susto.

Personalmente estoy encantado de que, por fin, haya vuelto la cordura y podamos disponer de Firefox sin trucos para evitar demandas legales absurdas porque, a pesar de intentar utilizar otros navegadores, ninguno
me convencía y no tardaba en volver a la comadreja de los hielos.

NOTA: esta entrada carece de enlaces y etiquetas html por un problema con el servidor. En cuanto se solvente, aparecerán mágicamente. :)