Configuración segura de un servidor Linux y implementación de aplicaciones

Configuración segura de un servidor Linux y despliegue de aplicaciones en producción. Desplegar una aplicación es sencillo. Desplegarla de forma segura, de modo que una aplicación comprometida no derribe todo el servidor, exige disciplina, límites claros y procedimientos repetibles. Este artículo documenta un flujo probado para preparar un servidor Linux limpio, ejecutar bases de datos y aplicaciones en contenedores o como servicios aislados, y mantener el sistema seguro y mantenible.

En Q2BSTUDIO, empresa de desarrollo de software y aplicaciones a medida, aplicamos estos principios en proyectos reales de software a medida, inteligencia artificial e iniciativas de ciberseguridad. Si buscas desarrollo de aplicaciones robustas y adaptadas a tu negocio visita nuestros servicios de aplicaciones a medida. Para auditorías y pruebas de seguridad puedes conocer nuestra oferta en ciberseguridad y pentesting.

Filosofía de seguridad esencial: root no es un runtime. Una aplicación debe corresponder a un usuario de servicio. Los humanos despliegan, los servicios ejecutan. Las bases de datos son privadas por defecto. El reverse proxy es el único punto público. Asumir que alguna aplicación podrá ser comprometida y diseñar para contener esa brecha.

Paso 1 Crear un usuario administrador no root. Desde root crea un usuario normal y agrégalo a sudo: adduser dev usermod -aG sudo dev. Evita el acceso SSH directo como root y favorece sudo porque es auditable y facilita recuperación ante errores.

Paso 2 Endurecer SSH. Genera clave en tu máquina local con ssh-keygen -t ed25519 y copia la pública a /home/dev/.ssh/authorized_keys; fija permisos con chown -R dev:dev /home/dev/.ssh chmod 700 /home/dev/.ssh chmod 600 /home/dev/.ssh/authorized_keys. En /etc/ssh/sshd_config desactiva PermitRootLogin y PasswordAuthentication y asegura PubkeyAuthentication yes. Recarga SSH con sudo systemctl reload ssh.

Paso 3 Activar firewall con UFW y permitir solo lo necesario: sudo ufw allow OpenSSH sudo ufw allow 80 sudo ufw allow 443 sudo ufw enable. Solo 22, 80 y 443 deben estar públicos.

Paso 4 Instalar Docker como administrador. Trata Docker como privilegios root: solo el usuario admin debe poder usarlo. Instala desde el repositorio oficial y añade el admin al grupo docker con sudo usermod -aG docker dev. Nunca agregues usuarios de servicio al grupo docker.

Paso 5 Ejecutar bases de datos en Docker de forma segura. Reglas clave: no exponer puertos DB públicamente, bind a 127.0.0.1, usar volúmenes Docker y acceso por túnel SSH. Ejemplo PostgreSQL: docker run -d --name postgres --restart unless-stopped -e POSTGRES_USER=appuser -e POSTGRES_PASSWORD=STRONG_PASSWORD -e POSTGRES_DB=appdb -v pgdata:/var/lib/postgresql -p 127.0.0.1:5432:5432 postgres:18. Verifica con ss -tulpn | grep 5432. Importante: Docker inserta reglas de iptables y UFW puede no aplicarse a puertos publicados; vincular a 127.0.0.1 evita exposición externa.

Paso 6 Acceso a bases de datos mediante túnel SSH: desde tu máquina local ejecuta ssh -N -L 5432:127.0.0.1:5432 dev@SERVER_IP y conéctate a Host 127.0.0.1 Port 5432. Conexión cifrada y segura.

Paso 7 Una clave de deploy por repositorio. Genera en el servidor una clave SSH dedicada por repositorio con ssh-keygen -t ed25519 -C deploy-myapp -f ~/.ssh/id_ed25519_myapp y añade la pública como Deploy key en GitHub con acceso solo lectura. Clonar mediante alias SSH evita exponer tokens y simplifica permisos.

Paso 8 Crear un usuario de servicio por aplicación. Ejecuta cada app con su propio usuario sin shell ni home: sudo adduser --system --no-create-home --group --shell /usr/sbin/nologin svc-myapp. Este usuario no debe poder SSH ni sudo y debe poseer solo su carpeta de aplicación.

