Archivos de Categoría: Uncategorized

ModSecurity con Nginx en Buster

Tras pasarlo regular para poner a marchar un Nginx como proxy inverso con ModSecurity, he pensado que sería buena idea volcar en alguna parte mis notas para ahorrar quebraderos de cabeza a otros sufridos informáticos.

Buster lleva la librería ModSecurity 3 ya empaquetada. No hay más que instalarla con apt.

Lo que da un poco de problema es compilar el módulo de nginx. Esto, por ahora, hay que hacerlo a mano.

Primero, instalar nginx con apt.

Luego, bajar el fuente de la versión exacta. En el momento de escribir esto:

dpkg -l nginx
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name Version Architecture Description
+++-==============-============-============-==========================================
ii nginx 1.14.2-2 all small, powerful, scalable web/proxy server

Por tanto:

wget -O - http://nginx.org/download/nginx-1.14.2.tar.gz | tar xzf -

También necesitamos el conector de ModSecurity con nginx:

git clone https://github.com/SpiderLabs/ModSecurity-nginx.git

Ahora, ojo a esto. Aparte de build-essential, hacen falta otras cosas. La más enrevesada es libpcre3-dev. Sin esto, no compila el módulo de nginx. Pero es que además hay que configurar el conector para que la use. Es decir, ya en el directorio del fuente de nginx (nginx-1.14.2 en este caso):

./configure --with-compat --add-dynamic-module=../ModSecurity-nginx --without-http_rewrite_module --without-http_gzip_module --with-pcre

Hecho esto, ya no hay más que hacer make.

Otra cosa que despista un poco es dónde pone Debian las cosas. El módulo compilado lo podemos encontrar en objs/ngx_http_modsecurity_module.so y casi cualquier guía que encontremos por ahí dice de ponerlo en /etc/nginx/modules. Pero nop, eso no es el estilo Debian. Para hacerlo al estilo Debian, hay que soltarlo en /usr/lib/nginx/modules/ y seguidamente crear la configuración que lo carga. Verbigracia:

echo "load_module modules/ngx_http_modsecurity_module.so;" > /tmp/mod-security.conf && sudo mv /tmp/mod-security.conf /etc/nginx/modules-available/

cd /etc/nginx/modules-enabled/

sudo ln -s ../modules-available/mod-security.conf 50-mod-security.conf

sudo service nginx restart

Y nuestros esfuerzos se verán recompensados con un:

nginx: [emerg] module "/usr/share/nginx/modules/ngx_http_modsecurity_module.so" is not binary compatible in /etc/nginx/modules-enabled/50-mod-security.conf:1

Mierda.

Total. Que vamos a ver cómo está construído el nginx del paquete Debian:

nginx -V

Esto suelta el chorizo que en su día le pasaron al nginx al compilarlo para empaquetarlo. Y nos dice que:

configure arguments: --with-cc-opt='-g -O2 -fdebug-prefix-map=/build/nginx-sWHVb6/nginx-1.14.2=. -fstack-protector-strong -Wformat -Werror=format-security -fPIC -Wdate-time -D_FORTIFY_SOURCE=2' --with-ld-opt='-Wl,-z,relro -Wl,-z,now -fPIC' --prefix=/usr/share/nginx --conf-path=/etc/nginx/nginx.conf --http-log-path=/var/log/nginx/access.log --error-log-path=/var/log/nginx/error.log --lock-path=/var/lock/nginx.lock --pid-path=/run/nginx.pid --modules-path=/usr/lib/nginx/modules --http-client-body-temp-path=/var/lib/nginx/body --http-fastcgi-temp-path=/var/lib/nginx/fastcgi --http-proxy-temp-path=/var/lib/nginx/proxy --http-scgi-temp-path=/var/lib/nginx/scgi --http-uwsgi-temp-path=/var/lib/nginx/uwsgi --with-debug --with-pcre-jit --with-http_ssl_module --with-http_stub_status_module --with-http_realip_module --with-http_auth_request_module --with-http_v2_module --with-http_dav_module --with-http_slice_module --with-threads --with-http_addition_module --with-http_geoip_module=dynamic --with-http_gunzip_module --with-http_gzip_static_module --with-http_image_filter_module=dynamic --with-http_sub_module --with-http_xslt_module=dynamic --with-stream=dynamic --with-stream_ssl_module --with-stream_ssl_preread_module --with-mail=dynamic --with-mail_ssl_module --add-dynamic-module=/build/nginx-sWHVb6/nginx-1.14.2/debian/modules/http-auth-pam --add-dynamic-module=/build/nginx-sWHVb6/nginx-1.14.2/debian/modules/http-dav-ext --add-dynamic-module=/build/nginx-sWHVb6/nginx-1.14.2/debian/modules/http-echo --add-dynamic-module=/build/nginx-sWHVb6/nginx-1.14.2/debian/modules/http-upstream-fair --add-dynamic-module=/build/nginx-sWHVb6/nginx-1.14.2/debian/modules/http-subs-filter

