Cristian Vicente

En las instancias de servidor de Oracle Cloud, cuando despliegas alguna de sus imágenes, tienen preconfiguradas una serie de reglas en el cortafuegos que impiden la comunicación a los servicios más básicos como HTTP/HTTPS.

Puede llegar a ser realmente confuso porque, antes de averiguar que en una instalación limpia ya hay reglas de cortafuegos, hemos tenido que abrir puertos y configurar la red en el panel de control de Oracle. Así que podemos dejar el cortafuegos totalmente abierto y gestionar la entrada/salida desde el panel de control.

Con estos comando quitaríamos las reglas:

iptables -I INPUT -j ACCEPT

iptables-save > /etc/iptables/rules.v4

O si sólo queremos abrir ciertos puertos:

iptables -I INPUT 6 -m state –state NEW -p tcp –dport 80 -j ACCEPT sudo netfilter-persistent save

netfilter-persistent save

Para más información, hay un hilo de reddit donde se discute el tema.

Dejando atrás la limitación del sistema operativo que traía de fabrica para intentar sobrepasar el límite del sistema de ficheros ext2 y lograr hacer un RAID 0 con dos discos duros de 20TB he llegado a la conclusión de que no se puede.

Se puede formar un RAID 0 sin mayores inconvenientes instalado las herramientas disponibles en OpenWRT y utilizando este comando como en cualquier sistema Linux:

mdadm –create –verbose /dev/md0 –level=0 –raid-devices=2 /dev/sda /dev/sdb

Pero a la hora de darle formato a ese raid es cuando empiezan los problemas. Con ext4, en el proceso de inicialización del journaling, directamente se para con un error, algo que se puede saltar para que finalice el proceso y con XFS no hay inconvenientes. Pero a la hora de montar la unidad /dev/md0, en ambos, salta un error diciendo que el fichero es demasiado grande («file to large»). Intuyo que todo está relacionado con el hecho de utilizar un sistema operativo de 32bit por culpa de una CPU que no soporta instrucciones de 64bit.

Curiosamente, podemos formatear y montar el raid si utilizamos el sistema de ficheros exFAT, pero cuando empiezas a copiar ficheros en él empieza a dar errores y tiempos de espera muy largos, algo que lo hace inusable.

Supongo que este ZyXEL se quedará con dos discos de 8TB como máximo.

Hace 8 años compré por un precio más que razonable un NAS de 2 bahías de Zyxel que me permitió hacer bastantes más cosas de las oficiales gracias a repositorios de la comunidad. Pero todo tiene un límite, concretamente en lo que se refiere a su compatibilidad con discos duros de gran capacidad. Resulta que el sistema de archivos que utiliza es ext2, el cual permite un tamaño de volumen máximo de 16TiB, algo que me impedía hacer uso de dos discos duros de 20TB. Frustrado por ello busqué alternativas y encontré la posibilidad de instalar OpenWRT reescribiendo la NAND, lo cuál me permitía hacer uso de ext3 entre otras muchas cosas.

Para llevar a cabo la operación, me enfrenté con documentación incompleta desde el punto de vista de alguien que no lo había hecho nunca. Se hablaba de utilizar una conexión serie USB, de poner comandos en un terminal, hacer uso de un pendrive antiguo y de soldar cosas. Al final fue relativamente sencillo, sin soldar ni comprar nada adicional porque ya tenía en mi posesión una Raspberry Pi 2 para hacer el trabajo de conector serie USB.

Importante

El proceso puede dejar inservible el dispositivo NAS e incluso la Raspberry Pi si confundís algún cable. Así que cada uno es responsable de lo que hace.

Obtención de la MAC

Durante el proceso habrá que configurar la MAC del NAS a mano, con lo que antes de empezar sería buena idea obtenerlo.

Sacar la placa base

Para sacar la placa base hay que extraer las bahías de los discos duros, sacar un par de tornillos de la base, deslizar una parte de la carcasa sobre la otra y seguir desatornillando un poco más, nada difícil ni nada clicks. Hay un vídeo muy ilustrativo de los primeros pasos:

Conectar la Raspberry Pi

