El hilo del laberinto (Publicaciones sobre Configuración)

Thunderbird "habla demasiado" (respecto a tu configuración)

Jesús Cea Avión — Wed, 13 Nov 2024 22:07:00 GMT

El otro día estaba mirando las cabeceras SMTP de mis correos electrónicos y me he llevado una sorpresa:

User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
            Thunderbird/102.15.1

Mi cliente de correo, Thunderbird, filtra la versión que estoy utilizando y que estoy usando Linux sobre x86-64.

Y esto no lo hace solo en los correos electrónicos salientes sino también en las conexiones HTTP que se generen al visualizar mensajes en formato HTML.

Esto me parece algo innecesario y un peligro de privacidad y de seguridad.

Afortunadamente podemos irnos al editor de configuración de Thunderbird y editar (o crear, si no existe) la preferencia general.useragent.override. Ahí ponemos el texto que nos de la gana.

En versiones modernas de Thunderbird podemos indicarle directamente al programa que sólo envie Thunderbird como identificación, sin referencias de plataforma o versiones. Para ello hay que entrar en el editor de configuración y poner (o crear) la preferencia mailnews.headers.useMinimalUserAgent a True. Si no queremos enviar una identificación de usuario en absoluto, podemos poner a False la preferencia mailnews.headers.sendUserAgent.

Podeis ver los detalles por vosotros mismos en el código fuente de Thunderbird, en su servidor Mercurial.

Elegir la identidad SSH que presenta un cliente al servidor

Jesús Cea Avión — Sun, 03 Dec 2023 14:12:00 GMT

Cuando un cliente se conecta a un servidor SSH, normalmente le propondrá todas las identidades SSH presentes en el servicio SSH Agent. Esto no está necesariamente mal, pero tiene algunos problemas:

El servidor SSH puede tener un número de reintentos limitado y nosotros podemos tener muchas identidades SSH que ofrecer.
A veces queremos tener nuestras personalidades online separadas y es preferible ofrecer al servidor SSH una identidad concreta controlada en vez de informarle de todas nuestras identidades disponibles para que elija la que le sirva. Un servidor malicioso podría vincular personalidades SSH e identificarnos como la misma persona física en diferentes entornos que preferimos mantener separados.

Los pasos a seguir con OpenSSH son sencillos:

Creamos una nueva identidad SSH para un servicio concreto. Para eso se usa el comando ssh-keygen.

Configuramos en ~/.ssh/config un perfil para ese servicio con estos parámetros:

# "IdentitiesOnly yes" indica que solo debemos ofrecer
# esa personalidad, aunque el SSH-Agent tenga más.
IdentitiesOnly yes
IdentityFile PATH_A_LA_IDENTIDAD_SSH

Cuando nos conectemos al servidor usando ese perfil, el cliente SSH solo ofrecerá esa identidad.

Podemos verificar que todo está funcionando bien conectando a ese servicio con ssh -v y viendo qué identidades estamos ofreciendo al servidor.

Advertencia

La configuración propuesta ofrece una única identidad SSH a un servidor SSH concreto, pero ofrecerá esa personalidad SSH a otros servidores SSH. Si queremos aislamiento total, debemos tener configuraciones similares para todos nuestros servidores SSH (se puede utilizar el comodín para definir una configuración por defecto) o bien añadir esa identidad SSH solo a un servicio SSH Agent concreto y separado.

Recuerda que puedes indicar qué servicio SSH Agent debe utilizar tu cliente SSH utilizando la variable de entorno SSH_AUTH_SOCK.

Cómo cambiar el tamaño del espacio de intercambio (SWAP) en SmartOS

Jesús Cea Avión — Wed, 11 Jan 2023 23:54:00 GMT

Nota

En este documento voy a usar los términos SWAP y espacio de intercambio de forma indistinta.

Cuando se realiza una instalación nueva, SmartOS crea un dataset de SWAP del mismo tamaño que la memoria RAM del ordenador. Esto puede ser apropiado para máquinas grandes, pero cuando vamos escasos de memoria un SWAP tan pequeño es problemático porque bajo Illumos (Solaris) no existe el concepto de overcommit de memoria como en Linux. Es decir, un kernel Illumos limita el espacio de direccionamiento disponible para los programas a la suma de la memoria RAM y el espacio de intercambio (SWAP).

Por tanto, en SmartOS es común ampliar el espacio de intercambio.

Una de mis máquinas tiene solo 8GB de RAM y veo lo siguiente:

[root@X ~]# swap -s
total: 3928724k bytes allocated + 221992k reserved = 4150716k used, 8223728k available