Vale

Pues nada, paciencia y vamos a ver.

make clean

./configure --add-dynamic-module=../ModSecurity-nginx --with-cc-opt='-g -O2 -fdebug-prefix-map=/build/nginx-sWHVb6/nginx-1.14.2=. -fstack-protector-strong -Wformat -Werror=format-security -fPIC -Wdate-time -D_FORTIFY_SOURCE=2' --with-ld-opt='-Wl,-z,relro -Wl,-z,now -fPIC' --prefix=/usr/share/nginx --conf-path=/etc/nginx/nginx.conf --http-log-path=/var/log/nginx/access.log --error-log-path=/var/log/nginx/error.log --lock-path=/var/lock/nginx.lock --pid-path=/run/nginx.pid --modules-path=/usr/lib/nginx/modules --http-client-body-temp-path=/var/lib/nginx/body --http-fastcgi-temp-path=/var/lib/nginx/fastcgi --http-proxy-temp-path=/var/lib/nginx/proxy --http-scgi-temp-path=/var/lib/nginx/scgi --http-uwsgi-temp-path=/var/lib/nginx/uwsgi --with-debug --with-pcre-jit --with-http_ssl_module --with-http_stub_status_module --with-http_realip_module --with-http_auth_request_module --with-http_v2_module --with-http_dav_module --with-http_slice_module --with-threads --with-http_addition_module --with-http_geoip_module=dynamic --with-http_gunzip_module --with-http_gzip_static_module --with-http_image_filter_module=dynamic --with-http_sub_module --with-http_xslt_module=dynamic --with-stream=dynamic --with-stream_ssl_module --with-stream_ssl_preread_module --with-mail=dynamic --with-mail_ssl_module

make

sudo cp objs/ngx_http_modsecurity_module.so /usr/lib/nginx/modules/ngx_http_modsecurity_module.so

sudo service nginx start

Los otros –add-dynamic-module se pueden omitir. Y ya estamos listos.

Configurar un proxy inverso con ModSecurity es otra historia y debe ser contada en otra ocasión.

Debian live a medida

En Github se pueden encontrar excelentes instrucciones para instalar una Debian Stretch con ZFS en la raíz. ZFS no está disponible directa y cómodamente en el instalador de Debian porque las licencias de Linux y de ZFS no son compatibles, por lo que es necesario <suspiro>hacerlo a mano</suspiro>.

En fin. La forma más normal, como se puede leer, es arrancar con una Debian «live» y seguidamente hacer un montón de cosas a mano. Esto es muy instructivo, pero cuando a uno le esperan una pila de hipervisores, que pesan más que uno y hasta algunos opinan que valen más, en todos los cuales hay que instalar una ZFS en raíz… Es de recibo buscar un método algo más automático.

El primer paso es automatizar un poquejo las acciones con un script en bash. Esto es bastante agradecido ya; no hay más que copiar y pegar, y la instalación se hace sola (más o menos).

Pero arrancar con una Debian Live tiene sus cosillas, como que hay que instalar una tonelada de software todas y cada una de las veces. Entre otras cosas, el zfs va en dkms y depende de un montón de cosas.

