SSL y seguridad

Sí, con el alojamiento web se incluye un certificado SSL Let's Encrypt gratuito, renovado automáticamente. HTTPS se activa desde la puesta en línea.

Sí. Si necesita un certificado de validación extendida o de organización, puede instalarlo en su alojamiento. Nuestro soporte le acompaña.

La redirección automática de HTTP a HTTPS se puede activar en un clic desde cPanel, para servir todo su sitio de forma segura.

Nuestra infraestructura aplica el aislamiento de las cuentas, un firewall y actualizaciones periódicas. En un VPS, la seguridad de su entorno sigue siendo responsabilidad suya (podemos asesorarle).

Sí, cuando su dominio utiliza nuestro DNS gestionado con el registro de su sitio en modo proxy: el tráfico pasa entonces por la red Cloudflare, que absorbe los ataques DDoS a escala mundial — la misma protección que los mayores sitios de la web, incluida y sin costo adicional.

Cloudflare es la red que acelera y protege cerca del 20 % de la web mundial. Conectamos su dominio a ella de forma automática y gratuita: obtiene un CDN mundial (un sitio más rápido en todas partes), una protección anti-DDoS, un DNS anycast resiliente y el HTTPS — sin ninguna manipulación por su parte.

Mantenga WordPress, sus temas y extensiones actualizados, use contraseñas seguras, limite los intentos de conexión, active el SSL y haga copias de seguridad periódicas.

Contacte con nuestro soporte sin esperar: le acompañamos para restaurar una copia de seguridad sana e identificar la brecha, con el fin de evitar que vuelva a producirse.

Los certificados Let's Encrypt son válidos 90 días, lo que impone una renovación automática cada 60 días aproximadamente. En nuestros alojamientos, esa renovación se gestiona automáticamente — usted no tiene que hacer nada. El CA/B Forum (el organismo que rige las autoridades de certificación) ha votado una hoja de ruta para acortar progresivamente esa duración: primero 100 días, después 47 días de cara a 2029. Una renovación más frecuente refuerza la seguridad, porque limita la ventana de exposición en caso de que una clave se vea comprometida. Si utiliza un certificado en un servidor que no gestionamos nosotros, asegúrese de que su herramienta de automatización (Certbot, acme.sh) está actualizada para gestionar estas nuevas duraciones.

Clientes ACME como `certbot`, `acme.sh` o Caddy permiten renovar sus certificados SSL automáticamente, sin intervención manual. Configure un temporizador systemd o una tarea cron para lanzar la renovación con regularidad — la mayoría de los clientes lo hacen de forma nativa durante la instalación. Esta automatización se vuelve urgente: el CA/B Forum prevé reducir las duraciones de validez a 47 días de aquí a 2029, lo que hace estructuralmente inviable cualquier renovación manual.

Traefik integra de forma nativa un cliente ACME compatible con Let's Encrypt. Basta con declarar un resolver en la sección `certificatesResolvers` del archivo `traefik.yml` (o como variable de entorno) y añadir después la etiqueta `traefik.http.routers.<service>.tls.certresolver=<nombre>` a cada contenedor Docker que desee proteger. Traefik se encarga entonces de la negociación del desafío HTTP-01 o DNS-01, de la emisión del certificado y de su renovación automática antes del vencimiento. Los certificados se almacenan en un archivo JSON persistente (`acme.json`) que debe montar en un volumen para no perderlos al reiniciar el contenedor.

Sí. Soluciones de código abierto como Authentik o Authelia, disponibles en el Marketplace de ServOrbit, permiten centralizar la autenticación de todas sus aplicaciones (Gitea, Nextcloud, Chatwoot…) mediante un único portal SSO/OIDC. Usted gestiona los usuarios, los permisos y la doble autenticación desde una interfaz única, sin reconfigurar cada aplicación por separado. Se recomienda un VPS Power (4 vCPU, 8 GB) para Authentik; Authelia es más ligero.

