Afirmaciones verificables.

La contraseña solo se necesita para abrir la primera conexión SSH e instalar un usuario de servicio. Se pasa como autenticación SSH de nuestra conexión, no como argumento de un script ni como variable de entorno. Nuestra base de datos no tiene un campo para ella; no entra en los entornos de ejecución de los scripts ni se escribe en los registros (los errores de conexión contienen solo la dirección y el puerto, nunca la contraseña). En memoria se borra (best-effort) tras su uso —eso es defensa en profundidad, no una garantía: Go puede mantener copias del valor en el heap hasta la recolección de basura.

Salvedad honesta: esta sigue siendo la contraseña de root de tu servidor. Tras la instalación deshabilitamos el inicio de sesión por contraseña y como root a través de SSH, pero no cambiamos la contraseña en sí —cámbiala tú mismo si lo deseas. 'No la almacenamos' es cierto; 'dejó de ser un secreto' no lo es.

PasswordAuthentication no, PermitRootLogin no, SSH trasladado a un puerto no estándar (12011 por defecto), fail2ban habilitado (un bloqueo de una hora tras 5 fallos), inicio de sesión solo por clave. La clave pública se valida estrictamente antes de usarse: se rechazan los saltos de línea (protección contra la inserción de claves adicionales en authorized_keys) y las claves sintácticamente inválidas.

Anti-bloqueo: el puerto 22 no se cierra hasta que el núcleo confirma (mediante ss) que el nuevo puerto SSH está realmente a la escucha; la configuración se comprueba con sshd -t y la regla de sudo con visudo -cf, ambas revertidas en caso de error.

El panel no trabaja con tu contraseña, sino con una clave independiente (ed25519) que él mismo genera. La parte privada reside en la base de datos cifrada con AES-256-GCM. La clave de cifrado (KEK) se almacena separada de la base de datos —en una variable de entorno del servidor— y en producción es obligatoria (no hay un valor por defecto inseguro: sin una KEK, el subsistema de cifrado sencillamente no arranca). El mismo cifrado protege los secretos sensibles de la base de datos: la contraseña, el token y el JWT de administrador de Marzban, las claves de Reality, las claves de los proveedores de pago, la caché de credenciales del proxy y la configuración de las copias de seguridad.

El cifrado no solo oculta, sino que autentica los datos (etiqueta de autenticación GCM): la manipulación de un campo cifrado se detecta al descifrar y se rechaza. Cada campo se cifra con un nonce aleatorio nuevo; el valor de la KEK nunca llega a los registros —solo su identificador corto.

Sobre los tokens de capacidad: el token de suscripción /sub es un secreto de portador. Para la búsqueda almacenamos solo su SHA-256, mientras que la copia necesaria para volver a mostrar un enlace ya emitido se conserva como texto cifrado con AES-GCM. Los registros antiguos en texto plano se migran al nuevo formato, con fallo cerrado (fail-closed), antes de que arranque el servidor HTTP. El identificador de la URL del webhook de pago se almacena en claro, pero no autentica por sí solo un evento: la autenticidad se verifica por separado mediante una firma HMAC.

La clave se descifra solo en el servidor, en memoria; las API ordinarias nunca la devuelven. La única forma de obtenerla es una función de exportación deliberada ('llévate tu clave'), protegida por el inicio de sesión más un código de un solo uso enviado por correo (el código se almacena solo como hash HMAC, se compara en tiempo constante, TTL de 10 minutos, 5 intentos). Así, la clave puede recuperarse de forma intencionada, pero no 'filtrarse' a través de una solicitud normal.

Antes de que cambie el estado del servidor y antes de cualquier operación de red en segundo plano, los campos que contienen la clave de gestión se ponen a cero de forma síncrona. Si la base de datos no confirma el borrado, la operación devuelve un error y puede reintentarse. La eliminación sigue siendo 'blanda' (soft): la fila y los datos de servicio no secretos se conservan. Esto no implica el borrado físico de las copias de seguridad ya creadas —su ciclo de vida se rige por la política de retención de copias de seguridad.

Las rutas de socio auditadas autorizan por partner_id, que el servidor deriva del token de inicio de sesión firmado, no de lo que el cliente envió en la ruta o el cuerpo. Antes de devolver o modificar cualquier cosa, el sistema vuelve a comprobar que el servidor, el clúster, el inbound, la ruta, el usuario de VPN o el pago solicitados pertenecen a tu cuenta; las consultas correspondientes a la base de datos están acotadas por tu partner_id, y el esquema (claves únicas compuestas más claves foráneas compuestas) rechaza los enlaces cruzados entre socios que sean inválidos. El aislamiento es por capas: aplicación, revalidación en el caso de uso, un filtro por partner_id y el esquema.

Salvedad honesta: esto se verifica mediante una auditoría del código a lo largo de la ruta de la solicitud, no mediante una prueba de penetración pública —así que SR-16, como el resto, está abierto a refutación en el bug bounty.

