Cómo blindar una pyme () proteger una pequeña oficina paso a paso

Montar una pequeña oficina segura no consiste en instalar un antivirus y dar el trabajo por terminado. La seguridad real aparece cuando varias capas trabajan juntas:

  • router correctamente configurado;
  • red de trabajo separada de invitados;
  • servidor con servicios mínimos;
  • ordenadores con privilegios limitados;
  • autenticación fuerte;
  • copias de seguridad que realmente puedan restaurarse.

En esta guía vamos a montar un ejemplo práctico utilizando:

  • un router del operador como salida a Internet;
  • un router GL.iNet Slate AX como red principal;
  • un miniPC con Ubuntu Server;
  • un portátil con Windows 11;
  • llaves FIDO para autenticación;
  • y un disco USB para copias de seguridad.


 

Importante: esta guía utiliza una arquitectura concreta como ejemplo. Las direcciones IP, nombres de interfaces y menús pueden variar. Antes de aplicar cualquier cambio, adapta los pasos a tu propia red y conserva una vía de acceso por si necesitas revertir la configuración.

1. Qué queremos conseguir

El objetivo no es “hacer la red inexpugnable”. El objetivo es reducir superficie de ataque y evitar errores habituales.

La arquitectura general será:

Internet
   ↓
Router del operador
   ↓
GL.iNet Slate AX
   ├── Red de trabajo
   │      ├── Windows 11
   │      └── Ubuntu Server
   │
   └── Red de invitados
          ├── móviles
          ├── visitas
          └── dispositivos menos confiables

La filosofía de CIBERMURO es sencilla:

Reducir lo que está expuesto, comprobar lo que está activo y no cambiar nada sin entender antes su función.

2. Primer nivel: asegurar el router del operador

El router proporcionado por el operador continúa siendo nuestra puerta de salida a Internet. Por eso conviene simplificarlo y reducir servicios que no necesitamos.

Las primeras comprobaciones son:

  • cambiar la contraseña de administración;
  • desactivar WPS;
  • desactivar UPnP si no existe una necesidad concreta;
  • revisar reglas NAT o puertos abiertos;
  • eliminar reglas que no reconozcamos;
  • dejar la red Wi-Fi principal en manos del router que utilizaremos para la oficina.

Después conectamos: 

Router operador · LAN
        ↓
Slate AX · WAN

De esta forma el Slate AX pasa a gestionar nuestra red interna.

3. Segundo nivel: configurar el Slate AX

El siguiente paso es convertir el segundo router en el centro real de la red de trabajo.

Actualizar antes de configurar

Antes de empezar con reglas y servicios:

  • cambiar la contraseña de administrador;
  • instalar el firmware disponible;
  • reiniciar y comprobar que todo sigue funcionando.

Configurar la Wi-Fi

Para las bandas de 2,4 y 5 GHz:

  • utilizar un nombre que no revele información innecesaria;
  • usar WPA2/WPA3 o WPA3 si todos los dispositivos lo soportan;
  • utilizar una contraseña larga y única.

Separar invitados y dispositivos secundarios

Una medida especialmente útil es disponer de una red de invitados independiente.

Por ejemplo:

RED DE TRABAJO
├── portátil
├── servidor
└── equipos profesionales

RED DE INVITADOS
├── visitas
├── móviles secundarios
├── televisión
└── dispositivos que no necesitan acceder al servidor

Cuando el router lo permita, activa aislamiento entre clientes y evita que la red de invitados pueda acceder al panel de administración o a la red interna.

Reservar direcciones IP

Para equipos que actúan como servidor o cliente habitual puede resultar útil reservar direcciones conocidas.

Ejemplo:

Servidor Ubuntu → 192.168.8.10
Portátil Windows → 192.168.8.20

No es obligatorio utilizar estas direcciones. Lo importante es mantener una configuración coherente y documentada.

4. DNS y reducción de superficie

En un router compatible podemos añadir una capa adicional de filtrado DNS.

Por ejemplo, AdGuard Home puede utilizar un resolvedor cifrado y con filtrado de dominios maliciosos.

También conviene revisar:

  • protección frente a DNS rebinding;
  • uso del DNS del router por los clientes;
  • acceso remoto al panel de administración;
  • servicios en la nube del fabricante que no estemos utilizando;
  • puertos abiertos innecesarios.

Una buena regla general es:

Si un servicio no se utiliza, no debería estar expuesto.

5. Preparar Ubuntu Server

El servidor debe empezar con una configuración mínima y actualizada.

Actualizar e instalar herramientas básicas

sudo apt update
sudo apt full-upgrade -y

sudo apt install -y unattended-upgrades ufw fail2ban
sudo dpkg-reconfigure -plow unattended-upgrades