Sí, el alojamiento compartido de ServOrbit utiliza CloudLinux, lo que garantiza un aislamiento fuerte entre las cuentas. Cada cliente se ejecuta en un entorno compartimentado llamado LVE (Linux Virtual Environment): sus archivos, procesos y recursos de CPU/RAM están estrictamente separados de los de los demás clientes alojados en el mismo servidor. Un sitio vecino mal configurado o comprometido no puede, por tanto, ni acceder a sus datos ni afectar a su rendimiento de forma desproporcionada. Esta arquitectura es una protección adicional respecto al alojamiento compartido clásico sin CloudLinux.

Despliegue Promtail en cada VPS que quiera supervisar: recopila los registros del sistema (auth.log, syslog, journald) y los envía a una instancia Loki centralizada en un segundo VPS o en un bucket de almacenamiento de objetos compatible. Grafana se conecta a Loki como fuente de datos y le permite crear alertas sobre los intentos de conexión fallidos (sudo, SSH) o los errores de aplicación. Esta pila es ligera (Loki + Grafana caben en un VPS a 99 DH/mes) y evita exponer sus logs a un servicio de terceros.

Sí. Cloudflare Tunnel (antes Argo Tunnel) establece una conexión saliente desde su VPS hacia la red de Cloudflare, lo que permite exponer una aplicación web con HTTPS sin abrir ningún puerto entrante: ideal si su VPS está detrás de un firewall estricto. El demonio `cloudflared` se instala en su servidor y gestiona la conexión; su dominio debe estar gestionado en Cloudflare. Nuestro artículo de blog dedicado detalla la configuración paso a paso.

Sí, puede generar e instalar un certificado wildcard Let's Encrypt (gratuito) mediante Certbot con el desafío DNS-01, que cubre su dominio principal y todos sus subdominios (*.ejemplo.com). En un servidor dedicado o un VPS con acceso root, el procedimiento es enteramente libre: ninguna restricción por nuestra parte. También puede instalar un certificado wildcard comercial (OV o EV) obtenido de una autoridad de certificación de su elección.

Se descubrieron dos vulnerabilidades críticas de elusión de la autenticación de dos factores en Nextcloud en mayo de 2026: CVE-2026-45690 (elusión mediante HTTP Basic Auth, CVSS 5.9) y CVE-2026-45691 (elusión mediante un token Bearer DAV, CVSS 5.9). Estas vulnerabilidades permiten a un atacante que disponga de un identificador y una contraseña conectarse sin pasar por el 2FA. **Paso 1 — Comprobar su versión**: conéctese a su Nextcloud como administrador, vaya a **Administración → Vista general** y consulte la versión mostrada. **Versiones corregidas**: Nextcloud 32.0.9 y 33.0.3. ⚠️ Nextcloud 34.0.2 contiene una regresión — no la utilice. **Paso 2 — Actualizar si es necesario**: desde la interfaz de administración, vaya a **Administración → Vista general → Buscar actualizaciones** y aplique la última actualización disponible. Para una instancia Docker, cambie la etiqueta de imagen a `nextcloud:32.0.9-apache` y reinicie el contenedor. **Paso 3 — Comprobar la aplicación 2FA**: asegúrese de que la aplicación Two-Factor TOTP o de doble factor por SMS está activada en **Administración → Seguridad** y de que es obligatoria para las cuentas de administrador.

Authelia es un proxy de autenticación ligero (< 30 MB de RAM) que añade una capa 2FA y SSO OIDC delante de sus aplicaciones a través de un reverse proxy (Traefik o nginx). No gestiona un directorio de usuarios completo y no habla SAML 2.0. Authentik es un IAM (Identity and Access Management) completo: cubre OIDC, SAML 2.0, LDAP, SCIM y el aprovisionamiento automático de cuentas. Requiere un VPS con 4 GB de RAM como mínimo (4 contenedores: server, worker, PostgreSQL, Redis). En la práctica: Authelia para 2 a 6 aplicaciones internas que proteger con 2FA, Authentik si necesita SAML 2.0, federar más de cinco aplicaciones o aprovisionar cuentas automáticamente. Ambos están disponibles en el Marketplace ServOrbit.