[root@X ~]# zfs get all zones/swap
NAME        PROPERTY              VALUE                    SOURCE
zones/swap  type                  volume                   -
zones/swap  creation              vie. dic.  2  8:38 2022  -
zones/swap  used                  8,22G                    -
zones/swap  available             614G                     -
zones/swap  referenced            3,71G                    -
zones/swap  compressratio         2.18x                    -
zones/swap  reservation           none                     default
zones/swap  volsize               7,97G                    local
zones/swap  volblocksize          8K                       default
zones/swap  checksum              on                       default
zones/swap  compression           lz4                      inherited from zones
zones/swap  readonly              off                      default
zones/swap  createtxg             92                       -
zones/swap  copies                1                        default
zones/swap  refreservation        8,22G                    local
zones/swap  guid                  1242262060458694733      -
zones/swap  primarycache          all                      default
zones/swap  secondarycache        all                      default
zones/swap  usedbysnapshots       0                        -
zones/swap  usedbydataset         3,71G                    -
zones/swap  usedbychildren        0                        -
zones/swap  usedbyrefreservation  4,52G                    -
zones/swap  logbias               latency                  default
zones/swap  dedup                 off                      default
zones/swap  mlslabel              none                     default
zones/swap  sync                  standard                 default
zones/swap  refcompressratio      2.18x                    -
zones/swap  written               3,71G                    -
zones/swap  logicalused           8,01G                    -
zones/swap  logicalreferenced     8,01G                    -
zones/swap  snapshot_limit        none                     default
zones/swap  snapshot_count        none                     default
zones/swap  redundant_metadata    all                      default
zones/swap  encryption            off                      default
zones/swap  keylocation           none                     default
zones/swap  keyformat             none                     default
zones/swap  pbkdf2iters           0                        default

Por necesidades de servicio, requiero ampliar bastante el espacio de intercambio que, como he dicho, limita el espacio de direccionamiento total disponible para todos los programas.

Leer más… (quedan 4 minutos de lectura)

Creación e instalación de un perfil OpenVPN en iOS

Jesús Cea Avión — Wed, 28 Sep 2022 22:31:00 GMT

Hace tiempo la cosa era más complicada, pero hoy en día crear y activar un perfil OpenVPN para iOS es bastante trivial.

Creación de un fichero de configuración OpenVPN

Creamos un par de claves públicas y privadas para el usuario. Esas claves deben ir firmadas por la entidad de certificación asociada al servidor OpenVPN y tienen una caducidad determinada (por defecto, un año).

Si usamos easy-rsa, los comandos a ejecutar son:
```
jcea@OpenVPN_Server:~$ cd /etc/openvpn/easy-rsa/2.2.2/
jcea@OpenVPN_Server:/etc/openvpn/easy-rsa/2.2.2$ source vars
NOTE: If you run ./clean-all, I will be doing a rm -rf on /etc/openvpn/easy-rsa/2.2.2/keys
jcea@OpenVPN_Server:/etc/openvpn/easy-rsa/2.2.2$ echo $KEY_EXPIRE
365
```
Lo anterior inicializa easy-rsa. Podemos ver que la expiración por defecto es de 365 días. Podemos modificarla si así lo deseamos.

Lo normal ahora sería generar el certificado OpenVPN para el usuario, sin más. Sin embargo la versión 2.2.2 de easy-rsa no permite crear una clave nueva para un usuario ya existente, AUNQUE LA CLAVE ANTIGUA HAYA CADUCADO. En mi opinión, esto es un bug.

Leer más… (quedan 5 minutos de lectura)

DNSSEC: Migración de "jcea.es" a ECDSAP256SHA256

Jesús Cea Avión — Mon, 20 Jun 2022 18:00:00 GMT

La experiencia de migrar algunos de mis subdominios DNS de uso privado a ECDSAP256SHA256 en 2020, tal y como describo en DNSSEC: Migración a ECDSAP256SHA256 en algunos de mis dominios, ha sido muy indolora y positiva. Sin embargo a la hora de migrar el dominio DNS jcea.es entero, el tema de la compatibilidad sigue sobre la mesa.

Hay novedades recientes documentadas en DNSSEC: enlaces interesantes (20220611), como que la mitad de los dominios DNS protegidos por DNSSEC en Holanda usan ya ECDSAP256SHA256, o que el registrador francés .fr acaba de migrar a ECDSAP256SHA256.

Parece que hay consenso en que usar ECDSAP256SHA256 en DNSSEC es el estado del arte actual y que debería funcionar en cualquier cosa que tenga menos de diez años (si tiene más de diez años, o no soporta DNSSEC en absoluto o, sencillamente, dejará de validar DNSSEC, como si el dominio no estuviese firmado).

