Este post es el primero de una serie donde explico algunos ejercicios realizados con Zimablade.

Zimablade es un pequeño servidor compacto, con las siguientes especificaciones técnicas:

CPU:
quad-core option (7700): Intel® Celeron with 2.4 GHz Turbo Speed
Intel® AES New Instructions
Intel® Virtualization Technology (VT-x)
Intel® Virtualization Technology for Directed I/O (VT-d)
Memory: SODIMM slot, compatible with 16 GB DDR3L RAM
Storage: Integrated 32 GB eMMC
Network: 1 x 10/100/1000 Mbps Gigabit Ethernet
Display:
1 x 4K MiniDP @ 60 Hz
1 x board-to-board eDP interface
Graphics:
Up to 700 MHz
Intel® Quick Sync Video
Intel® Clear Video HD Technology
Intel® Clear Video Technology
PCIe: 1 x PCIe 2.0, four lanes
USB:
1 x USB Type-C (data + power + display)
1 x USB 3.0
2 x USB 2.0
SATA: 2 x SATA 3.0
Power: 36 W USB Type-C power adapter
Thermal: 6 W TDP with passive cooling
Dimensions: 107 mm x 80 mm x 23 mm

Puede servir como servidor NAS para la red LAN, router seguro (con pfsense/OPNsense), servidor cloud (Nextcloud/Owncloud), o utilizando los servicios originales que vienen con CasaOS (basado en Debian) o ZimaOS (la versión pro, con algunas funcionalidades extra como chatear con los documentos mediante IA).
Ya que el espacio de la eMMC integrada es bastante limitado, le he instalado un disco duro SATA de 1TB como almacenamiento extra.

El diseño de la cubierta de la placa, es muy sencillo y con sólo un par de tornillos se puede desmontar completamente, para instalarle la memoria RAM o para cualquier otro caso.
Aunque el sistema de refrigeración pasiva integrado, impide que se sobresaliente, lo he colocado sobre una base de ventiladores de portátil, para bajarle aún más la temperatura de funcionamiento.

Con la idea de montar un laboratorio de hacking y pentesting, en esta serie voy a explicar cuales fueron los pasos y la experiencia en general utilizando Zimablade como laboratorio de redes con GNS3.

Instalación en Ubuntu 24.04:

Una vez ejecutados los pasos de instalación indicados en la documentación oficial de GNS3, eligiendo entre instalar el servicio localmente o en una máquina virtual.
En mi caso lo he instalado localmente, ya que de esa forma directamente puedo dar conectividad a mis compañeros de equipo con Tailscale, de forma muy transparente y sin complicadas configuraciones de red (cuantos menos puntos de fallo en el sistema, menos problemas en un futuro).

Queremos que el servidor de GNS3 se inicie al arrancar el sistema, para lo cual podemos usar systemd, creándole un servicio:

sudo nano /etc/systemd/system/gns3server.service

Con el siguiente contenido:

[Unit]
Description=GNS3 Server
After=network.target

[Service]
Type=simple
ExecStart=/usr/bin/gns3server
User=gns3
Group=gns3
Restart=on-failure

[Install]
WantedBy=multi-user.target

Tanto el usuario como el grupo se deben ajustar a la configuración que se ha realizado en el sistema.

Reiniciamos la configuración de systemd para que reconozca el servicio:

sudo systemctl daemon-reload

Y le indicamos que inicie el servicio en el arranque:

sudo systemctl enable gns3server

Tras reiniciar el servidor, comprobamos que el servicio se encuentra funcionando correctamente:

sudo systemctl status gns3server

O directamente abriendo la interfaz web de GNS3 desde cualquier equipo que tenga permitido el acceso.

Vamos ahora con la configuración del cortafuegos. En este ejemplo solamente vamos a tener funcionando los servicios SSH y GNS3, accesibles para conexiones desde la LAN y desde la VPN de Tailscale. Le indicamos esta configuración a ufw:

sudo ufw allow from 192.168.1.0/24 to any port 22 proto tcp
sudo ufw allow from 100.64.0.0/10 to any port 22 proto tcp
sudo ufw allow from 192.168.1.0/24 to any port 3080 proto tcp
sudo ufw allow from 100.64.0.0/10 to any port 3080 proto tcp
sudo ufw deny to any port 3080 proto tcp

Resolución de problemas

En esta versión de Ubuntu, nos encontramos con algunas restricciones a la hora de ejecutar espacios de nombre de usuario, lo que mejora la seguridad frente a exploits, pero también puede limitar el buen funcionamiento de algunos servicios, que deberán añadirse a las políticas de AppArmor.
En caso de problemas al configurar algún servicio, podemos desactivar temporalmente esta medida con:

sudo sysctl -w kernel.unprivileged_userns_clone=0

Una vez verificado si el problema con el servicio es debido a AppArmor o a otro motivo, la volvemos a activar:

sudo sysctl -w kernel.unprivileged_userns_clone=1

En el siguiente artículo de la serie, repasaremos la configuración específica de GNS3, y algunos nodos de ejemplo, que compondrían la primera versión del laboratorio de Hacking.