Para configurarlo todo automáticamente (instalar Xray+Reality, aplicar la configuración, leer métricas) el panel dispone de acceso administrativo completo en el servidor (equivalente a root, mediante un usuario de servicio con sudo sin contraseña). Esto es necesario para la gestión, y NO lo llamamos 'limitado'.

Lo que reduce el riesgo: los secretos se pasan al servidor únicamente a través del stdin del proceso (no como argumentos de comando —no son visibles en la lista de procesos); tras la instalación inicial, cada conexión de gestión verifica la clave de host fijada (pinned) del servidor —un cambio de servidor 'en medio' se rechaza. Lo que tú controlas: el acceso se apoya en una clave que puedes revocar en cualquier momento —eliminando el servidor (la clave se pone a cero) o simplemente eliminando el VPS en tu proveedor (entonces todo desaparece).

Las propias cuentas de VPN (VLESS/Reality) se crean y residen en Marzban en tu servidor maestro. De forma centralizada almacenamos solo lo necesario para emitir un enlace de suscripción: un token de suscripción aleatorio y una instantánea cifrada de las credenciales del proxy (una caché; la fuente de verdad es tu Marzban). No tenemos historial de tráfico, de IP ni de sitios visitados por los usuarios.

Esta es una lista honesta de dónde el correo electrónico de un usuario final sí pasa por nuestra base de datos central: el correo con el código de inicio de sesión lo enviamos nosotros, así que la dirección pasa por nuestra cola de envío (para cualquier inicio de sesión en la tienda, incluido el gratuito); al pagar, el correo del comprador llega en el webhook de pago y entra en el registro de pagos; al vincular Telegram, el correo se guarda en el perfil. Estos son los únicos puntos de contacto —de servicio y por necesidad—; ninguno de ellos implica tráfico ni comportamiento del usuario.

Conservamos estos datos de servicio solo el tiempo necesario y los borramos automáticamente: el correo se elimina de la cola de envío justo después del envío, el cuerpo de un evento de pago tras procesarlo, y los eventos a la espera de un reintento dentro de una ventana de 90 días. Puedes eliminar tu cuenta junto con los datos asociados poniéndote en contacto con el soporte (consulta el riesgo 7 para más detalles). Lo divulgamos abiertamente en lugar de ocultarlo tras fórmulas vagas.

La plataforma CreateYourVPN no recibe ni almacena información sobre qué sitios visitas tú o cuáles visitan tus usuarios. El esquema de ingesta de métricas es cerrado: físicamente no tiene campos para IP, dominios ni visitas —solo agregados (recuento de conexiones únicas en línea, bytes totales, CPU/RAM/carga). Cada nodo se autentica con un token HMAC vinculado a su propio identificador y solo puede escribir métricas para sí mismo. El balanceador en el nodo (HAProxy) funciona como enrutador TCP por SNI y no descifra el tráfico. En el propio servidor, los diarios del sistema se conservan durante no más de una hora aproximadamente y no se reenvían a syslog.

Más allá del nivel de plataforma, los servidores tampoco conservan ningún registro de visitas: el registro de accesos de Xray se desactiva de forma forzada en cada publicación de configuración (la plataforma establece log.access en none), de modo que el proxy perimetral no registra a qué direcciones se conectan los usuarios. Esto se aplica en el código y se ha desplegado en toda la flota.

Para entender cómo se usan el sitio y el panel aplicamos Google Analytics (el aviso de cookies advierte sobre la recopilación de cookies y estadísticas; los detalles están en la Política de privacidad). No hay otros rastreadores de terceros: ni Sentry, ni PostHog, ni Mixpanel, ni píxeles publicitarios (verificado buscando en ambos frontends). El backend no tiene ninguna telemetría de terceros. La tienda del usuario final no está cubierta por ninguna analítica —ni GA, ni rastreadores (verificable desde su código fuente).

Salvedad: GA recibe tu IP (en el lado de Google) y las direcciones de las páginas del panel visitadas; las URL del panel contienen solo un identificador de clúster, no un correo electrónico.

El pago y todos los datos de la tarjeta se gestionan en el lado del proveedor (Tribute / Lemon Squeezy). Nosotros solo recibimos un webhook firmado (HMAC-SHA256, comparación en tiempo constante, verificado antes de analizar el cuerpo y antes de cualquier escritura en la base de datos: sin conocer el secreto, un evento no supera la verificación). No recibimos el número completo de la tarjeta (PAN) ni el CVV. El reenvío del mismo webhook (reintentos del proveedor) no provoca una doble concesión —los eventos se deduplican.

Salvedad: el proveedor puede incluir metadatos de la tarjeta (marca y últimos 4 dígitos) y el nombre y el correo del pagador en el cuerpo del webhook. El worker necesita el cuerpo original hasta que finaliza el procesamiento; tras un procesamiento correcto se elimina junto con la pista del correo. Los eventos a la espera de reintento o de revisión manual conservan el cuerpo original solo hasta el final de la ventana de retención (90 días sin actividad), tras la cual los metadatos de la tarjeta y el correo del pagador se borran automáticamente. 'No hay número completo de tarjeta' es cierto, pero eso es una propiedad de los proveedores (no filtramos el cuerpo nosotros mismos); 'no vemos absolutamente nada sobre la tarjeta' no lo es.

