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.

Los secretos de las claves de la API de socios se almacenan de forma irreversible: la clave completa se muestra una sola vez, al emitirla, y en la base de datos queda el SHA-256 de su parte secreta. Los tokens access y refresh de las IA conectadas tampoco se almacenan en texto plano; la conexión está limitada al nivel de acceso elegido y el propietario de la cuenta puede revocarla.

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.

En las rutas del panel, partner_id se deriva de la sesión firmada; en la API de socios, de una clave API o de una conexión OAuth de IA verificadas. El identificador del propietario no se toma del path, de los parámetros de consulta ni del cuerpo de la solicitud. Además, las claves API están limitadas por scopes, vigencia y plan; en una IA conectada, el conjunto de permisos se calcula en cada solicitud a partir del nivel elegido por el propietario.

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 pertenecen a esta cuenta. Las consultas a la base de datos están acotadas por partner_id, y las claves únicas y foráneas compuestas rechazan los enlaces cruzados entre socios que sean inválidos. La matriz de autorización de las pruebas exige un escenario IDOR explícito para cada endpoint con identificador de recurso.

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.

La dirección de correo de un usuario final no se almacena con nosotros: el nombre de su cuenta se deriva de forma irreversible y no contiene ninguna dirección. 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 y se elimina de ella justo después del envío: para reconocer a un usuario que vuelve solo queda una huella irreversible, de la que no se puede recuperar la dirección. El único caso en el que una dirección sí queda registrada lo nombramos directamente: al pagar llega en el webhook de pago y entra en el registro de pagos con un plazo de conservación limitado.

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. Tú mismo puedes eliminar tu cuenta junto con todos sus datos en la sección «Configuración avanzada», confirmándolo con un código que te llega por correo (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). En las páginas de consentimiento OAuth, la carga de la analítica está desactivada de forma forzosa: la URL contiene un identificador de corta duración de la solicitud de conexión de la IA, que no debe transmitirse a terceros. No hay otros rastreadores de terceros: ni Sentry, ni PostHog, ni Mixpanel, ni píxeles publicitarios. El backend no tiene telemetría de terceros, y las tiendas de los usuarios finales no están cubiertas por la analítica.

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 conectado (lava.top). Nosotros solo recibimos un evento de webhook verificado: su autenticidad se establece con el método que admite el proveedor concreto, antes de modificar el saldo o el acceso. No recibimos el número completo de la tarjeta (PAN) ni el CVV. El reenvío del mismo evento 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.

Para la cuenta se almacenan el correo electrónico, la hora del último inicio de sesión, el modo de interfaz y los ajustes; para la facturación: el saldo y Telegram, si se ha indicado para las recargas. Para proteger la cuenta, una sesión activa contiene la hora de creación y de la última actividad, la dirección IP y el user-agent. El historial de intentos de acceso correctos y fallidos, con esos mismos datos técnicos, se conserva durante 90 días.

No hay un historial general de clics en el panel. Por separado existen registros específicos: solicitudes a la API de socios, como máximo las últimas 500 entradas y unas 25 horas; eventos de infraestructura y resultados de diagnóstico, como máximo 7 días; acciones de las IA conectadas, que se conservan junto con la cuenta. Antes de registrar las acciones de la IA se eliminan las contraseñas, los tokens, las claves y los enlaces de suscripción, y los correos de los usuarios se enmascaran.

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 del servidor 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. Si el código es correcto, se elimina de inmediato, y tras 5 intentos fallidos se anula anticipadamente. El límite de frecuencia de emisión se cuenta tanto por la dirección completa como por el buzón real: cambiar de IP, los puntos en Gmail y las etiquetas plus no dan un límite aparte.

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.

Cada sesión de socio tiene un identificador estable del lado del servidor, que se conserva al renovar el token. El cierre de sesión normal revoca toda la sesión actual, no solo una emisión del token. En la sección «Sesiones de la cuenta» se ven el dispositivo, la dirección IP, la hora de acceso y la última actividad; cualquier sesión se puede cerrar por separado. La acción «Cerrar sesión en todas partes» cierra todas las sesiones y desconecta las IA conectadas.

El historial de accesos se conserva durante 90 días y muestra los accesos correctos, los códigos incorrectos y caducados, y los casos en que se superó el número de intentos. Ante indicios de que se reutiliza una emisión del token ya canjeada, el sistema considera la sesión copiada, cierra todas las sesiones y conexiones de IA y envía una notificación al propietario.

En el almacenamiento local del navegador no hay tokens de sesión, solo ajustes de la interfaz. El token de la cookie HttpOnly lo coloca la capa de servidor de Next.js; el navegador no recibe la dirección interna del backend y se comunica con él a través de Server Actions. CORS no permite que otros orígenes lean respuestas de la API con datos autorizados.

Hay excepciones intencionadas que controla directamente el propietario: la exportación de la clave SSH privada tras introducir un código recibido por correo (SR-4) y una nueva clave de la API de socios, cuyo secreto completo se muestra una sola vez en el navegador al crearla. Después ese secreto no se puede recuperar de la base de datos: allí solo queda un hash. El dominio público de la API es accesible desde internet por diseño, pero sin una sesión válida, una clave API o un token OAuth no devuelve datos protegidos.

Los hosts públicos de CreateYourVPN se sirven mediante HTTPS con HSTS (max-age de dos años, includeSubDomains). Todos los frontends web que alojamos — el sitio de la plataforma, el panel de partners y las tiendas de los partners, ya sea en nuestros subdominios o en el dominio propio del partner — y el dominio de la API envían el mismo conjunto de encabezados de seguridad: una Content-Security-Policy (default-src 'none' en la API; en los frontends prohíbe la inserción en un iframe y fija base-uri y form-action), X-Content-Type-Options: nosniff, X-Frame-Options y una Referrer-Policy blindada (no-referrer en la API; strict-origin-when-cross-origin en los frontends, que además envían una Permissions-Policy restrictiva).

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

Una aplicación de IA se conecta mediante OAuth y no recibe las cookies de tu panel. En la página de consentimiento eliges uno de tres niveles: solo ver; ver y configurar; eliminar y conceder acceso. El servidor comprueba los permisos en cada llamada. Las eliminaciones críticas requieren además un código de un solo uso recibido por correo, y toda la conexión se puede revocar en la sección «IA conectadas».

Cada llamada a una herramienta se anota en un registro visible para el propietario, con su resultado y una copia segura de los argumentos. Las contraseñas, los tokens, las claves API, las claves privadas y los enlaces de suscripción se eliminan antes de registrarse; los correos de los usuarios se enmascaran. Aun así, la aplicación de IA elegida sigue siendo un servicio de terceros: los datos que le encargaste conscientemente leer o modificar se tratan también según las normas de su proveedor.