Las CVE posteriores a la autenticación explotan fallos accesibles una vez iniciada la sesión: mantenga sus aplicaciones actualizadas en cuanto se publique un parche, restrinja el acceso a la interfaz de administración por IP o mediante un proxy inverso con autenticación fuerte, y limite las cuentas de administrador a lo estrictamente necesario. Activar un WAF delante de su backoffice — a través de Cloudflare o de un proxy de aplicación — permite bloquear los patrones de explotación conocidos antes incluso de que alcancen la aplicación.

Desde la versión 2026.4.1 de los clientes Bitwarden, algunas API de cifrado más antiguas ya no son aceptadas por las nuevas instalaciones: un cliente nuevo aplica controles más estrictos que las sesiones ya abiertas. Compruebe que su instancia de Vaultwarden está actualizada (imagen `vaultwarden/server:latest` o una versión reciente fijada) y que su proxy inverso transmite correctamente las cabeceras — en particular `X-Real-IP` y `X-Forwarded-For`. Si el problema persiste, abra un ticket desde su área de cliente adjuntando la versión de Vaultwarden (`docker inspect vaultwarden | grep -i version`) y el mensaje de error exacto mostrado por el cliente.

Coloque un reverse proxy (Traefik o nginx) delante de su instancia Docmost y conecte Authelia o Authentik como middleware de autenticación: toda petición pasa primero por la página de conexión del SSO antes de llegar a la aplicación. Con Traefik, añada el middleware `forwardAuth` apuntando al endpoint de decisión de Authelia en sus labels. Con nginx, use `auth_request` hacia el endpoint de verificación. Este enfoque resulta especialmente adecuado para las herramientas de documentación internas que no exponen una autenticación nativa robusta. Authentik está disponible a través del marketplace ServOrbit y admite OIDC, SAML 2.0 y los forward auth headers compatibles con Traefik.

Antes de la migración, exporte su base de datos SQLite (`kuma.db`) y guárdela en un lugar seguro — es la única fuente de verdad de sus monitores y alertas. La v2 cambia el esquema de la base de datos: arranque el nuevo contenedor con el mismo volumen de datos, Uptime Kuma ejecutará las migraciones automáticamente en el primer inicio. Compruebe después que cada monitor está activo y que los canales de notificación responden antes de eliminar la instancia antigua. La v2 corrige la vulnerabilidad CVE-2026-45618 (inyección a través de las cabeceras HTTP) — se recomienda la actualización.

Una VPN en malla (mesh) basada en WireGuard, como Netbird o Tailscale, crea una red cifrada punto a punto entre sus VPS mediante conexiones únicamente salientes — ningún puerto entrante queda expuesto en la dirección IP pública. Un nodo de coordinación (relay STUN/TURN) resuelve el recorrido a través del NAT; el tráfico entre máquinas viaja directamente en modo par a par una vez establecido el túnel. Este enfoque conviene a los clústeres de bases de datos, a los servicios internos y a los pipelines CI/CD que no deben ser accesibles desde Internet.

CVE-2026-45672 es una vulnerabilidad de ejecución remota de código en Open WebUI que afecta a las versiones anteriores a la 0.6.10: un atacante autenticado puede ejecutar código arbitrario en el servidor a través del pipeline de tratamiento de archivos. Compruebe su versión desde la interfaz de administración (Ajustes → Acerca de) o con `docker inspect ghcr.io/open-webui/open-webui:latest | grep 'version'`. Si está por debajo de la 0.6.10, actualice de inmediato descargando la nueva imagen: `docker compose pull && docker compose up -d`. Mientras tanto, restrinja por IP el acceso a su interfaz mediante su reverse proxy. Escriba a [email protected] para recibir asistencia con la actualización.

El tag :latest sobrescribe la clave de cifrado de los embeddings en cada docker pull: pérdida IRREVERSIBLE de los documentos vectorizados. Fije siempre una versión concreta (p. ej. v1.8.x) en docker-compose. Fuente: issue #5256 github.com/Mintplex-Labs/anything-llm.

Passbolt cifra cada entrada con la clave GPG pública del destinatario. Ni el servidor ni el administrador pueden leer las contraseñas sin la clave privada del titular. El cifrado se realiza en el navegador mediante la extensión de Passbolt.