El correo electrónico (necesario para iniciar sesión), la hora del último inicio de sesión, el modo de interfaz; para la facturación: el saldo y Telegram (para las recargas). La IP del socio no se almacena en la base de datos, y no conservamos ningún historial de clics ni de acciones en el panel (aparte de un breve registro de acceso en caso de errores).

El cortafuegos deniega el tráfico entrante por defecto. Abierto hacia el exterior: 443 (VPN, Xray+Reality), SSH en un puerto no estándar (12011 por defecto) y —en el servidor maestro— el puerto del panel de administración de Marzban, solo para las IP del plano de control. El puerto 80 se abre por separado únicamente en modo Let's Encrypt para HTTP-01. El puerto 22 se cierra una vez trasladado SSH.

Los puertos de gestión del nodo están abiertos solo a la IP del servidor maestro, no hacia el exterior (un fallo en esta vinculación aborta la instalación). Si el cortafuegos no se activa, la instalación falla. El eco ICMP está limitado solo para IPv4; no prometemos que el servidor sea 'invisible', y el ICMP de IPv6 se conserva para que IPv6 funcione correctamente.

Las actualizaciones desatendidas (unattended upgrades) instalan automáticamente las actualizaciones de los paquetes de seguridad. Salvedad: el reinicio automático está deshabilitado de forma deliberada (para que un núcleo sin verificar no se reinicie por sí solo) —lo que significa que las correcciones que requieren un reinicio (el núcleo, a veces OpenSSH) se aplican solo tras un reinicio manual o programado. El 'parcheado automático' es cierto para el espacio de usuario (userland), no para lo que requiere un reinicio.

NO afirmamos que el servidor sea 'invisible' ni que 'no se pueda escanear'. El puerto 443 está abierto y responde a una conexión TCP como cualquier servidor web. La propiedad de que 'ante una conexión incorrecta parece un sitio web corriente y sin relación' la proporciona el protocolo Reality dentro de Xray —un componente aparte que no convertimos en un absoluto.

El inicio de sesión del socio se realiza mediante un código de un solo uso de 6 dígitos enviado por correo. No hay contraseña de cuenta. Esto no se aplica a las credenciales internas de los componentes gestionados, como la contraseña de administrador de Marzban generada. Los códigos los genera un generador criptográfico; solo se almacena su hash HMAC, y la comparación se hace en tiempo constante. El código es de un solo uso: si es correcto, se elimina de inmediato (sin repetición); tras 5 intentos fallidos se anula anticipadamente. El límite de frecuencia de emisión se cuenta por correo, no por IP —no puede eludirse cambiando de dirección.

El token de sesión reside en una cookie HttpOnly y Secure (JS no puede leerlo), verificada en el backend (no solo en el edge). El tiempo de espera por inactividad y el cierre de sesión automático por inactividad se implementan en el cliente, no en el servidor. El token se firma con HS256; en la verificación rechazamos estrictamente cualquier otro algoritmo (incluido 'none') —el clásico ataque de intercambio de algoritmo no pasa. El token de la tienda y el token del panel de socios se separan por audiencia: un token de usuario final no puede, técnicamente, alcanzar la API de socio (y viceversa). Un socio eliminado se rechaza incluso con un token vigente.

Salvedad: la revocación se implementa comprobando que el socio existe en cada solicitud, no invalidando el token en sí; el cierre de sesión elimina la cookie, pero un token emitido sigue siendo criptográficamente válido hasta su caducidad (hasta una hora). Todavía no existe una lista de revocación centralizada (una simplificación consciente del MVP).

No hay tokens en el almacenamiento local del navegador (solo ajustes de la interfaz); ni los secretos ni la dirección de la API llegan al bundle del cliente. Solo el servidor (Next.js) coloca el token en una cookie HttpOnly. El navegador se comunica con el núcleo únicamente a través del servidor (Server Actions): el frontend no llama a la API directamente desde el navegador, y CORS no permite lecturas de las respuestas de la API por parte del navegador desde otros orígenes.

Aclaración en lugar de un antiguo absoluto: el dominio de la API es en sí un host público —técnicamente puedes abrirlo desde un navegador, pero sin una sesión no devuelve ningún dato autorizado.

Los dominios públicos de CreateYourVPN se sirven mediante HTTPS con HSTS (max-age de dos años, includeSubDomains). Tanto el frontend web como el dominio de la API envían un conjunto estricto de encabezados de seguridad: una Content-Security-Policy restrictiva, X-Content-Type-Options: nosniff, X-Frame-Options y una Referrer-Policy blindada (no-referrer en la API; strict-origin-when-cross-origin en el frontend, que además envía una Permissions-Policy restrictiva).

Esto está en producción en ambos dominios y se puede comprobar de forma independiente — con cualquier inspector de encabezados HTTP o un servicio como SSL Labs.