[{"data":1,"prerenderedAt":195},["ShallowReactive",2],{"seo-verification":3,"blog-hardening-linux-vps-checklist-para-agencias-tras-la-entrega-es":6},{"google":4,"bing":5},"EycwPY2XMyTkVzas3n1ygeNJFGAH513qrMjfDljzsMQ","",{"key":7,"data":8},"blog-hardening-linux-vps-checklist-para-agencias-tras-la-entrega-es",{"id":9,"slug":10,"slugs":11,"title":15,"excerpt":16,"readTime":17,"views":18,"isPinned":19,"publishedAt":20,"updatedAt":21,"category":22,"categories":28,"featuredImage":30,"bgImage":31,"posterImage":32,"relatedSolution":30,"intro":33,"sections":34,"ctaTitle":145,"ctaBody":146,"ctaButton":147,"ctaUrl":148,"relatedPosts":149},317,"hardening-linux-vps-checklist-para-agencias-tras-la-entrega",{"fr":12,"en":13,"ar":14,"es":10},"linux-hardening-vps-checklist","linux-vps-hardening-checklist-for-agencies","قائمة-تصليب-خادم-لينكس-للوكالات-بعد-التسليم","Hardening Linux VPS : checklist para agencias tras la entrega","Checklist de hardening Linux reproducible para agencias: auditd, sudo, clave SSH, UFW, fail2ban y desactivación de root — con trazabilidad por cliente.",11,1,false,"2026-08-30T00:00:00+00:00","2026-09-07T11:26:10+00:00",{"id":23,"name":24,"slug":25,"color":26,"icon":27},8,"Seguridad y monitorización","securite-monitoring","bg-rose-500\u002F10 text-rose-400","security",[29],{"id":23,"name":24,"slug":25,"color":26,"icon":27},null,"\u002Fblog\u002Fcovers\u002Fbg.svg","\u002Fblog\u002Fcovers\u002Flinux-hardening-vps-checklist-poster.svg","Tu agencia entrega un VPS y cada técnico aplica «más o menos lo mismo» — sin un runbook escrito, sin rastro documentado. Cuando ocurre un incidente, no puedes demostrar que la configuración de seguridad acordada fue realmente aplicada. Esta guía comienza donde termina el tutorial individual: estandarización, delegación y trazabilidad para gestionar una cartera de servidores cliente.",[35,39,49,52,62,71,80,86,92,101,104,136,139,142],{"type":36,"title":37,"body":38},"h2","Por qué un runbook formalizado lo cambia todo para una agencia","Un desarrollador individual puede aplicar mentalmente cinco comandos tras cada entrega. Una agencia no puede: varios técnicos, decenas de VPS de clientes, turnos de guardia rotativos. Cuando un cliente informa de un acceso sospechoso seis meses después del lanzamiento, la pregunta no es «¿asegurasteis el servidor?» sino «¿podéis demostrarlo?\"\n\nLa trazabilidad se ha convertido en un requisito contractual y regulatorio. La directiva **NIS2** (en proceso de transposición al derecho nacional) y el **RGPD** obligan a los prestadores que tratan datos personales a documentar las medidas de seguridad implementadas. Sin un runbook versionado y sin registros `auditd`, tu agencia no dispone de ningún documento oponible.\n\nEsta guía no vuelve a describir la instalación de fail2ban o UFW — los artículos \u003Ca href=\"\u002Fblog\u002Fproteger-vps-fail2ban\">Proteger un VPS con fail2ban\u003C\u002Fa> y \u003Ca href=\"\u002Fblog\u002Fpare-feu-ufw-vps\">Firewall UFW en VPS\u003C\u002Fa> lo hacen en detalle. Opera a un nivel superior: cómo estandarizar, delegar y rastrear estos gestos a escala de una cartera completa de clientes.",{"type":40,"title":41,"items":42},"ul","Lo que este runbook aporta a tu agencia",[43,44,45,46,47,48],"**Reproducibilidad**: cada técnico sigue exactamente los mismos pasos, en el mismo orden, en cada nuevo VPS cliente.","**Trazabilidad**: `auditd` registra quién hizo qué, cuándo y qué comando — prueba conservable en caso de incidente o auditoría de cliente.","**Delegación segura**: un junior puede entregar un servidor endurecido sin improvisar, porque el runbook contiene las decisiones en su lugar.","**Defensa contractual**: una cláusula de seguridad en tu contrato de mantenimiento solo es defendible con un registro de ejecución fechado.","**Reducción de la superficie de ataque**: la checklist elimina los olvidos clásicos — root SSH abierto, auditd sin activar — los puntos de entrada más explotados.","**Consistencia entre clientes**: misma base segura para todos, diferencias solo donde el pliego de condiciones del cliente lo exija.",{"type":36,"title":50,"body":51},"Requisitos previos y alcance de la checklist","Esta checklist está dirigida a **Ubuntu 24.04 LTS** y **Debian 12** (Bookworm), las dos distribuciones más comunes en VPS en 2026. Los comandos han sido verificados en estos sistemas; en AlmaLinux o Rocky Linux, los nombres de paquetes y las rutas de servicio difieren.\n\nRequisitos mínimos del VPS: 1 vCPU, 1 GB de RAM (2 GB recomendados cuando fail2ban y auditd corren juntos), 20 GB SSD. ServOrbit entrega cada VPS con acceso root SSH inmediato y consola KVM incluida, lo que permite a tu agencia aplicar este runbook desde el primer minuto — sin necesidad de solicitar acceso intermediario al proveedor.\n\nLa checklist está organizada en **siete bloques**, en orden de aplicación. Se detiene en el perímetro básico del sistema: la seguridad de aplicaciones (backoffice expuesto, superficies de ataque de aplicaciones) se trata por separado en \u003Ca href=\"\u002Fblog\u002Fbackoffice-vps-surfaces-attaque-oubliees-2026\">Backoffice expuesto: las superficies de ataque olvidadas en VPS\u003C\u002Fa>.",{"type":53,"title":54,"steps":55},"steps","Bloque 1 — Actualizaciones e inventario inicial",[56,59],{"title":57,"body":58},"Actualización del sistema e inventario","La primera acción tras el login como root es llevar el sistema a su nivel de parches actual.\n\n```bash\napt update && apt upgrade -y\napt install -y auditd audispd-plugins curl gnupg2 ufw fail2ban\n```\n\nRegistra en tu runbook: la fecha, la versión del kernel (`uname -r`) y la lista de paquetes instalados (`dpkg -l > \u002Froot\u002Finventory-$(date +%F).txt`). Este archivo de inventario constituye la **línea base** del servidor en la entrega — es el documento que presentarás si un cliente cuestiona el estado inicial de su máquina.\n\n**Referencia CIS Benchmark**: control CIS 1.1 (Ubuntu Linux 24.04 LTS Benchmark, sección «Configuración inicial»).",{"title":60,"body":61},"Activar actualizaciones de seguridad automáticas","```bash\napt install -y unattended-upgrades\ndpkg-reconfigure --priority=low unattended-upgrades\n```\n\nVerifica que la línea `Unattended-Upgrade::Allowed-Origins` incluya `${distro_id}:${distro_codename}-security`. Para una cartera de clientes, activa las actualizaciones automáticas y programa una revisión mensual de las actualizaciones no relacionadas con seguridad — requieren validación humana.\n\n**Referencia CIS**: control CIS 1.9 (Garantizar que se instalen actualizaciones, parches y software de seguridad adicional).",{"type":53,"title":63,"steps":64},"Bloque 2 — Usuario sudo y bloqueo de root",[65,68],{"title":66,"body":67},"Crear una cuenta de administración dedicada","Nunca uses `root` para las tareas habituales. Crea una cuenta nominativa por técnico o una cuenta de servicio de agencia:\n\n```bash\nuseradd -m -s \u002Fbin\u002Fbash adminagencia\nusermod -aG sudo adminagencia\npasswd adminagencia\n```\n\n**Consejo para la agencia**: usa un nombre de cuenta identificable en los logs (`juan.garcia` o `agency-admin`), no un genérico `admin`. Cuando `auditd` registra una acción, queda registrada la cuenta ejecutante — un nombre genérico inutiliza la auditoría.",{"title":69,"body":70},"Deshabilitar el login root por SSH","```bash\nsed -i 's\u002F^#\\?PermitRootLogin.*\u002FPermitRootLogin no\u002F' \u002Fetc\u002Fssh\u002Fsshd_config\ngrep PermitRootLogin \u002Fetc\u002Fssh\u002Fsshd_config\n```\n\nAtención: solo recarga `sshd` **después** de verificar que tu usuario sudo puede conectarse y ejecutar `sudo su`. De lo contrario te quedarás sin acceso al servidor.\n\n**Referencia CIS**: control CIS 5.2.8 (Garantizar que el login root SSH esté deshabilitado).",{"type":53,"title":72,"steps":73},"Bloque 3 — Autenticación por clave SSH",[74,77],{"title":75,"body":76},"Desplegar la clave pública de la agencia","```bash\nmkdir -p \u002Fhome\u002Fadminagencia\u002F.ssh\nchmod 700 \u002Fhome\u002Fadminagencia\u002F.ssh\necho \"\u003CCLAVE_PUBLICA_AGENCIA>\" >> \u002Fhome\u002Fadminagencia\u002F.ssh\u002Fauthorized_keys\nchmod 600 \u002Fhome\u002Fadminagencia\u002F.ssh\u002Fauthorized_keys\nchown -R adminagencia:adminagencia \u002Fhome\u002Fadminagencia\u002F.ssh\n```\n\n**Consejo para la agencia**: mantén un repositorio versionado de claves públicas (un archivo por técnico, rotación anual). Cada clave desplegada en un VPS cliente debe estar referenciada en ese repositorio — es lo que permite revocar el acceso cuando un colaborador deja el equipo.",{"title":78,"body":79},"Deshabilitar la autenticación por contraseña","Una vez verificada la clave (prueba desde otro terminal antes de confirmar):\n\n```bash\nsed -i 's\u002F^#\\?PasswordAuthentication.*\u002FPasswordAuthentication no\u002F' \u002Fetc\u002Fssh\u002Fsshd_config\nsed -i 's\u002F^#\\?ChallengeResponseAuthentication.*\u002FChallengeResponseAuthentication no\u002F' \u002Fetc\u002Fssh\u002Fsshd_config\nsystemctl reload sshd\n```\n\n**Referencia CIS**: control CIS 5.2.19 (Garantizar que la autenticación SSH por contraseña esté deshabilitada).",{"type":53,"title":81,"steps":82},"Bloque 4 — Firewall UFW",[83],{"title":84,"body":85},"Configurar UFW con política de denegación por defecto","```bash\nufw default deny incoming\nufw default allow outgoing\nufw allow 22\u002Ftcp comment 'SSH agencia'\nufw allow 80\u002Ftcp comment 'HTTP'\nufw allow 443\u002Ftcp comment 'HTTPS'\nufw --force enable\nufw status verbose\n```\n\nAbre solo los puertos realmente utilizados por el proyecto del cliente. Si la aplicación del cliente no usa un puerto de correo directo, no lo abras.\n\nPara la instalación de fail2ban y las opciones avanzadas de UFW, consulta los artículos dedicados: \u003Ca href=\"\u002Fblog\u002Fproteger-vps-fail2ban\">Proteger un VPS con fail2ban\u003C\u002Fa> y \u003Ca href=\"\u002Fblog\u002Fpare-feu-ufw-vps\">Firewall UFW en VPS\u003C\u002Fa>.\n\n**Referencia CIS**: control CIS 3.5.1 (Garantizar que un paquete de firewall esté instalado).",{"type":53,"title":87,"steps":88},"Bloque 5 — fail2ban",[89],{"title":90,"body":91},"Activar fail2ban con la jaula SSH","```bash\ncp \u002Fetc\u002Ffail2ban\u002Fjail.conf \u002Fetc\u002Ffail2ban\u002Fjail.local\n```\n\nEdita `\u002Fetc\u002Ffail2ban\u002Fjail.local` y ajusta la sección `[sshd]`:\n\n```bash\n[sshd]\nenabled = true\nmaxretry = 5\nfindtime = 600\nbantime = 3600\n```\n\n```bash\nsystemctl enable fail2ban\nsystemctl start fail2ban\nfail2ban-client status sshd\n```\n\nPara una cartera de clientes, considera \u003Ca href=\"\u002Fblog\u002Fsecuriser-vps-crowdsec\">CrowdSec\u003C\u002Fa> como sustituto o complemento: su lista de bloqueo comunitaria mancomuniza la inteligencia de miles de servidores.",{"type":53,"title":93,"steps":94},"Bloque 6 — auditd: el registro de trazabilidad",[95,98],{"title":96,"body":97},"Activar auditd y configurar las reglas mínimas","`auditd` es el componente que las agencias olvidan con mayor frecuencia — y sin embargo es el que proporciona la prueba oponible en caso de incidente.\n\n```bash\nsystemctl enable auditd\nsystemctl start auditd\n```\n\nCrea un archivo de reglas de agencia en `\u002Fetc\u002Faudit\u002Frules.d\u002Fagency.rules`:\n\n```bash\n# Registrar todas las elevaciones de privilegios\n-w \u002Fetc\u002Fsudoers -p wa -k sudoers_changes\n-w \u002Fetc\u002Fsudoers.d\u002F -p wa -k sudoers_changes\n\n# Registrar conexiones SSH\n-w \u002Fvar\u002Flog\u002Fauth.log -p wa -k auth_log\n\n# Registrar modificaciones en archivos de configuración del sistema\n-w \u002Fetc\u002Fssh\u002Fsshd_config -p wa -k sshd_config\n-w \u002Fetc\u002Fpasswd -p wa -k passwd_changes\n-w \u002Fetc\u002Fshadow -p wa -k shadow_changes\n\n# Registrar comandos ejecutados como root\n-a always,exit -F arch=b64 -S execve -F euid=0 -k root_commands\n```\n\n```bash\naugenrules --load\nauditctl -l\n```\n\n**Referencia CIS**: control CIS 4.1.1 (Garantizar que la auditoría esté habilitada) y CIS 4.1.3 (Garantizar que se recopilen eventos que modifiquen información de fecha y hora).",{"title":99,"body":100},"Exportar y conservar los logs de auditd","Los logs de `auditd` deben conservarse fuera del servidor para ser oponibles. Configura una exportación a tu sistema centralizado (rsyslog, Loki o un simple `rsync` diario al almacenamiento de la agencia):\n\n```bash\n# Ejemplo: exportación rsyslog al colector de la agencia\necho ':programname, isequal, \"auditd\" @\u003CIP_COLECTOR_AGENCIA>:514' \\\n  >> \u002Fetc\u002Frsyslog.d\u002F99-auditd-remote.conf\nsystemctl restart rsyslog\n```\n\nConserva al menos 90 días de logs. El RGPD no fija un período mínimo de retención para logs de seguridad, pero marcos como **CIS Controls v8** (control 8.3) recomiendan al menos 90 días en local y 1 año en archivo frío.",{"type":36,"title":102,"body":103},"Bloque 7 — Verificación final y acta de entrega","Una vez ejecutados los seis bloques anteriores, audita el estado del servidor antes de entregar los accesos al cliente:\n\n```bash\n# Verificar servicios activos\nsystemctl is-active ufw fail2ban auditd sshd\n\n# Confirmar que root no puede conectarse por SSH\ngrep PermitRootLogin \u002Fetc\u002Fssh\u002Fsshd_config\n\n# Verificar reglas UFW\nufw status verbose\n\n# Verificar reglas auditd cargadas\nauditctl -l\n\n# Revisar últimas conexiones\nlast -n 10\n```\n\nProduce un **acta de entrega fechada y firmada** (incluso por correo electrónico) que liste las medidas aplicadas, las versiones de los paquetes de seguridad instalados y la ubicación del colector de logs. Este es el documento que firma tu cliente y que constituye la prueba contractual de la configuración inicial.\n\nEl acta de entrega no es una formalidad: un cliente que sufre una intrusión dos años después del lanzamiento pedirá a tu agencia que justifique el estado del servidor en la entrega. Sin este documento, la carga de la prueba se invierte.",{"type":105,"title":106,"headers":107,"rows":111},"comparison","Runbook de agencia vs. configuración improvisada",[108,109,110],"Criterio","Configuración improvisada","Runbook estandarizado",[112,116,120,124,128,132],[113,114,115],"Reproducibilidad","Depende del técnico presente","Idéntica en cada entrega",[117,118,119],"Trazabilidad auditd","Rara vez activada, config variable","Activada y configurada sistemáticamente",[121,122,123],"Prueba en caso de incidente","Sin documentos oponibles","Acta fechada + logs centralizados",[125,126,127],"Delegación a junior","Arriesgada (posibles olvidos)","Posible con el runbook como guía",[129,130,131],"Rotación de clave SSH","Manual y olvidada","Procedimiento escrito, repositorio versionado",[133,134,135],"Cumplimiento NIS2 \u002F RGPD","Sin documentar","Documentado y reproducible",{"type":137,"body":138},"tip","**Consejo de auditoría mensual.** Una vez al mes, vuelve a ejecutar las verificaciones finales del Bloque 7 en cada VPS cliente activo y archiva el resultado. Un diff entre dos auditorías consecutivas revela inmediatamente cualquier modificación no autorizada: un puerto extra abierto, un servicio fail2ban detenido, una regla auditd que falta. Esta auditoría toma menos de cinco minutos por servidor cuando los comandos están en un script.",{"type":36,"title":140,"body":141},"Resolución de errores: los más frecuentes al aplicar el runbook","**Error 1 — `sshd` rechaza arrancar tras modificar `sshd_config`**\nMensaje: `sshd: \u002Fetc\u002Fssh\u002Fsshd_config line 42: unsupported option`\nCausa: una directiva obsoleta o con sintaxis incorrecta. Verifica con `sshd -t` antes de recargar el servicio. En Ubuntu 24.04, `ChallengeResponseAuthentication` se reemplaza por `KbdInteractiveAuthentication`.\n\n```bash\nsshd -t && systemctl reload sshd\n```\n\n**Error 2 — UFW bloquea tu propia conexión SSH**\nMensaje: la sesión SSH se congela tras `ufw enable`.\nCausa: la regla SSH no se añadió antes de la activación. Usa la consola KVM de ServOrbit para acceder al servidor sin SSH, luego ejecuta `ufw allow 22\u002Ftcp` y `ufw reload`.\n\n**Error 3 — `auditd` arranca pero `auditctl -l` devuelve una lista vacía**\nMensaje: `List of rules:` seguido de nada.\nCausa: el archivo de reglas no está cargado. Verifica que tu archivo `.rules` está en `\u002Fetc\u002Faudit\u002Frules.d\u002F` y ejecuta `augenrules --load`.\n\n**Error 4 — fail2ban no bloquea pese a múltiples intentos fallidos**\nMensaje: `fail2ban-client status sshd` muestra `Currently banned: 0` tras 10 intentos.\nCausa: la ruta del diario SSH ha cambiado. En Debian 12 y Ubuntu 24.04 con journald, el backend de fail2ban debe ser `systemd` en `jail.local`: `backend = systemd`.\n\n**Error 5 — `unattended-upgrades` reinicia servicios en producción**\nCausa: la configuración por defecto reinicia automáticamente los servicios tras las actualizaciones. Para un VPS cliente en producción, deshabilita el reinicio automático y programa una ventana de mantenimiento:\n\n```bash\n# En \u002Fetc\u002Fapt\u002Fapt.conf.d\u002F50unattended-upgrades\nUnattended-Upgrade::Automatic-Reboot \"false\";\n```",{"type":36,"title":143,"body":144},"Ir más lejos: bastionado y monitorización continua","Esta checklist cubre el **nivel 1** del endurecimiento del sistema. Para una cartera de clientes que requiere un nivel de seguridad superior:\n\n- **Bastion SSH**: centraliza todos los accesos a través de un único punto de entrada reforzado — ver \u003Ca href=\"\u002Fblog\u002Fheberger-bastion-host-vps\">Bastion Host en VPS\u003C\u002Fa>.\n- **CrowdSec**: detección conductual y lista de bloqueo comunitaria como complemento o sustituto de fail2ban — ver \u003Ca href=\"\u002Fblog\u002Fsecuriser-vps-crowdsec\">Proteger tu VPS con CrowdSec\u003C\u002Fa>.\n- **Copias de seguridad**: la configuración de seguridad no protege contra la pérdida de datos — ver \u003Ca href=\"\u002Fblog\u002Fbackups-borgbackup-vps\">Copias de seguridad con BorgBackup en VPS\u003C\u002Fa>.\n- **Parches de aplicaciones**: el endurecimiento del sistema es inútil si las aplicaciones self-hosted no se mantienen — ver \u003Ca href=\"\u002Fblog\u002Froutine-correctifs-apps-self-hosted\">Rutina de parches para apps self-hosted\u003C\u002Fa>.\n- **Certificados SSL**: HTTPS es un requisito previo antes de cualquier exposición pública — ver \u003Ca href=\"\u002Fblog\u002Fcertificats-ssl-lets-encrypt-vps\">Certificados SSL con Let's Encrypt en VPS\u003C\u002Fa>.","ServOrbit entrega cada VPS listo para este runbook","Acceso root SSH inmediato y consola KVM incluida en la entrega: tu agencia aplica este runbook desde la primera conexión, para cada cliente, sin necesidad de solicitar acceso intermediario al proveedor. Gestiona toda tu cartera de VPS clientes desde un panel de agencia centralizado.","ServOrbit entrega cada VPS","\u002Fsolutions\u002Fagences",[150,166,181],{"id":151,"slug":152,"slugs":153,"title":157,"excerpt":158,"readTime":159,"views":160,"isPinned":19,"publishedAt":161,"updatedAt":21,"category":162,"categories":163,"featuredImage":30,"bgImage":31,"posterImage":165,"relatedSolution":30},116,"certificados-ssl-gratis-con-lets-encrypt-en-un-vps",{"fr":154,"en":155,"ar":156,"es":152},"certificats-ssl-lets-encrypt-vps","free-ssl-certificates-with-lets-encrypt-on-a-vps","شهادات-ssl-مجانية-باستخدام-lets-encrypt-على-خادم-vps","Certificados SSL gratis con Let's Encrypt en un VPS","Despliegue Let's Encrypt en su VPS: HTTPS gratuito, renovación automática y A+ en SSL Labs con Nginx, Caddy o Traefik en Docker.",4,0,"2026-02-24T00:00:00+00:00",{"id":23,"name":24,"slug":25,"color":26,"icon":27},[164],{"id":23,"name":24,"slug":25,"color":26,"icon":27},"\u002Fblog\u002Fcovers\u002Fcertificats-ssl-lets-encrypt-vps-poster.svg",{"id":167,"slug":168,"slugs":169,"title":173,"excerpt":174,"readTime":175,"views":160,"isPinned":19,"publishedAt":176,"updatedAt":21,"category":177,"categories":178,"featuredImage":30,"bgImage":31,"posterImage":180,"relatedSolution":30},278,"backoffice-expuesto-en-vps-superficies-de-ataque-olvidadas",{"fr":170,"en":171,"ar":172,"es":168},"backoffice-vps-surfaces-attaque-oubliees-2026","exposed-backoffice-on-vps-the-overlooked-attack-surfaces","لوحة-إدارة-الخادم-الافتراضي-أسطح-الهجوم-المنسية","Backoffice expuesto: superficies de ataque olvidadas en VPS","Cuatro CVE de agosto de 2026 comparten el mismo patrón: backoffice expuesto en Internet, cuenta comprometida. La autenticación de la aplicación no basta.",12,"2026-08-17T00:00:00+00:00",{"id":23,"name":24,"slug":25,"color":26,"icon":27},[179],{"id":23,"name":24,"slug":25,"color":26,"icon":27},"\u002Fblog\u002Fcovers\u002Fbackoffice-vps-surfaces-attaque-oubliees-2026-poster.svg",{"id":182,"slug":183,"slugs":184,"title":188,"excerpt":189,"readTime":159,"views":160,"isPinned":19,"publishedAt":190,"updatedAt":21,"category":191,"categories":192,"featuredImage":30,"bgImage":31,"posterImage":194,"relatedSolution":30},114,"copias-de-seguridad-vps-con-borgbackup",{"fr":185,"en":186,"ar":187,"es":183},"backups-borgbackup-vps","encrypted-vps-backups-with-borgbackup","نسخ-خادم-vps-الاحتياطية-المشفرة-باستخدام-borgbackup","Copias de seguridad cifradas de VPS con BorgBackup","Respalde su VPS con BorgBackup: deduplicación potente, cifrado autenticado y compresión. Guía completa y comparativa con Restic.","2026-02-26T00:00:00+00:00",{"id":23,"name":24,"slug":25,"color":26,"icon":27},[193],{"id":23,"name":24,"slug":25,"color":26,"icon":27},"\u002Fblog\u002Fcovers\u002Fbackups-borgbackup-vps-poster.svg",1789665021633]