Antes de actualizar Chatwoot, consulte el changelog oficial y la base NVD/CVE para conocer las vulnerabilidades ligadas a la versión de destino; la rama v4 corrigió en particular fallos en la gestión de los tokens de autenticación. Haga una copia de seguridad íntegra de su base PostgreSQL y de sus volúmenes antes de cualquier actualización, y luego pruebe en un clon antes de pasar a producción. En caso de duda sobre la exposición de su instancia, abra un ticket desde su área de cliente o contacte con [email protected].

**Let's Encrypt (gratuito)**: - Únicamente certificados **DV (Domain Validation)**: demuestra que usted controla el dominio, no la identidad de su organización - Válido 90 días (renovación automática mediante certbot) - Reconocido por todos los navegadores modernos - Adecuado para la gran mayoría de los sitios web - Wildcard disponible (mediante DNS-01): un solo certificado cubre `*.su-dominio.com` **Certificados de pago**: - **OV (Organization Validation)**: la AC verifica la existencia legal de su empresa — visible en los detalles del certificado - **EV (Extended Validation)**: verificación exhaustiva, antiguamente visible mediante la barra verde en los navegadores (esta indicación se retiró de los navegadores modernos en 2019) - Válidos de 1 a 2 años - Pueden incluir una garantía financiera en caso de emisión indebida **Para el 99 % de los usos, Let's Encrypt es suficiente.** Los certificados EV/OV tienen interés por razones de conformidad interna, de contratos con determinados socios, o para sectores regulados (bancos, seguros) que los exigen contractualmente.

Suscríbase a las releases de Gitea en GitHub (github.com/go-gitea/gitea/releases) y active las notificaciones para las nuevas versiones. Cada release precisa si corrige CVE y cuál es el impacto (CVSS). En un VPS de ServOrbit, la actualización se hace mediante `docker compose pull && docker compose up -d` — prevea una copia de seguridad antes de cualquier actualización mayor.

Comience exportando una caja fuerte cifrada desde su gestor actual, verifique su integridad antes de eliminar el original y, a continuación, despliegue Vaultwarden o Passbolt en un VPS dedicado en HTTPS con un certificado válido — los clientes Bitwarden rechazan las conexiones sin cifrar. Active la autenticación de dos factores en todas las cuentas desde el primer acceso, programe el corte fuera del horario laboral y no revoque el acceso a la solución anterior hasta que cada miembro del equipo haya validado la nueva. Nuestro equipo de soporte puede ayudarle con la configuración TLS en [email protected].

Consulte `/var/log/auth.log` (Debian/Ubuntu) para identificar intentos de inicio de sesión fallidos (`Failed password`, `Invalid user`) y conexiones exitosas fuera de sus horarios habituales. El comando `last` lista las sesiones SSH recientes con fecha y dirección IP de origen. Para vigilancia continua, `fail2ban` bloquea automáticamente las IP con demasiados fallos, y puede configurar alertas por correo electrónico. Si confirma un inicio de sesión desconocido, termine la sesión de inmediato con `pkill -u <user>`, rote sus claves SSH y abra un ticket desde su área de cliente.

Para un uso puramente interno — equipo, proyectos internos, sin exposición del servicio a terceros — la BSL y la SSPL generalmente no imponen restricciones: ninguna de las dos apunta al uso privado. La restricción de la SSPL se activa cuando ofreces el software como servicio a usuarios externos (SaaS); la BSL prohíbe ofrecer un servicio comercial que compita con el editor. Si tus clientes acceden a la herramienta, consulta a un abogado antes de desplegarla. Suscríbete a las releases de GitHub de los proyectos que usas para detectar cambios de licencia en cada versión mayor.

El desafío DNS-01 permite obtener un certificado wildcard (`*.tudominio.ma`) sin exponer un puerto HTTP: Certbot crea un registro TXT `_acme-challenge` en tu zona DNS que Let's Encrypt verifica. Si tu dominio está gestionado con Cloudflare, el plugin `certbot-dns-cloudflare` automatiza este paso con un token API de alcance reducido (`Zone:DNS:Edit`). Añade un cron o un timer systemd para ejecutar `certbot renew` y recargar nginx automáticamente tras la renovación. Prueba el proceso de renovación con `--dry-run` antes de confiarlo al planificador.