Así que, redondeando, decidí hacerme una Debian Live a medida. Esto no es tan difícil, especialmente si alguien lo ha hecho antes y ha vivido para documentarlo, como por ejemplo ha hecho Will Haley con este excelente artículo. Partiendo del mismo, he hecho unas pocas adaptaciones y esto es lo que me funciona, para hacer una ISO de Debian Stretch (live) especialmente para instalar Debian con ZFS en raíz, utilizando una Debian Stretch.

En el artículo de Will Haley también explica cómo generar un pincho USB. Pero como la ISO me soluciona la papeleta (porque uso iDRAC, IPMIs, iLOs y otras cosas que comienzan con i), aquí me he quedado.

La cosa empieza instalando en la Debian en que vayamos a trabajar lo necesario:

sudo apt install debootstrap squashfs-tools xorriso grub-pc-bin grub-efi-amd64-bin mtools

Nos creamos un directorio (voy a usar el mismo nombre que Will Haley para no liarnos) y algunos subdirectorios que usaremos más adelante:

mkdir -p LIVE_BOOT/{scratch,image/live}

Nos montamos una Debian básica en ese directorio:

sudo debootstrap --arch=amd64 --variant=minbase stretch LIVE_BOOT/chroot http://deb.debian.org/debian/

En lugar de http://deb.debian.org/debian, podemos usar nuestro mirror favorito si tenemos uno. Igualmente, la arquitectura puede ser i386 o lo que necesitemos.

Nos vamos al chroot:

sudo chroot LIVE_BOOT/chroot

Elegimos un nombre para nuestra Debian «viva» y lo ponemos:

echo "viva" > /etc/hostname
echo "127.0.1.1 viva" >> /etc/hosts

Le instalamos un kernel y lo necesario para el arranque:

apt install --no-install-recommends linux-image-amd64 live-boot systemd-sysv

Añadimos a la masa los paquetes que queramos tener disponibles. Varios de los siguientes son prácticamente una necesidad para poder tener red y esas cosillas:

sudo apt install curl openssh-client openssh-server iproute2 iputils-ping less sudo emacs-nox

Y si queremos usar esta imagen para instalar un ZFS en raíz, podemos ir metiendo algunos paquetes que necesitaremos. Desafortunadamente, zfs-dkms no se puede compilar en un chroot (ni idea de por qué), pero al menos se puede dejar instalado:

sudo apt install debootstrap gdisk dpkg-dev linux-headers-amd64
sudo apt install zfs-dkms

Limpiamos:

sudo apt clean

Creamos un usuario si nos apetece y le damos sudo. O bien simplemente ponemos una clave a root:

sudo useradd -m -s /bin/bash debian
sudo passwd debian
sudo passwd root
sudo visudo

Y nos salimos del chroot

exit

Ya tenemos nuestro entorno listo; ahora hacemos con él un sistema de ficheros:

sudo mksquashfs LIVE_BOOT/chroot LIVE_BOOT/image/live/filesystem.squashfs -e boot

Copiamos el kernel y el sistema de ficheros al directorio donde guardamos lo que irá en la imagen:

sudo cp LIVE_BOOT/chroot/boot/vmlinuz-* LIVE_BOOT/image/vmlinuz
sudo cp LIVE_BOOT/chroot/boot/initrd.img-* LIVE_BOOT/image/initrd

Ahora vamos a crear la configuración de GrUB. El comando search lo que hace es buscar un sistema de ficheros que contenga el fichero /DEBIAN_CUSTOM que vamos a crear seguidamente. Lo podríamos haber llamado /Susana o cualquier otra cosa. El caso es que el sistema de ficheros que pesque con ese fichero creado es el que va a llamar raíz:

cat <<'EOF' > LIVE_BOOT/scratch/grub.cfg
search --set=root --file /DEBIAN_CUSTOM
insmod all_video
set default="0"
set timeout=5
menuentry "Debian Live" {
linux /vmlinuz boot=live quiet nomodeset
initrd /initrd
}
EOF

Creamos el fichero prometido en su sitio:

touch LIVE_BOOT/image/DEBIAN_CUSTOM

Creamos la imagen UEFI con GrUB:

sudo grub-mkstandalone --format=x86_64-efi --output=LIVE_BOOT/scratch/bootx64.efi --locales="" --fonts="" "boot/grub/grub.cfg=LIVE_BOOT/scratch/grub.cfg"

Creamos la imagen de arranque UEFI, de 16 bits de toda la vida (al menos de la vida del PC):

cd LIVE_BOOT/scratch
dd if=/dev/zero of=efiboot.img bs=1M count=10
mkfs.vfat efiboot.img
mmd -i efiboot.img efi efi/boot
mcopy -i efiboot.img ./bootx64.efi ::efi/boot/
cd ../..

Y una imagen de arranque para BIOS:

sudo grub-mkstandalone --format=i386-pc --output=LIVE_BOOT/scratch/core.img --install-modules="linux normal iso9660 biosdisk memdisk search tar ls" --modules="linux normal iso9660 biosdisk search" --locales="" --fonts=""  "boot/grub/grub.cfg=LIVE_BOOT/scratch/grub.cfg"

Concatenamos la imagen de arranque de CD con el sistema de ficheros que hemos creado:

cat /usr/lib/grub/i386-pc/cdboot.img LIVE_BOOT/scratch/core.img > /tmp/bios.img
sudo mv /tmp/bios.img LIVE_BOOT/scratch/bios.img

Y por fin, crear la ISO:

sudo xorriso -as mkisofs -iso-level 3 -full-iso9660-filenames -volid "DEBIAN_CUSTOM" -eltorito-boot boot/grub/bios.img -no-emul-boot         -boot-load-size 4 -boot-info-table --eltorito-catalog boot/grub/boot.cat --grub2-boot-info --grub2-mbr /usr/lib/grub/i386-pc/boot_hybrid.img -eltorito-alt-boot -e EFI/efiboot.img -no-emul-boot -append_partition 2 0xef ${HOME}/LIVE_BOOT/scratch/efiboot.img     -output "${HOME}/LIVE_BOOT/debian-custom.iso" -graft-points         "${HOME}/LIVE_BOOT/image"  /boot/grub/bios.img=$HOME/LIVE_BOOT/scratch/bios.img  /EFI/efiboot.img=$HOME/LIVE_BOOT/scratch/efiboot.img

Listo para usar. A pasarlo pipa.

Los controladores virtuales en máquinas virtuales

«Modern OS should use virtio-scsi anyways«. Esta cita de Tom, de Proxmox, originalmente en su foro, suena a buena idea. Ya que hemos sustituído una controladora SCSI (SATA para nosotros, los humildes), con su correspondiente disco, por una mera simulación software de la misma y un trocito de un disco más grande, suena correcto que el controlador por el que el virtual pide sus operaciones sea virtual.

Hay varias razones para ello. La más sencilla es que una controladora virtual (una LSI, por ejemplo, que es una de las más populares) no deja de ser un software cuya tarea es interpretar lo que pide el sistema virtualizado, usando unos comandos que se diseñaron pensando en discos que giran y tienen cabezas magnéticas, y convertirlo a lo que el hipervisor ofrece. Esto último, cada vez más, son discos que se parecen mucho más a la memoria RAM que a lo que tenían en mente los que diseñaron el protocolo SCSI para discos. Entonces, podemos librarnos de un montón de trabajo en todos y cada uno de los accesos del virtual al disco si simplemente cogemos lo que el virtual quiere y directamente se lo damos al hipervisor en su lenguaje nativo. Menos uso de recursos, menos código y menos complejo, igual a menos errores. ¿Algún inconveniente?

Claro que sí. La cosa tiene sus inconvenientes. Los aficionados a la retroinformática («mi ERP requiere Windows Server 2003») descubrirán en seguida que los sistemas operativos diseñados hace quince años no llevan controladores para almacenamiento virtualizado. Oh, por supuesto hay solución: No hay más que bajarse la ISO con los últimos controladores, meterla en el CD virtual, e instalar. Si se trata de una máquina que ya existe, solo queda pegar el cambiazo. Ya de paso, podemos meter el controlador de red virtual. Este último mejorará un pelo el rendimiento y uso de recursos de la red, a cambio de… Su propio interface, por supuesto. Ah, ¿que estábamos hablando de una máquina virtual que ya existe? En ese caso, el ejercicio de malabarismo para cambiar uno por otro sin perder la conexión, lo dejo de manos del lector.