Las actualizaciones automáticas de seguridad reducen el riesgo de mantener vulnerabilidades conocidas durante largos periodos.

Ubuntu Pro y Livepatch

Si disponemos de Ubuntu Pro podemos asociar el equipo y activar Livepatch: 

sudo pro attach TU_TOKEN
sudo pro enable livepatch

6. Firewall del servidor: permitir solo lo necesario

La idea es sencilla: 

Entrada → denegada por defecto
Salida  → permitida

Por ejemplo:

sudo ufw default deny incoming
sudo ufw default allow outgoing

Después permitimos únicamente los servicios necesarios desde equipos concretos.

Ejemplo para un portátil con IP reservada:

sudo ufw allow from 192.168.8.20 to any port 22 proto tcp
sudo ufw allow from 192.168.8.20 to any port 445 proto tcp

sudo ufw enable
sudo ufw status verbose

Así el servidor no acepta conexiones indiscriminadamente desde toda la red.

Si posteriormente añadimos otro equipo autorizado, podemos crear reglas equivalentes para su dirección IP.

7. Reducir ataques de fuerza bruta

Para SSH podemos añadir Fail2ban: 

sudo systemctl enable --now fail2ban
sudo fail2ban-client status sshd

No sustituye a una buena autenticación, pero añade otra capa frente a intentos repetitivos.

8. Compartir archivos con Samba

Si necesitamos utilizar el servidor como almacenamiento de archivos: 

sudo apt install -y samba

sudo mkdir -p /srv/empresa
sudo chown TU_USUARIO: /srv/empresa
sudo smbpasswd -a TU_USUARIO

Un ejemplo de configuración sería:

[global]
   server min protocol = SMB3
   smb encrypt = required

[empresa]
   path = /srv/empresa
   valid users = TU_USUARIO
   read only = no
   browseable = no

Después:

sudo systemctl restart smbd

La idea vuelve a ser la misma: habilitar únicamente aquello que realmente necesitamos.

9. Comprobar qué servicios están escuchando

Una de las comprobaciones más útiles en un servidor Linux es: 

sudo ss -tulpn

Esta orden permite revisar qué procesos están escuchando conexiones.

En nuestro ejemplo deberían aparecer únicamente los servicios que hemos decidido utilizar, como SSH y Samba.

Si aparece algo inesperado, primero debemos identificarlo. No conviene cerrar servicios a ciegas.

10. Preparar Windows 11

El portátil de trabajo también forma parte del modelo de seguridad.

Las comprobaciones básicas incluyen:

  • Windows Update al día;
  • BIOS y controladores actualizados;
  • cuenta estándar para el trabajo cotidiano;
  • cuenta administrativa reservada para elevaciones;
  • cifrado de dispositivo o BitLocker;
  • SmartScreen y protección basada en reputación;
  • Firewall activo;
  • Escritorio remoto desactivado si no se necesita;
  • Windows Hello y bloqueo automático.

Cuenta estándar para trabajar

Una de las medidas más sencillas y útiles consiste en no utilizar privilegios administrativos para el trabajo cotidiano.

El esquema sería:

Trabajo diario
   ↓
Cuenta estándar

Instalación / cambio administrativo
   ↓
UAC
   ↓
Credenciales de administrador

Esta separación reduce el impacto de determinadas acciones accidentales o maliciosas.

11. Conectar Windows al servidor

Desde el Explorador de archivos podemos conectar el recurso compartido: 

\\192.168.8.10\empresa

Las credenciales deben corresponder al usuario configurado en Samba.

12. Añadir autenticación con llaves FIDO

Las llaves físicas permiten reforzar cuentas compatibles y también pueden utilizarse para SSH.

Es recomendable disponer al menos de:

  • una llave principal;
  • una segunda llave de respaldo;
  • códigos de recuperación conservados fuera del equipo habitual.

No conviene que la única llave y los únicos códigos de recuperación estén en el mismo lugar.

13. SSH utilizando una llave física

En Windows podemos crear una clave SSH respaldada por una llave compatible con FIDO: 

ssh-keygen -t ed25519-sk -C "equipo-fido"

Si la llave no admite ese tipo:

ssh-keygen -t ecdsa-sk -C "equipo-fido"

Después copiamos la clave pública al servidor y comprobamos que podemos iniciar sesión correctamente.

Solo después de confirmar que la autenticación mediante clave funciona debemos plantearnos desactivar el acceso mediante contraseña.

14. Desactivar contraseña en SSH

Podemos utilizar un fichero específico:

sudo nano /etc/ssh/sshd_config.d/99-cibermuro.conf

Contenido:

PasswordAuthentication no
KbdInteractiveAuthentication no
PermitRootLogin no
PubkeyAuthentication yes

Después:

sudo systemctl restart ssh