Por defecto, PostgreSQL escucha en el puerto 5432; si este puerto es accesible desde Internet, cualquiera puede intentar conectarse. Compruebe su exposición con `ss -tlnp | grep 5432` (o `netstat`): si la dirección de escucha es `0.0.0.0` o `::`, el servicio es alcanzable desde el exterior. Para protegerlo: vincule PostgreSQL a `127.0.0.1` en `postgresql.conf` (`listen_addresses = 'localhost'`), bloquee el puerto con su cortafuegos (`ufw deny 5432`) y permita el acceso remoto únicamente a través de un túnel SSH o VPN. Si necesita ayuda para endurecer su configuración, abra un ticket desde su área de cliente.

Comience revisando los registros de Certbot con el comando journalctl -u certbot o leyendo el archivo /var/log/letsencrypt/letsencrypt.log para identificar la causa del fallo. Si utiliza el challenge HTTP-01, verifique que el puerto 80 sea accesible desde el exterior y que la configuración de su servidor web sirva correctamente el directorio .well-known/acme-challenge/. Si el puerto 80 está bloqueado o necesita un certificado wildcard, cambie al challenge DNS-01 utilizando el plugin DNS adecuado para su proveedor. Para forzar una renovación inmediata y probar la configuración, utilice el comando certbot renew --force-renewal.

Un certificado SSL wildcard cubre un dominio y todos sus subdominios de primer nivel, por ejemplo *.ejemplo.com. Let's Encrypt emite certificados wildcard únicamente mediante el challenge DNS-01, que requiere crear un registro TXT en su zona DNS para demostrar la propiedad del dominio. Para automatizar este proceso, utilice Certbot con el plugin DNS correspondiente a su proveedor de DNS. ZeroSSL es una alternativa a Let's Encrypt que también ofrece certificados wildcard gratuitos mediante el challenge DNS-01 y dispone de una interfaz web para facilitar la emisión manual.

Cuando tu dominio está proxificado por Cloudflare, el reto HTTP-01 de Certbot puede fallar porque Cloudflare responde en lugar de tu servidor. Usa en su lugar el reto DNS-01: instala el plugin `certbot-dns-cloudflare`, crea un token de API de Cloudflare con permiso `Zone:DNS:Edit` y luego ejecuta `certbot renew --dns-cloudflare --dns-cloudflare-credentials ~/cloudflare.ini`. La renovación se realiza sin exponer ningún puerto y funciona incluso si tu servidor no es accesible desde internet. Recuerda automatizar la renovación mediante un cron job `certbot renew` para evitar futuras expiraciones.