Teniendo en cuenta de que en mi caso estaba usando una Rasperry Pi 2 B y que sun GPIO difiere de otros modelos, la conexión me quedó así:

En caso de utilizar un adaptador USB serie, la conexión sería como esta:

Preparando un pendrive

Parece ser que esto es algo que da bastantes problemas, donde algunas personas han tenido que recurrir a pendrive antiguos anteriores al 2.0, pero yo me he arreglado con un Sandisk de 16GB que tenía por ahí. Lo tendremos que formatear en FAT32 y depositaremos en él dos ficheros:

• Los ficheros de u-boot en su versión 18.06.0 porque las más recientes parecen tener un bug que afecta al arranque con USB.
• El firmware de OpenWRT (la más reciente, a día de hoy la versión 22.03.5).

Colocaremos el pendrive en la placa base del NAS, procurando que sea uno de los puertos traseros 2.0.

Preparando la Raspeberry Pi

Arrancamos la Raspberry Pi (en mi caso llevaba una Hyperbian), nos logueamos y, utilizando el comando «raspi-config», dentro de «Interface options» -> «Serial Port», desactivamos el puerto serie para el login shell y activamos el puerto serie por hardware. Reiniciamos las Raspberry Pi y ya la tenemos lista.

Flasheando

Le damos corriente al NAS a través de su adaptador habitual y lo encendemos desde su botón. Desde la Raspberry Pi descargamos el u-boot y le damos una orden con él a través del USB serie que hemos montado con los cables:

wget https://archive.openwrt.org/releases/18.06.0/targets/kirkwood/generic/u-boot-nsa325/u-boot.kwb

kwboot -p -t -b u-boot.kwb -o 5 -B 115200 /dev/ttyAMA0

Nos pedirá que reiniciemos el dispositivo NAS de Zyxel, con lo que le quitaremos la corriente y se la volveremos a dar. Nos mostrará el progreso de flasheo y cuando haya terminado cargará una especie de shell interactiva en la cual tendremos que dar algunas órdenes.

usb reset
fatload usb 0 0x1000000 u-boot.kwb
nand erase 0x0 0x100000
nand write 0x1000000 0x00000 0x100000
reset

Seguiremos configurando algunas variables de entorno:

setenv mtdparts ‘mtdparts=orion_nand:0x00c0000(uboot),0x80000(uboot_env),0x7ec0000(ubi)’
setenv bootcmd ‘run setenv bootargs; ubi part ubi; ubi read 0x800000 kernel; bootm 0x800000’
saveenv
reset

Le configuraremos la MAC que tenía:

setenv ethaddr AB:CD:EF:00:00:00
saveenv

Flashearemos el fichero «openwrt-22.03.5-kirkwood-zyxel_nsa325-squashfs-factory.bin» que habíamos descargado:

usb reset
fatload usb 0 0x2000000 openwrt-22.03.5-kirkwood-zyxel_nsa325-squashfs-factory.bin
nand erase.part ubi
nand write 0x2000000 ubi 0x600000

Una vez finalizado podremos reiniciarlo con el siguiente comando:

reset

El sistema arrancará y ya tendremos disponible desde el navegador una interfaz web para configurarlo.

Fuentes:

Documentación de OpenWRT

Apuntes de Panticz.de

Hace 15 años dejé protegidos con contraseña una serie de documentos de Microsoft Word (versión XP/2003) que impedían su apertura. Con el pasar del tiempo y la contínua renovación de contraseñas, en algún momento puntual, dejé de recordar qué contraseña usé para proteger dichos documentos.

Pensé que en la actualidad no sería difícil encontrar algún mecanismo para romper el sistema de contraseñas que usaba MS Office en 2003 (MD5 + RC4) y me puse manos a la obra en busca de algún programa que me facilitase la tarea. Había dos planteamientos:

• Eliminando la solicitud de la contraseña.
• Ataque por fuerza bruta para averiguar la contraseña.

En el primer caso encontré algún artículo en Internet que, mediante la edición del documento .doc con un editor hexadecimal, eliminando la zona en la que se albergaba la contraseña se deshabilitaba la solicitud de la misma, pero no encontraba los patrones con los cuales identificarla y, tras varios intentos, aquello se convirtió en un callejón sin salida. Al menos averigüe que Office 2003 sigue funcionando en Windows 10 y de forma bastante rápida.