Paso 9 Clonar y construir como admin. Desde el usuario admin clona y construye: cd /var/apps git clone git@github.com-myapp:org/repo.git npm ci npm run build npm prune --production. Los humanos construyen; los servicios solo ejecutan binarios o artefactos listos.

Paso 10 Variables de entorno build vs runtime. Nunca subir variables sensibles a Git. Guardar variables de runtime en un archivo gestionado por el sistema, por ejemplo /etc/systemd/system/myapp.env, propiedad de root y cargado por systemd. Para Next.js, variables que empiecen por NEXT_PUBLIC_ deben estar disponibles en build time; en ese caso construir con el env exportado: sudo -E bash -c 'set -a; source /etc/systemd/system/myapp.env; set +a; npm run build'. Para builds standalone de Next.js copiar activos estáticos manualmente en .next/standalone para evitar 404 en assets.

Paso 11 Transferir propiedad al usuario de servicio tras el build: sudo chown -R svc-myapp:svc-myapp /var/apps/myapp sudo chmod -R o-rwx /var/apps/myapp. Esto garantiza separación entre quien despliega y quien ejecuta.

Paso 12 Ejecutar la app con systemd y endurecer el servicio. Ejemplo de unidad systemd con opciones de hardening como NoNewPrivileges, ProtectSystem, PrivateTmp y UMask restrictiva. Habilita y arranca con sudo systemctl daemon-reload sudo systemctl enable myapp sudo systemctl start myapp. Estas restricciones limitan escaladas de privilegio y movimientos laterales.

Paso 13 Frontends estáticos. Aplicaciones React o Vite se construyen y sirven desde el reverse proxy sin runtime. Inyecta variables públicas durante el build en .env.production y ejecuta npm run build. Da acceso de solo lectura al servidor web, por ejemplo sudo chown -R svc-frontend:svc-frontend /var/apps/frontend sudo chmod -R 755 /var/apps/frontend/dist. Las apps estáticas reducen drásticamente la superficie de ataque.

Paso 14 Reverse proxy como único punto público. Caddy, Nginx o un proxy administrado debe ser la única entrada a tu servidor. Ejemplo: la app interna escucha 127.0.0.1:5000 y el reverse proxy hace reverse_proxy a ese puerto. Las rutas estáticas se sirven directamente desde el filesystem. Esta arquitectura mantiene abiertos solo los puertos 80 y 443 y evita que las aplicaciones expongan puertos al internet.

Paso 15 Actualizar una app de forma segura. Para desplegar cambios, temporalmente dar permisos al admin, actualizar y reconstruir, luego restituir propiedad al usuario de servicio y reiniciar systemd: sudo chown -R dev:dev /var/apps/myapp cd /var/apps/myapp git pull npm ci npm run build sudo chown -R svc-myapp:svc-myapp /var/apps/myapp sudo chmod -R o-rwx /var/apps/myapp sudo systemctl restart myapp. Nunca hagas sudo git pull desde el directorio del servicio en ejecución.

Qué protege esta configuración: escalada de privilegios, movimiento lateral entre aplicaciones, fugas accidentales de datos, bases de datos expuestas y compromiso a nivel root a partir de fallos en una sola app. Incluso si una aplicación se ve comprometida el resto del sistema y los datos críticos permanecen protegidos.

En Q2BSTUDIO aplicamos estos patrones en proyectos de inteligencia artificial, soluciones de ia para empresas, agentes IA, servicios cloud aws y azure, servicios inteligencia de negocio y power bi, y automatización de procesos. Ofrecemos entrega de software personalizado y consultoría en ciberseguridad para garantizar despliegues seguros y escalables. Si te interesa potenciar tu negocio con IA y soluciones seguras consulta nuestra página de inteligencia artificial en servicios de inteligencia artificial o contacta para una auditoría de seguridad y despliegue profesional.

Conclusión Seguridad no es solo herramientas. Es establecer límites claros, defaults conservadores y procesos repetibles. Evita la complejidad innecesaria y confía en las capacidades nativas de Linux, contenedores y systemd para mantener un entorno de producción robusto. Siguiendo este flujo tu servidor estará más protegido que la mayoría de entornos de producción convencionales. Feliz y seguro despliegue.