Feliz cumpleaños, Víctor.

dehydrated y Apache

Si antes lo digo… Hoy he tenido que instalar dehydrated con Apache.

Igual que con nginx, es la sencillez misma; pero no puedo pasar la oportunidad de dejar testimonio de una configuración de ejemplo con Apache, típicamente guardada (en Debian) en /etc/apache2/sites-available/midominio.mitld.conf:

<VirtualHost *:80>
 ServerAdmin webmaster@localhost
 ServerName midominio.mitld
 DocumentRoot /var/www
 <Directory />
  Options FollowSymLinks
  AllowOverride None
 </Directory>
 <Directory /var/www/>
  Options Indexes FollowSymLinks MultiViews
  AllowOverride None
  Order allow,deny
  allow from all
 </Directory>
 ScriptAlias /cgi-bin/ /usr/lib/cgi-bin/
 <Directory "/usr/lib/cgi-bin">
  AllowOverride None
  Options +ExecCGI -MultiViews +SymLinksIfOwnerMatch
  Order allow,deny
  Allow from all
 </Directory>
 ErrorLog ${APACHE_LOG_DIR}/midominio.mitld.errores
 LogLevel warn
 CustomLog ${APACHE_LOG_DIR}/midominio.mitld.accesos combined
 Alias /.well-known/acme-challenge /var/lib/dehydrated/acme-challenges/
 <Directory "/var/lib/dehydrated/acme-challenges">
  Require all granted
 </Directory>
</VirtualHost>
<IfModule mod_ssl.c>
<VirtualHost _default_:443>
 ServerAdmin webmaster@localhost
 ServerName midominio.mitld
 DocumentRoot /var/www
 <Directory />
  Options FollowSymLinks
  AllowOverride None
 </Directory>
 <Directory /var/www/>
  Options Indexes FollowSymLinks MultiViews
  AllowOverride None
  Order allow,deny
  allow from all
 </Directory>
 ScriptAlias /cgi-bin/ /usr/lib/cgi-bin/
 <Directory "/usr/lib/cgi-bin">
  AllowOverride None
  Options +ExecCGI -MultiViews +SymLinksIfOwnerMatch
  Order allow,deny
  Allow from all
 </Directory>
 ErrorLog ${APACHE_LOG_DIR}/midominio.mitld-ssl.errores
 LogLevel warn
 CustomLog ${APACHE_LOG_DIR}/midominio.mitld-ssl.accesos combined
 # SSL Engine Switch:
 # Enable/Disable SSL for this virtual host.
 SSLEngine on
 SSLCertificateFile /var/lib/dehydrated/certs/midominio.mitld/cert.pem
 SSLCertificateKeyFile /var/lib/dehydrated/certs/midominio.mitld/privkey.pem
 <FilesMatch "\.(cgi|shtml|phtml|php)$">
  SSLOptions +StdEnvVars
 </FilesMatch>
 <Directory /usr/lib/cgi-bin>
  SSLOptions +StdEnvVars
 </Directory>
</VirtualHost>
</IfModule>

El resto de la instalación es idéntico a nginx, y también con la salvedad de activar el módulo SSL después de ejecutar dehydrated -c por primera vez y por tanto tener el certificado ya preparado.

En Debian, esto se hace con la sencilla y elegante instrucción

sudo a2enmod ssl

Seguido, si es menester, por

sudo apache2ctl restart

A pasarlo pipa.

Ruby y Python

Muchos, me atrevo a decir casi todos los que trabajamos en empresas relativamente pequeñas, estamos acostumbrados a que, tarde o temprando, hay que hacer de todo. Sin ir más lejos, hoy he cambiado un interruptor de luz de la oficina. Bien, pues eso es la parte de hardware: ahora, vamos con el software.

Hace poco, me empeñé en automatizar ciertas operaciones relacionadas con dominios que se hacían a mano, con el riesgo de retrasos y errores que ello entraña y que, de hecho, han generado más de un alzar de cejas. Es un affaire en el fondo sencillo, pero hay que hablar con tres APIs de tres proveedores diferentes en tres países distintos, que no siguen una norma común más allá de lo habitual del uso de json y la filosofía REST tan de nuestros días. Ah, y generar un XML.