No cierres la sesión SSH que ya funciona todavía. Abre una segunda conexión y comprueba primero que puedes entrar utilizando la llave. Si algo falla, la sesión anterior seguirá permitiéndote corregir la configuración.

15. Copias de seguridad: no basta con hacerlas

Una copia de seguridad solo es útil si puede restaurarse.

Para este ejemplo utilizaremos un disco USB conectado al servidor y Restic como herramienta de backup.

Preparar el disco

lsblk

sudo mkfs.ext4 -L COPIAS /dev/sdX1
sudo mkdir -p /mnt/copias

Atención: formatear una partición elimina los datos existentes. Comprueba cuidadosamente cuál es el dispositivo antes de ejecutar mkfs.

Crear un repositorio Restic

sudo apt install -y restic

sudo sh -c 'umask 077; openssl rand -base64 32 > /root/.restic-pass'

sudo restic \
  -r /mnt/copias/restic \
  --password-file /root/.restic-pass \
  init

La contraseña del repositorio debe conservarse de forma segura. Sin ella no podremos recuperar las copias cifradas.

16. Automatizar las copias

Podemos crear un script como:

#!/bin/bash

set -e

export RESTIC_REPOSITORY=/mnt/copias/restic
export RESTIC_PASSWORD_FILE=/root/.restic-pass

mountpoint -q /mnt/copias || exit 1

restic backup /srv /etc /home

restic forget \
  --keep-daily 7 \
  --keep-weekly 4 \
  --keep-monthly 6 \
  --prune

restic check

Después le damos permisos:

sudo chmod 700 /usr/local/bin/copia.sh

Y hacemos una primera ejecución manual:

sudo /usr/local/bin/copia.sh

Solo después de comprobar que funciona tiene sentido automatizarla.

17. Probar la restauración

Este paso es tan importante como crear la copia.

Podemos listar los snapshots:

sudo restic \
  -r /mnt/copias/restic \
  --password-file /root/.restic-pass \
  snapshots

Y restaurar temporalmente el último:

sudo restic \
  -r /mnt/copias/restic \
  --password-file /root/.restic-pass \
  restore latest \
  --target /tmp/prueba

Después comprobamos los archivos recuperados.

CIBERMURO: una copia que nunca se ha intentado restaurar es una copia cuya utilidad real todavía no hemos comprobado.

18. La segunda copia debe estar en otro lugar

Un disco permanentemente conectado al mismo servidor protege frente a algunos fallos, pero no frente a todos.

Conviene disponer de otra copia físicamente separada.

Por ejemplo:

  • rotación de dos discos;
  • uno de ellos guardado fuera de la oficina;
  • o un segundo destino remoto correctamente protegido.

El objetivo es que un único incidente no pueda destruir al mismo tiempo los datos originales y todas sus copias.

19. Checklist final

Antes de considerar terminado el montaje, comprobar:

  • ☐ La red de invitados no accede al router de administración ni al servidor.
  • ☐ El acceso SSH funciona mediante la llave autorizada.
  • ☐ UFW está activo y únicamente permite los servicios necesarios.
  • ☐ Windows puede acceder al recurso compartido autorizado.
  • ☐ Windows 11 está actualizado y utiliza una cuenta estándar para el trabajo cotidiano.
  • ☐ Firewall, SmartScreen y cifrado están revisados.
  • ☐ Existe al menos una copia de seguridad reciente.
  • ☐ Se ha realizado una restauración de prueba.
  • ☐ Las cuentas importantes disponen de autenticación fuerte y método de recuperación.

20. Mantenimiento: la seguridad no termina el día de la instalación

Una configuración segura hoy puede dejar de serlo dentro de unos meses.

Como rutina básica:

  • revisar regularmente actualizaciones;
  • comprobar los clientes conectados al router;
  • revisar reglas y servicios que ya no sean necesarios;
  • examinar los logs de las copias;
  • restaurar periódicamente algún fichero de prueba;
  • mantener firmware y software soportados.

Conclusión

Blindar una pequeña oficina no consiste en activar una única opción.

La protección aparece al combinar varias capas:

Router
  +
Segmentación de red
  +
Firewall
  +
Cuenta estándar
  +
Cifrado
  +
Autenticación fuerte
  +
Servidor mínimo
  +
Copias verificadas
       ↓
Menor superficie de ataque

Y hay una idea especialmente importante:

No basta con activar controles de seguridad.
Hay que comprobar qué protegen, verificar que funcionan y saber cómo recuperar el sistema cuando algo falle.

Ese es precisamente el enfoque de CIBERMURO: detectar primero, explicar después y cambiar únicamente aquello que entendemos.

CIBERMURO
Ciberseguridad práctica para usuarios y pequeños entornos profesionales.
cibermuro.es