Puedes verificar la instalación y la fecha de vencimiento de tu certificado SSL directamente desde tu navegador: haz clic en el candado de la barra de direcciones, luego en 'La conexión es segura' para ver los detalles del certificado (emisor, dominio cubierto, validez). Herramientas en línea como SSL Labs (ssllabs.com/ssltest) o check-host.net también permiten realizar un análisis en profundidad (cadena de certificación, algoritmos, compatibilidad). Si el certificado es gestionado automáticamente por ServOrbit (Let's Encrypt), la renovación se gestiona sin ninguna acción por tu parte.

Esta CVE apunta a instancias de Artifactory auto-alojadas que exponen ciertos endpoints REST sin autenticación. Compruebe la versión instalada (Administración → Sistema → Configuración general) y aplique el parche de las notas de versión oficiales de JFrog. Mientras tanto, bloquee el acceso público al puerto de administración (8081/8082) mediante el cortafuegos de su VPS o servidor dedicado ServOrbit, y desactive el acceso anónimo en la configuración de seguridad de Artifactory.

Sí, desde Docker Compose v2.24, Docker Secrets están soportados de forma nativa sin Swarm. Declara un bloque secrets en su docker-compose.yml referenciando un archivo local: Docker monta el secreto como archivo temporal en /run/secrets/<nombre> dentro del contenedor, sin exponerlo en variables de entorno ni en docker inspect. Este es el método recomendado para proteger claves de API, contraseñas de base de datos o tokens en un VPS root. Consulte nuestra guía sobre Docker Secrets en producción para los comandos exactos y las limitaciones de cada enfoque.

Tres enfoques son posibles en un VPS root: Docker Secrets (archivos montados en /run/secrets/, sin Swarm desde Compose v2.24), .env.vault con la herramienta dotenvx que cifra el archivo .env y solo expone la clave de descifrado DOTENV_KEY, y SOPS que cifra los valores de un archivo YAML o .env mediante una clave age o AWS KMS. En todos los casos, el archivo .env en claro nunca debe versionarse en Git. Consulte nuestra guía de Docker Secrets en producción para los comandos y las limitaciones reales de cada método.

CVE-2026-87902 es una vulnerabilidad de ejecución remota de código (RCE) encontrada en WordPress antes de la versión 7.1.2. Si tu sitio usa una versión anterior, podría estar en riesgo. Comprueba la versión actual en tu panel de WordPress en Panel → Actualizaciones. Para estar protegido, actualiza a WordPress 7.1.2 o superior cuanto antes desde tu panel ServOrbit o directamente desde la administración de WordPress.

Tras la publicación de una CVE, los bots automatizados escanean masivamente los servidores expuestos. En su VPS ServOrbit, active el cortafuegos integrado para bloquear los rangos de IP sospechosos, actualice WordPress de inmediato y considere añadir la licencia Imunify360, disponible como opción, que aporta un cortafuegos de aplicaciones. Coloque también su sitio detrás de Cloudflare en modo proxy para beneficiarse de una protección DDoS y de un filtrado de aplicaciones adicional. Nuestro equipo de soporte puede acompañarle en la configuración.

Las versiones 0.29.x de Dokploy se vieron afectadas por varios CVE críticos que permiten escalada de privilegios y ejecución remota de código a través de la API de Docker. Para verificar tu versión, conéctate por SSH y ejecuta `dokploy --version` o consulta la interfaz de administración. Si estás en 0.29.x, actualiza de inmediato con `curl -sSL https://dokploy.com/install.sh | sh` o sigue las notas de lanzamiento oficiales. Mientras esperas la actualización, restringe el acceso al puerto de la interfaz (por defecto 3000) a tus IPs de confianza mediante el cortafuegos de tu VPS.

Sí, `unattended-upgrades` puede desencadenar un reinicio automático tras instalar un parche del kernel si la opción `Unattended-Upgrade::Automatic-Reboot` está habilitada en `/etc/apt/apt.conf.d/50unattended-upgrades`. Por defecto, esta opción está desactivada para evitar interrupciones no planificadas. Es posible definir una hora fija con `Unattended-Upgrade::Automatic-Reboot-Time`, lo que permite programar el reinicio fuera de las horas pico. En entornos de producción críticos, muchos administradores prefieren mantener esta opción desactivada y gestionar los reinicios manualmente, utilizando `needrestart` para determinar si un reinicio es realmente necesario.

Existen varios métodos para confirmar que `unattended-upgrades` funciona correctamente. El archivo de log `/var/log/unattended-upgrades/unattended-upgrades.log` lista los paquetes instalados en las últimas ejecuciones. El comando `unattended-upgrades --dry-run --debug` simula una ejecución sin realizar cambios y muestra lo que se actualizaría. El archivo `/var/log/dpkg.log` registra cada instalación de paquete con su marca de tiempo. En sistemas recientes, `systemctl status unattended-upgrades` muestra el estado del servicio. Por último, `apt-get -s upgrade` combinado con el filtrado de paquetes de seguridad (`unattended-upgrade -d`) permite verificar que no haya ninguna actualización crítica pendiente.

Sí, siempre que el subdominio se cree a través de cPanel y su registro DNS apunte al servidor de alojamiento. Let's Encrypt emite entonces un certificado para ese subdominio en minutos tras su adición, sin ninguna acción por tu parte. Si el subdominio está alojado en otro lugar o no está resuelto en DNS, no se puede emitir ningún certificado automáticamente.

Qdrant expone su interfaz HTTP en el puerto 6333 sin autenticación por defecto. En un VPS de ServOrbit, combine tres medidas. Primero, defina una clave API en la configuración de Qdrant añadiendo `api_key: su-clave-secreta` en `config/production.yaml` o usando la variable de entorno `QDRANT__SERVICE__API_KEY`. Cada solicitud deberá incluir el header `api-key: su-clave-secreta`. Segundo, restrinja el acceso de red al puerto 6333 con UFW: permita solo las IPs de sus aplicaciones (servidor de aplicación, pipeline de ingesta) y bloquee el resto. Tercero, nunca exponga Qdrant directamente en internet sin un reverse proxy TLS: coloque un vhost nginx delante con un certificado Let's Encrypt y reenvíe las conexiones HTTPS al puerto local 6333. El template de ServOrbit para Qdrant integra estas tres medidas por defecto. Para cualquier consulta sobre configuración de red, contacte [email protected].

El cumplimiento en materia de cookies — banner de consentimiento, bloqueo de scripts de terceros antes de la aceptación y registro de consentimientos — es responsabilidad suya como editor del sitio, independientemente del proveedor de alojamiento. ServOrbit proporciona la infraestructura segura (HTTPS, aislamiento de cuenta, copias de seguridad) pero no gestiona los scripts de su frontend. Puede integrar una solución de código abierto como Klaro o Cookie Consent en su alojamiento o VPS. Para cualquier pregunta técnica sobre su configuración, abra un ticket desde su área de cliente.

Una VPN clásica centraliza todo el tráfico a través de un servidor pasarela: cada cliente se conecta al servidor, que redistribuye hacia los demás. Una VPN en malla (Tailscale/Headscale) crea túneles cifrados directos entre cada par (peer-to-peer) gracias al protocolo WireGuard, sin hacer pasar el tráfico por un nodo central. El resultado es menor latencia y mayor resiliencia, a costa de una gestión de claves más distribuida. Headscale es la versión auto-alojable del servidor de coordinación de Tailscale.

El artículo 21 de la directiva NIS2 exige medidas de seguridad proporcionadas que incluyen el cifrado de datos en tránsito, lo que hace obligatorio un certificado TLS válido para cualquier instancia self-hosted expuesta a Internet. En ServOrbit, cada VPS puede obtener un certificado gratuito de Let's Encrypt a través de nuestra interfaz o directamente con Certbot. Un certificado caducado o autofirmado no cumple los requisitos de NIS2 y expone a su organización a una no conformidad.

Sí, Zitadel está diseñado precisamente para este caso de uso: puede crear un único proyecto Zitadel y registrar en él varias aplicaciones (clientes OIDC), cada una correspondiente a una de las aplicaciones auto-alojadas que desea proteger. Cada aplicación obtiene su propio client ID y secret, con límites de roles y scopes distintos, lo que garantiza un aislamiento preciso de los derechos de acceso. Zitadel puede auto-alojarse en el mismo VPS de ServOrbit detrás de Traefik, asignándole un subdominio dedicado con certificados TLS gestionados automáticamente. Prevea al menos 2 GB de RAM para una instancia Zitadel cómoda si se ejecuta junto a otros servicios en el mismo host.

Wazuh es una plataforma SIEM/XDR de código abierto que puede instalar en un VPS de ServOrbit (recomendado: mínimo 4 vCPU y 8 GB de RAM). El manager de Wazuh centraliza las alertas de los agentes desplegados en cada servidor monitorizado; el panel OpenSearch Dashboards integrado ofrece una vista en tiempo real de los eventos de seguridad. ServOrbit ofrece Wazuh en su marketplace para despliegue en un clic; para instalación manual o ayuda con la configuración, contacte a [email protected].

La ANRT no exige un certificado SSL como condición de registro para dominios .ma, pero HTTPS es un requisito de facto impuesto por los navegadores modernos y los motores de búsqueda, que penalizan o bloquean las páginas sin cifrar. Todos los planes de alojamiento de ServOrbit incluyen un certificado Let's Encrypt gratuito y renovado automáticamente. Para un cumplimiento más estricto (RGPD, NIS2 u obligaciones sectoriales), se pueden instalar certificados OV o EV bajo petición — contáctenos a través de nuestro formulario.

Un bucle de fallos (CrashLoopBackOff) provoca que el contenedor se reinicie a intervalos crecientes: una sonda de tipo 'ping container' puede entonces alternar entre 'arriba' y 'abajo' sin disparar una alerta si el umbral de confirmaciones es demasiado bajo. Uptime Kuma v2 mejoró la detección de estados intermedios respecto a la v1 — mantener la instancia actualizada reduce este riesgo. Para servicios críticos, complemente la sonda de disponibilidad con un healthcheck HTTP sobre un endpoint de aplicación real, que verifica el estado interno del contenedor y no solo su arranque.

Sí. Pocket ID es un proveedor OIDC/OAuth 2.0: registre cada aplicación como cliente independiente en su interfaz de administración (client ID + redirect URI), y sus usuarios se autentican una sola vez para acceder a todas las apps compatibles con OIDC. Esta arquitectura SSO centralizada es especialmente eficaz para proteger un conjunto de servicios en el mismo VPS o en varios servidores ServOrbit vinculados por un subdominio de autenticación compartido.

Sí, los certificados SSL OV (Validación de Organización) y EV (Validación Extendida) están disponibles en ServOrbit para empresas marroquíes con un número RC o ICE válido. Estos certificados muestran el nombre de tu empresa en los detalles del certificado, aumentando la confianza de los visitantes, especialmente para sitios de e-commerce o portales financieros. El proceso de validación requiere proporcionar documentos oficiales (registro mercantil, estatutos); cuenta con 3 a 5 días hábiles. Contáctanos en [email protected] para iniciar el proceso.

No necesariamente. Debian, Ubuntu, AlmaLinux y Rocky Linux retroportan las correcciones de seguridad a la versión que empaquetan sin cambiar el número original: solo cambia el sufijo del paquete, y el número que muestra `nginx -v` no basta para concluir. Busca el identificador CVE anunciado en el registro de cambios del paquete instalado (`apt changelog nginx` en Debian o Ubuntu, `rpm -q --changelog nginx` en AlmaLinux o Rocky Linux), o consulta el seguimiento de seguridad de tu distribución; el mismo método sirve para OpenSSH. En un alojamiento web o de revendedor, esta comprobación nos corresponde; en un VPS o un servidor dedicado, te corresponde a ti.

La actualización cierra el fallo, pero no te dice si fue explotado antes. Si tu aplicación estuvo expuesta a Internet durante la ventana de vulnerabilidad, considera que los secretos guardados en el servidor (claves de API, contraseñas de la base de datos, archivo de entorno) pudieron leerse y renuévalos; después revisa tus registros de acceso. Si sospechas de una intrusión, abre un ticket desde tu área de cliente.

No se limite a esperar: un plugin vulnerable y sin corrección sigue siendo una puerta abierta. Haga una copia de seguridad, desactive y elimine el plugin (la simple desactivación suele dejar sus archivos en su sitio) y sustitúyalo por una extensión equivalente y mantenida. Si el sitio estuvo expuesto, busque archivos modificados recientemente y cuentas de administrador desconocidas, y restaure una copia limpia si encuentra alguno. El gestor de WordPress de su cPanel (WP Toolkit) y [email protected] pueden ayudarle a comprobar el estado del sitio.

Elija « Full (strict) » en cuanto su servidor presente un certificado válido: Cloudflare cifra entonces también el tramo hasta el origen y comprueba su certificado. En « Flexible », Cloudflare contacta con el origen por HTTP; si este redirige de HTTP a HTTPS, la petición da vueltas y el navegador muestra « demasiadas redirecciones ». El modo « Full » sin « strict » acepta un certificado autofirmado o caducado: resérvelo para diagnosticar. Fije el modo antes de activar el proxy y pruebe el sitio tras cada cambio.

En un alojamiento web, el servidor y el sistema son responsabilidad del proveedor, pero el contenido de su sitio sigue siendo suyo: el CMS, los temas, las extensiones y la versión de PHP elegida para cada dominio. Son estos elementos, y no el servidor, los que atacan la mayoría de las vulnerabilidades anunciadas en los CMS. El gestor de WordPress de cPanel (WP Toolkit) le muestra las actualizaciones disponibles; aplíquelas después de una copia de seguridad. Si tiene dudas sobre el estado de su sitio, escriba a [email protected].