El segundo caso me llevó algo más de tiempo porque el mercado está lleno de páginas webs milagrosas y programas en versión demo que sólo me sirvieron para saber que la contraseña tenía más de 6 caracteres y que por fuerza bruta, con un AMD 5900X de 12 núcleos, me llevaría al menos 36 horas. Pero luego descubrí que existía una combinación de software libre bastante más potente.

Primero necesitaríamos extraer el hash de la contraseña del fichero .doc. Este trabajo lo puede hacer un script que podremos descargar desde esta URL y luego utilizaremos el proyecto de HashCat para obtener nuestro objetivo.

Teniéndolo todo en un mismo directorio, los comandos a utilizar serían los siguientes:

python3 office2hashcat.py ficheroObjetivo.doc > hash.txt

./hashcat.bin -a 3 -m 9700 hash.txt

El primer comando extrae de forma inmediata el hash de la contraseña y lo almacena en un fichero de texto «hash.txt» y tendrá el siguiente aspecto:

$oldoffice$1*04477077758555626246182730342136*b1b72ff351e41a7c68f6b45c4e938bd6*0d95331895e99f73ef8b6fbc4a78ac1a

Con lo anterior y consultando la información de la wiki de HashCat sabremos que nuestro hash-mode será el 9700 (-m 9700). Además, como carecemos de diccionario de palabras o sospechamos que no sería de utilidad para encontrar la contraseña,  indicaremos que nuestro modo de ataque será por fuerza bruta (-a 3).

Como contamos con una RTX 3800, HashCat saca provecho de ello y la utiliza para empezar el ataque que nos informa que durará como máximo alrededor de 90 minutos, bastante menos que las 36 horas que nos daban algunos programas en su versión demo. Pero el asombro llega por partida doble cuando el programa termina con éxito al cabo de 15 minutos y nos provee de una contraseña que en mi vida hubiese utilizado. Esto último se debe a las posibles colisiones que existen cuando contamos con cifrados débiles, donde dos palabras diferentes pueden tener el mismo hash.

Finalmente, la contraseña obtenida nos permite abrir esos ficheros sin mayores problemas.

Conclusiones:

• La cantidad de desinformación, de páginas web fachada y porquería inútil es cada vez mayor en Internet. Resulta dolorosamente penoso el uso de buscadores hoy en día.
• La contraseña que crees que no vas a olvidar en tu vida no existe, el paso de los años hace estragos en la memoria.
• Con un hardware comercial a la mano de mucha gente se pueden romper contraseñas en minutos, donde sólo la longitud de la misma y la dureza del cifrado ponen trabas.

Si nos encontramos un error similar al siguiente en los log’s de Seafile (sobretodo al intentar crear un fichero «.md»):

django.db.utils.OperationalError: no such column: base_filecomment.uuid_id

Se debe a que en la migración a la versión 7.0 la base de datos no sufrió los cambios necesarios y nos toca hacerlos a mano.

En el caso de utilizar MySQL nos bastará con hacer lo siguiente después de haber eliminado la tabla «base_filecomment»:

CREATE TABLE `base_filecomment` (

`id` int(11) NOT NULL AUTO_INCREMENT,
`author` varchar(255) NOT NULL,

`comment` longtext NOT NULL,
`created_at` datetime NOT NULL,

`updated_at` datetime NOT NULL,
`uuid_id` char(32) NOT NULL,

`detail` longtext NOT NULL,
`resolved` tinyint(1) NOT NULL,

PRIMARY KEY (`id`),
KEY `base_filecomment_uuid_id_4f9a2ca2_fk_tags_fileuuidmap_uuid` (`uuid_id`),

KEY `base_filecomment_author_8a4d7e91` (`author`),

KEY `base_filecomment_resolved_e0717eca` (`resolved`),

CONSTRAINT `base_filecomment_uuid_id_4f9a2ca2_fk_tags_fileuuidmap_uuid` FOREIGN KEY (`uuid_id`) REFERENCES `tags_fileuuidmap` (`uuid`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;

Si se trata de SQLite tendremos que eliminar la tabla «base_filecomment» y recrearla con lo siguiente:

CREATE TABLE «base_filecomment» (
«id» integer NOT NULL PRIMARY KEY AUTOINCREMENT,
«author» varchar(255) NOT NULL,
«comment» text NOT NULL,
«created_at» datetime NOT NULL,
«updated_at» datetime NOT NULL,
«uuid_id» char(32) NOT NULL REFERENCES «tags_fileuuidmap» («uuid»),
«detail» text NOT NULL,
«resolved» bool NOT NULL);

Partiendo del hecho de que una Ubuntu Server carece de interfaz gráfica tal cual la conocemos habitualmente, a la hora de instalar un Kodi y que sea lo único que aparezca se hace algo laborioso.

Instalaremos Kodi con lo siguiente:

add-apt-repository ppa:team-xbmc/ppa
apt install kodi

En caso de tener una tarjeta gráfica de Nvidia, instalaremos su driver propietario:

apt install ubuntu-drivers-common
ubuntu-drivers devices
ubuntu-drivers autoinstall

Observando los diferentes escritorios a los que podemos optar, yo elegí Lubuntu por su ligereza:

tasksel –list-task
tasksel install lubuntu-core
service lightdm start

Con lo anterior ya deberíamos tener una interfaz gráfica donde hacer login que hará que arranque Kodi nada más entrar. Para no necesitar introducir la contraseña podemos hacer que entre automáticamente creando un fichero «/etc/lightdm/lightdm.conf.d/50-myconfig.conf» que incluya lo siguiente:

[Seat:*]
autologin-user=nombre_de_usuario
autologin-user-timeout=0

Sin embargo, nos encontraremos con problemas para hacer passthrough de sonido a través del HDMI de la gráfica. Tendremos que crear un script que se inicie con la sesión que recoja estos comandos:

echo autospawn = no > $HOME/.config/pulse/client.conf
pulseaudio –kill > /dev/null 2>&1

Desde la comunidad Self-Hosted de Reddit encontré un repertorio lleno de alternativas de software libre para cubrir las necesidades que se nos puedan pasar por la cabeza y que podemos implantar con mayor o menor dificultad en nuestro servidor. Desde luego sirve como buen punto de partida cuando sabemos que queremos algo pero no sabemos por dónde empezar a probar proyectos.

Airsonic es un fork de Subsonic. Es software libre, programado en Java y permite hacer streaming por HTTP de una gran multitud de formatos de música. Lo que más me gusta es que me permite explorar mi colección de música bajo la estructura de carpetas, nada de etiquetas.

Requiere tener instaladas una serie de dependencias:

apt install wget openjdk-8-jre ffmpeg

La instalación no es complicada:

useradd airsonic

mkdir -p /opt/airsonic

cd /opt/airsonic

wget https://github.com/airsonic/airsonic/releases/download/v10.5.0/airsonic.war

ln -s /usr/bin/ffmpeg

chown -R airsonic:airsonic /opt/airsonic

Y para que arranque al inicio crearemos un script de este estilo («nano /etc/systemd/system/airsonic.service»):

[Unit]
Description=Airsonic Media Server
After=remote-fs.target network.target
AssertPathExists=/opt/airsonic

[Service]
Type=simple
Environment=»JAVA_JAR=/opt/airsonic/airsonic.war»
Environment=»JAVA_OPTS=-Xmx700m»
Environment=»AIRSONIC_HOME=/opt/airsonic»
Environment=»PORT=8080″
Environment=»CONTEXT_PATH=/airsonic»
Environment=»JAVA_ARGS=»
EnvironmentFile=-/etc/default/airsonic
ExecStart=/usr/bin/java \
$JAVA_OPTS \
-Dairsonic.home=${AIRSONIC_HOME} \
-Dserver.context-path=${CONTEXT_PATH} \
-Dserver.port=${PORT} \
-jar ${JAVA_JAR} $JAVA_ARGS
User=airsonic
Group=airsonic

# See https://www.freedesktop.org/software/systemd/man/systemd.exec.html
# for details
DevicePolicy=closed
DeviceAllow=char-alsa rw
NoNewPrivileges=yes
PrivateTmp=yes
PrivateUsers=yes
ProtectControlGroups=yes
ProtectKernelModules=yes
ProtectKernelTunables=yes
RestrictAddressFamilies=AF_UNIX AF_INET AF_INET6
RestrictNamespaces=yes
RestrictRealtime=yes
SystemCallFilter=~@clock @debug @module @mount @obsolete @privileged @reboot @setuid @swap
ReadWritePaths=/opt/airsonic

# You can uncomment the following line if you’re not using the jukebox
# This will prevent airsonic from accessing any real (physical) devices
PrivateDevices=yes

# You can change the following line to `strict` instead of `full`
# if you don’t want airsonic to be able to
# write anything on your filesystem outside of AIRSONIC_HOME.
ProtectSystem=full

# You can uncomment the following line if you don’t have any media
# in /home/…. This will prevent airsonic from ever reading/writing anything there.
ProtectHome=true

# You can uncomment the following line if you’re not using the OpenJDK.
# This will prevent processes from having a memory zone that is both writeable
# and executeable, making hacker’s lifes a bit harder.
#MemoryDenyWriteExecute=yes

[Install]
WantedBy=multi-user.target

Y si necesitamos añadir algún tipo de configuración especial crearemos un fichero con «nano /etc/default/airsonic» que, en principio, lleva el siguiente contenido:

# Set the location of the standalone war to use
JAVA_JAR=/opt/airsonic/airsonic.war

# Set any java opts separated by spaces
JAVA_OPTS=-Xmx700m

# Set a different location for the airsonic home.
# If this path is /opt/libresonic or even contains «libresonic»,
# the data from a previous libresonic can be used as is (i.e. without
# renaming libresonic.properties,db/libresonic*, etc
AIRSONIC_HOME=/opt/airsonic

# Change the port to listen on
PORT=8080

# Change the path that is listened to on
CONTEXT_PATH=/airsonic

# Add any java args. These are different than JAVA_OPTS in that
# they are passed directly to the program. The default is empty:
#JAVA_ARGS=

# Note that there are several settings for spring boot, not explicitly listed
# here, but can be used in either JAVA_OPTS or JAVA_ARGS. The full list
# can be found here:
# https://docs.spring.io/spring-boot/docs/1.4.5.RELEASE/reference/htmlsingle/#common-application-properties
# For example to set debug across the board:
#JAVA_ARGS=–debug

# Or to change the IP address that is listened to:
#JAVA_ARGS=–server.address=127.0.0.1

Habilitaremos el servicio:

systemctl daemon-reload

systemctl start airsonic

systemctl enable airsonic

A veces el uso de una versión inestable del entorno de escritorio puede hacer que éste sufra algún tipo de error que fuerce su cerrado y nos deje sin barra de tareas. Si en dicha ocasión reiniciar el ordenador es un inconveniente, siempre nos quedará la posibilidad de, en versiones Plasma superiores a la 5.10, usar los siguiente comandos desde un terminal o desde ALT+F2:

kquitapp5 plasmashell
kstart5 plasmashell

En versiones inferiores a Plasma 5.10, supuestamente (no lo he probado) se deben utilizar los siguientes comandos:

killall plasmashell
kstart plasmashell

Jellyfin es un gestor de contenido multimedia que permite hacer streaming de nuestra música, películas, series, etc. Es como un sustituto de Plex y Emby (del cual proviene) de código totalmente abierto y gratuito.

Existe una imagen preparado con él en Turnkey que nos permite tener funcionando el sistema en cuestión de pocos minutos.

Si queremos tener la posibilidad de trascodificar nuestro contenido puede ser que nos salga el siguiente error al querer utilizar, por ejemplo, nuestro navegador:

PlaybackErrorNoCompatibleStream

Para darle solución sólo tendremos que instalar ffmpeg de la siguiente forma:

apt install ffmpeg

Después, desde el panel de control de Jellyfin dentro de la sección de «Reproducción» tendremos que poner la siguiente ruta en «Ruta de FFmpeg:»:

/usr/bin/ffmpeg