Para migrar jcea.es a ECDSAP256SHA256 voy a seguir básicamente los pasos descritos en DNSSEC: Migración a ECDSAP256SHA256 en algunos de mis dominios. Ls diferencia fundamental es que quiero editar los registros DS solo una vez, porque quiero interactuar con mi registrador DNS lo mínimo posible.

Es decir, en DNSSEC: Migración a ECDSAP256SHA256 en algunos de mis dominios añado las claves KSK y ZSK nuevas, manteniendo las claves viejas y añadiendo registros DS nuevos de forma que se admitan las claves KSK viejas y nuevas. Una vez que se propagan los cambios, puedo eliminar los registros DS, y las claves KSK y ZSK antiguos.

Ahora solo quiero hacer un cambio en los registro DS.

Los pasos son:

Leer más… (quedan 5 minutos de lectura)

DNSSEC: enlaces interesantes (20220611)

Jesús Cea Avión — Sat, 11 Jun 2022 15:19:00 GMT

Puesta al día de algunos enlaces interesantes sobre DNSSEC para quitármelos de mis marcadores del navegador web:

DNSSEC Deployment.
DNSSEC and DANE Deployment Statistics.

En el momento de escribir este artículo, el despliegue de claves KSK está igualado entre los algoritmos RSASHA256 y ECDSAP256SHA256.
INCIBE: Guía de implantación y buenas prácticas de DNSSEC.

Lectura imprescindible. 103 páginas de nada.
RFC 6605: Elliptic Curve Digital Signature Algorithm (DSA) for DNSSEC.
Resolutions for 2020: Afnic goes elliptic.
DNSSEC: change of algorithm for the .fr zone.

El dominio .fr ha migrado a ECDSAP256SHA256.
DNSSEC Algorithm Use in 2022.

El 30.5% de los dominios protegidos con DNSSEC utilizan ECDSAP256SHA256.
DNSSEC: The Long and Bumpy Road of Algorithm Deployment.
DNSSEC algorithms for TLDs (and everyone else).
DNSSEC Report 2020-10 for Top 100 Banking Institutions.
The Reality of Algorithm Agility: Studying the DNSSEC Algorithm Life-Cycle.
RFC 8080: Edwards-Curve Digital Security Algorithm (EdDSA) for DNSSEC.
RFC 7344: Automating DNSSEC Delegation Trust Maintenance.
RFC 8078: Managing DS Records from the Parent via CDS/CDNSKEY.
Announcing CDS/CDNSKEY Support.
DNSSEC provisioning automation with CDS/CDNSKEY in the real world.
DNSSEC algorithm rollover HOWTO.
Parents, children, CDS/CDNSKEY records, and dnssec-cds.
dnssec-cds.
Automating the DNSSEC trust anchors using CDS.

DNSSEC: Migración a ECDSAP256SHA256 en algunos de mis dominios

Jesús Cea Avión — Thu, 06 Aug 2020 14:19:00 GMT

Tras "Key Rollover" y reconfiguración de mis DNSSEC para eliminar SHA-1 me quedé con el resquemor de migrar mis dominios DNS protegidos con DNSSEC al algoritmo RSASHA256 y no al molón ECDSAP256SHA256. Mi miedo en aquel momento era la compatibilidad [1].

[1]	La zona raíz del DNS y el propio dominio regional .es utilizan RSASHA256 para las firmas DNSSEC.

Pero dentro de jcea.es tengo algunos dominios de uso interno y otro con un único "consumidor". Comprobando los resolvers "consumidores" de esos dominios, confirmo que son compatibles con el algoritmo ECDSAP256SHA256 en DNSSEC. ¡Podría migrarlos sin arriesgar la compatibilidad del dominio jcea.es!

Los pasos son similares a los documentados en "Key Rollover" y reconfiguración de mis DNSSEC para eliminar SHA-1, así que no voy a repetir los comandos precisos, me centraré en una descripción de alto nivel:

Leer más… (quedan 2 minutos de lectura)

"Key Rollover" y reconfiguración de mis DNSSEC para eliminar SHA-1

Jesús Cea Avión — Wed, 22 Jul 2020 12:11:00 GMT

Mi configuración actual DNSSEC utiliza SHA-1, que es un algoritmo de hash al que se le han ido encontrando vulnerabilidades. Lo he mantenido porque un ataque a mi DNS parece poco rentable y porque lo consideraba el más compatible [1], pero la puntilla ha sido un nuevo ataque en enero de 2020. La situación es ya insostenible y mantener SHA-1 resulta injustificable.

[1]

(1, 2)

Si durante la verificación DNSSEC un resolver encuentra algoritmos desconocidos, simplemente se comportará como si ese registro DNS no existiese.

En particular, si el registro de anclaje DS que activa DNSSEC en un subdominio no es reconocido, el resolver considerará que el registro no existe y, por tanto, el dominio no tiene DNSSEC.