La primera versión, para probar, la hice en Bash a base de curl. Curl es una herramienta potente, pero el manejo de flujos de programa en Bash recuerda demasiado que el inefable señor Bourne (nada que ver con el señor Burns, aunque suene casi igual), todo lo que necesitaba era una shell para hacer cuatro cosas. Bastante lejos ha llegado.

Total, que inspirado por un programita que me enseñó un compañero, me puse a hacer una siguiente versión en Python, sin haberlo usado en la vida anteriormente, usando la metodología que nuestro desarrollador de referencia llamó SODD: Stack Overflow Driven Development. Pues bien, Python fue un lenguaje sumamente fácil de aprender para hacer algo sencillo. Las cosas salen con facilidad y, a pesar de que no pretendo ser un programador, me resultó fluido hacer un programa de 200 líneas que cumple su cometido.

Me he limitado a las librerías que vienen de serie con una instalación normal en Debian, y aún así, ha sido razonablemente sencillo encontrar lo necesario para manipulación de fechas, POST, GET, un poco de números y cadenas.

Luego decidí aprovechar para aprender Ruby, y porté el programita.

Me sucedieron inmediatamente varias cosas:

  1. No entiendo Ruby. Hay cosas que no sé por qué funcionan, y otras que no sé por qué no. Hay partes de la sintaxis que me resultan alienígenas. Esta sensación no la tengo con Python.
  2. Hay cosas extrañamente difíciles de hacer. Un POST, por ejemplo. No he encontrado forma de hacerlo si no es con una gema aparte, o con un bloque de código, o con ambas cosas. También enviar correo se me hace algo aparatoso comparado con Python.
  3. El programa engordó un 15%, especialmente por los bloques necesarios para los POST.
  4. La escritura de xml es mucho más elegante (siempre hablando de las librerías que vienen «de serie»), si bien con una sintaxis algo alienígena, pero elegante y ligera.

Total. Que el programita de los demoniosdominios lo voy a mantener con Python, y le daré otra oportunidad a Ruby cuando tenga que hacer (si llega el caso, que llegará) alguna pequeña aplicación web. Según me ha asegurado el antes aludido, en ese momento las cosas van a favor de Ruby (on Rails). Claro, que también ha dicho que el futuro es Rust… Así que no sé. Estoy por volver a Bash.

Las iDRAC molan. A veces. Salvo que te las cargues actualizando

Las iDRAC antiguas, en particular las iDRAC 6 y anteriores, tienen sus manías. Más manías cuanto más antiguo es el firmware, hasta el punto de ser poco menos que intratables: Solo funcionan con versiones prehistóricas de ie, les petan las actualizaciones, no les funciona https… En fin, esas cosillas.

A veces, es posible que una de estas iDRAC antiguas petardee al actualizar, y las cosas se van rápidamente a la alcantarilla. El peor caso que he conocido necesitó comprar un recambio. ¿Qué recambio? Ahí está lo gracioso: Dell parece hacer como si no existiera.

En los fiables (aunque ya venerables) r610, el acceso fuera de banda al servidor está compuesto de dos piezas separadas: La placa que contiene el puerto Ethernet (y que habitualmente se llama iDRAC a secas) y otra placa que se llama iDRAC express, y que no es otra cosa que una BMC glorificada. Para confundir las cosas, el firmware no va en la iDRAC, sino en la iDRAC express. Y la iDRAC express, va de serie en los r610, y no se vende como recambio normalmente. De hecho, en el esquema del servidor donde se dice dónde van hasta cosas tan raras como la licencia de iSCSI (que es una especie de llave física), no se hace ni mención a la iDRAC express, pero sí a la iDRAC, que es opcional.

Pues bien, cuando la actualización de firmware de iDRAC se va al desagüe… ¿A que no adivinas qué placa es la que se ha quedado gagá? Claro, como no podía ser de otra forma: La que «no existe».

