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

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…

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

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…

Cuidado al activar "userobj_accounting" en ZFS

Tras escribir Actualización de características en un sistema de ficheros ZFS (20200528) y decidir que todas mis máquinas con ZFS eran estables y no necesitaban la seguridad de poder volver a una versión previa del Sistema Operativo, me puse a actualizar mis ZPOOLs ZFS con todas las características opcionales disponibles.

La actualización fue simple, rápida e indolora salvo en uno de mis servidores. En ese servidor la operación se eternizó, con una carga de CPU muy elevada, a pesar de que la actividad de disco era relativamente baja.

De todas las características opcionales activadas, la única potencialmente costosa es userobj_accounting, porque requiere repasar los metadatos de todos los archivos y directorios en el ZPOOL.

La extrema carga de CPU en ese servidor es evidente:

top - 02:11:43 up 16 min,  1 user,  load average: 69.54, 61.05, 34.18
Tasks: 298 total,  66 running, 171 sleeping,   0 stopped,   0 zombie
%Cpu(s):  0.0 us, 99.5 sy,  0.0 ni,  0.0 id,  0.3 wa,  0.0 hi,  0.2 si,  0.0 st
KiB Mem :  1994684 total,   240660 free,  1568512 used,   185512 buff/cache
KiB Swap:        0 total,        0 free,        0 used.   279708 avail Mem

  PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND
18438 root      20   0       0      0      0 R   3.6  0.0   0:00.74 arc_prune
18603 root      20   0       0      0      0 R   3.6  0.0   0:00.15 arc_prune
18630 root      20   0       0      0      0 R   3.3  0.0   0:18.67 arc_prune
18461 root      20   0       0      0      0 R   3.3  0.0   0:00.63 arc_prune
18483 root      20   0       0      0      0 R   3.3  0.0   0:00.58 arc_prune
18507 root      20   0       0      0      0 R   3.3  0.0   0:00.42 arc_prune
18522 root      20   0       0      0      0 R   3.3  0.0   0:00.37 arc_prune
18528 root      20   0       0      0      0 R   3.3  0.0   0:00.36 arc_prune
18540 root      20   0       0      0      0 R   3.3  0.0   0:00.31 arc_prune
18548 root      20   0       0      0      0 R   3.3  0.0   0:00.28 arc_prune
18552 root      20   0       0      0      0 R   3.3  0.0   0:00.26 arc_prune
18553 root      20   0       0      0      0 R   3.3  0.0   0:00.26 arc_prune
18560 root      20   0       0      0      0 R   3.3  0.0   0:00.25 arc_prune
18563 root      20   0       0      0      0 R   3.3  0.0   0:00.24 arc_prune
18581 root      20   0       0      0      0 R   3.3  0.0   0:00.16 arc_prune
18589 root      20   0       0      0      0 R   3.3  0.0   0:00.15 arc_prune
18596 root      20   0       0      0      0 R   3.3  0.0   0:00.15 arc_prune
18599 root      20   0       0      0      0 R   3.3  0.0   0:00.15 arc_prune

Aquí vemos que la carga de CPU es muy elevada, casi 70, con más de un 99% del tiempo consumido en el Sistema Operativo por hilos ejecutando arc_prune. Buscando ese nombre en internet, aparece un enlace interesante: arc_prune: high load and soft lockups #6223.

Leer más…

Comparación de algoritmos de compresión ZRAM en Raspberry PI

Advertencia

En este artículo solo me interesa utilizar el algoritmo de compresión con mayor reducción. En otras situaciones habrá que tener en cuenta también el impacto en consumo de CPU, pero esto no es un factor en mi caso de uso.

Ten en cuenta que en tu caso puedes valorar otras cosas. Depende de tus necesidades concretas.

En Cómo y por qué utilizar ZRAM como "espacio de intercambio" o SWAP comparo el nivel de compresión de varios algoritmos en mi portátil, con mi perfil de uso del portátil.

Como explico allí, uno de los entornos donde ZRAM es más interesante es en una Raspberry PI, porque por un lado no queremos quemar la microSD con las grabaciones del espacio de intercambio y, por otro, el tamaño de la RAM disponible en una Raspberry PI es limitado y no se puede ampliar.

Las comparativas del nivel de compresión que extraje de mi portátil son útiles, pero prefiero hacer las pruebas también en mi Raspberry PI, fundamentalmente porque el perfil de uso es muy diferente y los resultados de la compresión serán distintos.

La configuración de dispositivos ZRAM es similar a lo explicado en Cómo y por qué utilizar ZRAM como "espacio de intercambio" o SWAP, así que no voy a repetirla aquí. Lo más importante es ver qué algoritmos de compresión tenemos disponibles y probarlos todos. Para ello, una vez que ya hemos creado algún dispositivo ZRAM, podemos preguntarle qué algoritmos de compresión soporta:

root@osmcpi:~# cat /sys/block/zram0/comp_algorithm
lzo lzo-rle lz4 zstd [deflate]

En esta versión del Sistema Operativo tenemos cinco algoritmos de compresión disponibles para ZRAM. Los probamos todos con mi caso de uso y vemos el resultado tras achuchar un poco la Raspberry PI:

Leer más…