Incluyo algunos enlaces relevantes en la bibliografía del final.

Las claves públicas DNSSEC actuales de mi dominio jcea.es son:

jcea@jcea:~$ dig DNSKEY jcea.es

; <<>> DiG 9.16.1-Ubuntu <<>> DNSKEY jcea.es
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 30207
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 65494
;; QUESTION SECTION:
;jcea.es.                       IN      DNSKEY

;; ANSWER SECTION:
jcea.es.                86400   IN      DNSKEY  256 3 7 AwEAAdvqYNIq+kT+BeN+EZLr2oygteIWy1McKv9pt3PEXnSmoIUT+puP p6fVbqf5bbPQxp7FD6k2d5U8VpF7c1clcvlqhihgZK59jF1sWe2vM51k QW+ZeyAY5hcWF/DRij7jUa3QcWBJLnOSseV8VEOFfD53FSiIdGpDdVbf OH2Mwi1l
jcea.es.                86400   IN      DNSKEY  257 3 7 AwEAAbBRJkUetAndznEpQm8SI1UFxwy+/ZWyj/CK0MT13Cjx0Yd/Kmah WfFC9G9cpJU3aPw/5w8TOC0Cpa9BluYfBboKu60i1OXlgDvQevevk8Av foqLm213nttALCFfeCTd5iBxJohNQUjreopxcV+FgCG1TKCZQqbDUh5L DaCMDeeHPZJKzIp+Jysif9etSwLnsShUem75X9wv0DLc6i6fdKDsz61j vitl420eDET98LCxRraIgPPjW4yYDoUIEeagtd5VSbgbDXLKVK0nAHlv G4p19cTtZz+Ct928l072FIZ4w3XIDYB7TkWZ5AU/+pXIHfglXwurLtUo gDuHWD2mcgs=

;; Query time: 96 msec
;; SERVER: 127.0.0.53#53(127.0.0.53)
;; WHEN: jue jul 16 15:41:19 CEST 2020
;; MSG SIZE  rcvd: 460

Ambas claves, la KSK y la ZSK, utilizan el algoritmo 7 que, según el RFC8624, es RSASHA1-NSEC3-SHA1. Está marcado como NOT RECOMMENDED. Toca cambiar.

Leer más… (quedan 5 minutos de lectura)

DNS TTL of 0 and "nsec3params"

Jesús Cea Avión — Wed, 03 Jul 2019 22:46:00 GMT

As described in Usar NSEC3 en vez de NSEC en un dominio DNSSEC con gestión de DNS dinámico, the common TTL (Time To Live (TTL)) used in NSEC3PARAMS record is Zero. This record is used in DNSSEC to provide a secure "proof of non existence" without leaking details about what names actually exist. I never fully understood why a TTL of zero is so common, but knowing in this case is not really important.

So good so far.

The problem was listening to The Ask Mr. DNS Podcast: Episode 57 [1]. There, Matt Larson and Cricket Liu talk long and deep about why using a TTL of Zero for DNS records is (almost) always a bad idea. I agree with the comments in the podcast, but the comments hit a nerve inside of me. I have always been unconfortable about not knowing WHY a TTL of Zero is used with NSEC3PARAMS and now real DNS experts [1] were saying that a TTL of Zero is bad.

[1]

(1, 2, 3)

The Ask Mr. DNS Podcast is (usually) a quite deep, insightful and (at times) funny podcast about DNS conducted by world class DNS experts Matt Larson and Cricket Liu.

You can ask them DNS questions at mrdns@ask-mrdns.com. If you are lucky (they are picky), they could reply them in the podcast.

Sorry, I needed to know. I sent a message to The Ask Mr. DNS Podcast people [1] asking for clarification and expert insight:

Leer más… (quedan 4 minutos de lectura)

¿Cómo desactivar la WIFI y/o el Bluetooth internos de una Raspberry PI 3?

Jesús Cea Avión — Tue, 20 Sep 2016 17:39:00 GMT

Cambiar mi red WIFI al canal 13, como se describe en Usar los canales WIFI 12 y 13 en una Raspberry PI, ayudó un poco, pero la calidad seguía siendo insuficiente. En la práctica no se podía confiar en el funcionamiento WIFI de la Raspberry PI 3, lo que resulta la mar de frustrante.

Antes de la Raspberry PI 3 usaba modelos anteriores con un USB WIFI externo. Funcionaba a la perfección. ¿Y si pruebo ese dispositivo en la Raspberry PI 3?.

Esa Raspberry PI 3 usa OSMC como media center. Esta distribución solo permite una tarjeta WIFI así que tenemos que desactivar la capacidad WIFI interna para que utilice el WIFI USB.

Leer más… (quedan 1 minutos de lectura)