¿La solución? Bueno, tal vez sea posible recuperarla por el método descrito aquí, usando el puerto serie virtual para acceder a la consola de recuperación. Pero si no, no hay problema: Nos vamos a eBay, y preguntamos por una iDRAC 6 express. Las he llegado a ver por un euro (mas 18 de envío). Os aseguro que es más barato que el tiempo que se puede llegar a perder peleando con una iDRAC 6 express mal flasheada (y disculpad el barbarismo). Creedme, aunque os costara 50 euros, seguiría siendo barato.

 

A vueltas con las claves SSH

SSH es un protocolo estupendo, y OpenSSH es una implementación digna de estudio por su usabilidad y pulcro mantenimiento, lo que le ha llevado a una casi ubicuidad.

Con los años, los cifrados han ido cambiando, aconsejándose unos y otros según avanza la ciencia de la criptografía. Los siguientes son los más habituales, y los primeros tres los que más he usado:

  • RSA, el clásico. Aunque desaconsejado por haber sido superado por lo último, sigue siendo la única forma de tener autenticación con clave pública en, sin ir más lejos, los también ubicuos switches Cisco Catalyst, que no conocen otra cosa. No es aconsejable usarlo para nuevas claves salvo en casos como el mencionado si hay otros más modernos.
  • DSA, el que pudo ser. Hace bastantes años, DSA prometía mejorar RSA. Sin embargo, los avances en criptografía lo acabaron poniendo en un riesgo mayor que RSA. En los OpenSSH actuales, se desaconseja usar DSA. Incluso Mac OS Sierra lo trae desactivado de serie.
  • ECDSA, una nueva esperanza. DSA con curvas elípticas. Teóricamente, un DSA sin los problemas de DSA. En la práctica, también tiene sus «problemillas»: Su seguridad depende de lo bueno que sea el generador local de números aleatorios. Ni mencionar a alguien siquiera medio paranoico.
  • Ed25519, el salvador (al menos por ahora). Un algoritmo matemáticamente fuerte, implementable con buen rendimiento, que depende menos del generador local de números aleatorios y, en fin, al que no se le conocen por ahora grietas. En resumen, el que hay que usar si se ha de elegir uno para empezar.

Por cierto. .ssh/authorized_keys2 lleva años desaconsejado, pero aún se ve en servidores por el mundo alante. Trabajando con versiones siquiera medio actuales de SSH, es recomendable mv .ssh/authorized_keys2 .ssh/authorized_keys.

FreeNAS, cada vez mejor

Lo mejor que puede ocurrir con un almacenamiento es que pase desapercibido.
Lo segundo mejor es que sea potente, escalable y demás características deseables.
Un almacenamiento pasa desapercibido cuando no genera problemas, corre lo suficiente y, en general, va como un reloj. FreeNAS lleva haciendo esto ya años.
Para extraer lo máximo de FreeNAS, no solamente en rendimiento sino también, y más importante, en resistencia a fallos, es necesario aprender unas cuantas cosas sobre ZFS. Cómo se organizan los discos en volúmenes. Cuáles son las mejores formas de mejorar el rendimiento y la fiabilidad, dependiendo del hardware de que se disponga; o qué hardware comprar, dependiendo de lo que se quiera hacer.
A fecha de este artículo, estamos convirtiendo todos nuestros almacenamientos basados en sistemas libres de RAID 10 a pilas de RAIDZ-2 de un máximo de 6 discos. Esto da un máximo de almacenamiento exportado (un 15% largo más que RAID10 con solo 6 discos) con un máximo de rendimiento.
Expandir la capacidad de una cabina cambiando los discos por otros de mayor tamaño es relativamente rápido y sencillo, siempre y cuando uno tome la precaución de leer la sección del manual que describe cómo cambiar discos. En algún caso he tenido que ir a la línea de comandos a hacer un zpool replace; nada que quede fuera del alcance de un administrador de sistemas con algunas noches en su haber. Desapercibido.
La flexibilidad, por el hecho de no usar discos con firmware propio, resulta mucho mayor que la de las cabinas «de marca» que mantenemos. Y, aunque estas últimas facilitan algunas operaciones, como el cambio de discos, no se justifica de ninguna de las maneras que cuesten a partir de tres veces más.
Con FreeNAS 9.10, estamos pasando (por recomendación suya) a instalar el sistema en un disco SSD, en lugar de un pincho USB o memoria interna SD. Uno pequeño, de 50 o 100 gigas, es ampliamente suficiente. Como no son muy caros, suelo usar los Samsung 850 Evo de 120. Más espacio libre es más espacio sobre el que repartir las escrituras y por tanto más fiabilidad.
A día de hoy, atesoramos varios años de funcionamiento con FreeNAS. Su fiabilidad ha resultado a la misma altura de las Dell, EMC y compañía. Han pasado igual de desapercibidas. Y han costado de la tercera parte para abajo por bit exportado.

Añadiendo una segunda fuente a un Mikrotik CCR 1036

Publicado originalmente en inglés en el foro de Mikrotik.
Tres de las fuentes originales petaron en solo dos semanas, todas ellas con una chepa en C10:
C10 reventado

Por ello, tuve que invertir algún tiempo en el asunto. Los resultados han sido como sigue.

La primera decisión fue fácil. Dado que las fuentes conmutadas de los 69W necesarios (según las especificaciones en http://www.cloudcorerouter.com/) no son muy caras, decidimos cambiarla por una mejor. La elegida fue la experimentada Traco Power TOP 100, aunque probablemente echaré una mirada a su nueva, y más compacta, TPI 100-124A-J más adelante. Ambas suministran 100W.

Una de las cosas más dolorosamente ausentes en los CCR 1036 es fuentes dobles. El problema es que hay poco espacio dentro de la caja, por lo que se precisa una fuente minúscula. Me decidí por la Mean Well EPS-65S. Aunque un pelín por debajo de lo requerido, permite extraer picos de 71,6W durante 10 segundos, lo cual debe ser suficiente: nunguno de nuestros CCR 1036 en producción se lleva más de 55W contínuamente. Y lo importante es que su perfil es bajo, con una altura de solo 24mm desde la base de la placa hasta la parte superior.

Para instalar esta fuente, diseñé e imprimí en 3D una base que se atornilla a la parte izquierda de la placa base del router con los tornillos originales:

second ps support

Este es el archivo original de la base en OpenSCAD.

La fuente se atornilla a esta base con tornillos, arandelas y tuercas M3.

Los conectores de las fuentes están especificados en sus respectivas hojas de características. Desgraciadamente, una usa Molex y la otra JST; ambos son baratos y fáciles de montar.

Cuando empecé a probar, me encontré con que cuando cortaba la alimentación a la Mean Well, el router rearrancaba. Creo que tira un pico de carga y este pico tira la Traco Power, porque estas fuentes no fueron diseñadas para la redundancia. Esto se resuelve insertando un diodo 1N4004 entre la salida +V de la Mean Well y la placa base. En la próxima conversión, añadiré otro diodo a la otra fuente, por si acaso.

Arreglado eso, las pruebas fueron bien. Cualquiera de las dos fuentes puede arrancar el router y mantenerlo andando durante tanto tiempo como he probado hasta ahora. El router no se entera de un corte a una sola de las fuentes.

La Traco Power se calienta un poco, pero no mucho. La Mean Well, probablemente porque su diodo mantiene su voltaje ligeramente por debajo de la otra y por tanto no recibe carga, se mantiene fría.

Un poco más de prueba en el banco, luego algo de pruebas en el centro de datos, y si no sale nada, verán luz verde para producción.

IMG_8702

qdb

Hay webs inmortales. En tiempos muy remotos, el navegador Netscape venía configurado con sendos botones titulados «What’s new» y «What’s cool». Era una época en que se podían hacer estas cosas.

Sin embargo, con todo el tiempo pasado, siguen existiendo algunos sitios que, de seguir existiendo el segundo de los botones, allí seguirían, año tras año.

Hoy, en uno de esos lugares inmortales, pasé uno de esos ratos riéndome solo (y tomado, por tanto, por loco). Y de todo lo que leí, me resulta muy difícil quedarme con algo, pero si algo mola mucho, es esto: http://www.qdb.us/305607