Afirmacions verificables.

La contrasenya només cal per obrir la primera connexió SSH i instal·lar un usuari de servei. Es passa com a autenticació SSH de la nostra connexió —no com a argument d’un script ni com a variable d’entorn. La nostra base de dades no té cap camp per emmagatzemar-la; no entra en els entorns d’execució dels scripts i no s’escriu als registres (els errors de connexió només contenen l’adreça i el port, mai la contrasenya). A la memòria s’esborra (en la mesura del possible) després de fer-la servir; això és defensa en profunditat, no una garantia: Go pot conservar còpies del valor a la memòria dinàmica (heap) fins a la recol·lecció d’escombraries.

Salvetat sincera: aquesta continua sent la contrasenya de root del teu servidor. Després de la instal·lació desactivem l’inici de sessió amb contrasenya i com a root per SSH, però no canviem la contrasenya en si —canvia-la tu mateix si vols. «No l’emmagatzemem» és cert; «ha deixat de ser un secret» no ho és.

PasswordAuthentication no, PermitRootLogin no, SSH mogut a un port no estàndard (12011 per defecte), fail2ban activat (un bloqueig d’una hora després de 5 intents fallits), inici de sessió només amb clau. La clau pública es valida estrictament abans d’utilitzar-la: es rebutgen els salts de línia (protecció contra la introducció de claus addicionals a authorized_keys) i les claus sintàcticament no vàlides.

Antibloqueig: el port 22 no es tanca fins que el nucli confirma (mitjançant ss) que el nou port SSH està realment a l’escolta; la configuració es comprova amb sshd -t i la regla de sudo amb visudo -cf, i totes dues es reverteixen en cas d’error.

El tauler no treballa amb la teva contrasenya, sinó amb una clau independent (ed25519) que ell mateix genera. La part privada resideix a la base de dades xifrada amb AES-256-GCM. La clau de xifratge (KEK) s’emmagatzema separadament de la base de dades —en una variable d’entorn del servidor— i en producció és obligatòria (no hi ha cap valor per defecte insegur: sense una KEK, el subsistema criptogràfic simplement no s’inicia). El mateix xifratge protegeix els secrets pesants de la base de dades: la contrasenya/token/JWT d’administrador de Marzban, les claus de Reality, les claus dels proveïdors de pagament, la memòria cau de credencials del proxy i la configuració de còpies de seguretat.

El xifratge no només amaga les dades, sinó que les autentica (etiqueta d’autenticació GCM): la manipulació d’un camp xifrat es detecta en desxifrar-lo i es rebutja. Cada camp es xifra amb un nonce aleatori nou; el valor de la KEK mai no arriba als registres —només ho fa el seu identificador curt.

Sobre els tokens de capacitat: el token de subscripció /sub és un secret de portador. Per a la cerca només n’emmagatzemem el SHA-256, mentre que la còpia necessària per tornar a mostrar un enllaç ja emès es conserva com a text xifrat AES-GCM. Els registres antics en text pla es migren al nou format, amb fallada segura, abans que s’iniciï el servidor HTTP. L’identificador d’URL del webhook de pagament s’emmagatzema en clar, però per si sol no autentica cap esdeveniment: l’autenticitat es verifica per separat amb una signatura HMAC.

Els secrets de les claus de l’API de socis es conserven de manera irreversible: la clau completa només es mostra una vegada, en emetre-la, i a la base de dades hi queda el SHA-256 de la seva part secreta. Els tokens d’accés i d’actualització de les IA connectades tampoc no s’emmagatzemen en text pla; la connexió queda limitada al nivell d’accés triat i el propietari del compte la pot revocar.

La clau es desxifra només al servidor, a la memòria; les API ordinàries mai no la retornen. L’única manera d’obtenir-la és una funció d’exportació deliberada («emporta’t la clau»), protegida per l’inici de sessió més un codi d’un sol ús enviat per correu electrònic (el codi només s’emmagatzema com a resum HMAC, es compara en temps constant, TTL de 10 minuts, 5 intents). Així, la clau es pot recuperar intencionadament, però no es pot «filtrar» a través d’una petició normal.

Abans que canviï l’estat del servidor i abans de qualsevol operació de xarxa en segon pla, els camps que contenen la clau de gestió es posen a zero de manera síncrona. Si la base de dades no confirma l’esborrament, l’operació retorna un error i es pot tornar a intentar. L’eliminació continua sent «suau»: la fila i les dades de servei no secretes es conserven. Això no significa l’esborrament físic de les còpies de seguretat ja creades —el seu cicle de vida es regeix per la política de retenció de còpies de seguretat.

A les rutes del tauler, el partner_id es deriva de la sessió signada; a l’API de socis, d’una clau d’API verificada o d’una connexió OAuth d’una IA. L’identificador del propietari no es pren del camí (path), dels paràmetres de consulta ni del cos de la petició. A més, les claus d’API queden limitades per scope, termini de validesa i pla; en una IA connectada, el conjunt de permisos es calcula a cada petició a partir del nivell triat pel propietari.

Abans de retornar o canviar res, el sistema torna a comprovar que el servidor, el clúster, l’inbound, la ruta, l’usuari de VPN o el pagament pertany a aquest compte. Les consultes a la base de dades queden limitades pel partner_id, i les claus úniques i foranes compostes rebutgen els enllaços entre socis no vàlids. La matriu d’autorització de les proves exigeix un escenari IDOR explícit per a cada endpoint amb un identificador de recurs.

Salvetat sincera: això es verifica mitjançant una auditoria de codi al llarg de tot el recorregut de la petició, no mitjançant una prova de penetració pública —així que SR-16, com la resta, està oberta a la refutació en el bug bounty.

Per configurar-ho tot automàticament (instal·lar Xray+Reality, aplicar la configuració, llegir les mètriques), el tauler disposa d’accés administratiu complet al servidor (equivalent a root, mitjançant un usuari de servei amb sudo sense contrasenya). Això és necessari per a la gestió, i NO en diem «limitat».

El que redueix el risc: els secrets es passen al servidor només a través de l’stdin del procés (no com a arguments de comanda —no són visibles a la llista de processos); després de la instal·lació inicial, cada connexió de gestió verifica la clau de host fixada del servidor —un canvi de servidor «al mig» es rebutja. El que tu controles: l’accés depèn d’una clau que pots revocar en qualsevol moment —eliminant el servidor (la clau es posa a zero) o simplement eliminant el VPS al teu proveïdor (llavors tot desapareix).

Els comptes de VPN en si (VLESS/Reality) es creen i viuen a Marzban al teu servidor mestre. De manera centralitzada només emmagatzemem el que cal per emetre un enllaç de subscripció: un token de subscripció aleatori i una instantània xifrada de les credencials del proxy (una memòria cau; la font de veritat és el teu Marzban). No tenim cap historial de trànsit, IP ni de visites dels usuaris.

L'adreça de correu d'un usuari final no es desa a casa nostra: el nom del seu compte es deriva de manera irreversible i no conté cap adreça. El correu amb el codi d'inici de sessió l'enviem nosaltres, de manera que l'adreça passa per la nostra cua d'enviament i se n'elimina just després de l'enviament: per reconèixer un usuari que torna només queda una empremta irreversible, de la qual no es pot recuperar l'adreça. L'únic cas en què una adreça sí que hi resta l'anomenem directament: en pagar arriba al webhook de pagament i entra al registre de pagaments amb un termini de conservació limitat.

Conservem aquestes dades de servei només durant el temps necessari i les esborrem automàticament: el correu s'elimina de la cua d'enviament just després de l'enviament, el cos d'un esdeveniment de pagament després de processar-lo, i els esdeveniments a l'espera d'un reintent dins d'una finestra de 90 dies. Pots eliminar el teu compte, juntament amb totes les seves dades, directament a la secció «Configuració avançada», confirmant-ho amb un codi que rebràs per correu (vegeu el risc 7 per a més detalls). Ho divulguem obertament en lloc d'amagar-ho darrere d'expressions vagues.

La plataforma CreateYourVPN no rep ni emmagatzema informació sobre quins llocs visiteu tu o els teus usuaris. L’esquema d’ingesta de mètriques és tancat: físicament no té camps per a IP, dominis ni visites —només agregats (recompte d’usuaris únics en línia, total de bytes, CPU/RAM/càrrega). Cada node s’autentica amb un token HMAC lligat al seu propi identificador i només pot escriure mètriques per a si mateix. El balancejador del node (HAProxy) funciona com un encaminador TCP per SNI i no desxifra el trànsit. Al servidor mateix, els registres del sistema es conserven durant no més d’una hora aproximadament i no es reenvien a syslog.

Més enllà del nivell de plataforma, els servidors tampoc conserven cap registre de visites: el registre d’accessos de Xray es desactiva de manera forçada a cada publicació de configuració (la plataforma estableix log.access a none), de manera que el proxy perimetral no registra a quines adreces es connecten els usuaris. Això s’aplica al codi i s’ha desplegat a tota la flota.

Per entendre com s’utilitzen el lloc i el tauler apliquem Google Analytics (el bàner de galetes adverteix sobre la recollida de galetes i estadístiques; els detalls són a la Política de privacitat). A les pàgines de consentiment OAuth l’analítica no es carrega en cap cas: la URL conté un identificador de curta durada de la sol·licitud de connexió d’una IA, que no es pot transmetre a tercers. No hi ha cap altre rastrejador de tercers: ni Sentry, ni PostHog, ni Mixpanel, ni píxels publicitaris. El backend no té telemetria de tercers, i les botigues dels usuaris finals no estan cobertes per l’analítica.

Salvetat: GA rep la teva IP (al costat de Google) i les adreces de les pàgines del tauler visitades; les URL del tauler només contenen un identificador de clúster, no cap correu electrònic.

El pagament i totes les dades de la targeta es gestionen al costat del proveïdor connectat (lava.top). Nosaltres només rebem un esdeveniment de webhook verificat: la seva autenticitat s’estableix amb el mètode que admet el proveïdor concret, abans de canviar el saldo o l’accés. No rebem el número complet de la targeta (PAN) ni el CVV. El reenviament del mateix esdeveniment no provoca una concessió doble: els esdeveniments es dedupliquen.

Salvetat: el proveïdor pot incloure metadades de la targeta (marca i els últims 4 dígits) i el nom i el correu del pagador al cos del webhook. El worker necessita el cos original fins que finalitza el processament; després d’un processament correcte, s’elimina juntament amb la pista del correu. Els esdeveniments que esperen un reintent o una revisió manual només conserven el cos original fins al final de la finestra de retenció (90 dies sense activitat), després de la qual les metadades de la targeta i el correu del pagador s’esborren automàticament. «No hi ha número complet de targeta» és cert, però això és una propietat dels proveïdors (no filtrem el cos nosaltres mateixos); «no veiem res sobre la targeta» no ho és.

Per al compte s’emmagatzemen el correu electrònic, l’hora de l’últim inici de sessió, el mode d’interfície i la configuració; per a la facturació —el saldo i Telegram, si s’ha indicat per a les recàrregues. Per protegir el compte, una sessió activa conté l’hora de creació i de l’última activitat, l’adreça IP i l’user-agent. L’historial d’intents d’inici de sessió correctes i fallits, amb els mateixos atributs tècnics, es conserva durant 90 dies.

No hi ha cap historial general de clics al tauler. A part, hi ha registres específics: les peticions a l’API de socis (com a màxim les 500 entrades més recents i unes 25 hores), els esdeveniments d’infraestructura i els resultats de diagnòstic (com a màxim 7 dies) i les accions de les IA connectades (mentre existeixi el compte). Abans d’enregistrar les accions de la IA, se n’eliminen les contrasenyes, els tokens, les claus i els enllaços de subscripció, i els correus dels usuaris s’emmascaren.

El tallafoc denega el trànsit entrant per defecte. Obert cap a l’exterior: 443 (VPN, Xray+Reality), SSH en un port no estàndard (12011 per defecte) i —al servidor mestre— el port del tauler d’administració de Marzban, només per a les IP del pla de control. El port 80 s’obre per separat només en el mode Let’s Encrypt per a HTTP-01. El port 22 es tanca després de moure l’SSH.

Els ports de gestió del node estan oberts només a la IP del servidor mestre, no cap a l’exterior (una fallada d’aquesta vinculació avorta la instal·lació). Si el tallafoc no s’activa, la instal·lació falla. L’echo ICMP està limitat només per a IPv4; no prometem que el servidor sigui «invisible», i l’ICMP d’IPv6 es conserva perquè IPv6 funcioni correctament.

Les actualitzacions desateses instal·len automàticament les actualitzacions dels paquets de seguretat. Salvetat: el reinici automàtic està desactivat deliberadament (perquè un nucli no verificat no es reiniciï tot sol) —cosa que significa que les correccions que requereixen un reinici (el nucli, de vegades OpenSSH) només s’apliquen després d’un reinici manual o programat. L’«aplicació automàtica de pedaços» és certa per a l’espai d’usuari, no per al que requereix un reinici.

NO afirmem que el servidor sigui «invisible» o «impossible d’escanejar». El port 443 està obert i respon a una connexió TCP com qualsevol servidor web. La propietat «en una connexió incorrecta sembla un lloc web ordinari i sense relació» la proporciona el protocol Reality dins de Xray —un component independent que no convertim en un absolut.

L’inici de sessió del soci es fa amb un codi d’un sol ús de 6 dígits enviat per correu electrònic. No hi ha cap contrasenya de compte. Això no s’aplica a les credencials internes dels components gestionats, com ara la contrasenya d’administrador generada per al servidor. Els codis els genera un generador criptogràfic; només se n’emmagatzema el resum HMAC, i la comparació es fa en temps constant. En cas d’èxit, el codi s’elimina immediatament, i després de 5 intents erronis s’anul·la abans d’hora. El límit de freqüència d’emissió es compta tant per l’adreça completa com per la bústia física: canviar d’IP, els punts a les adreces de Gmail i les etiquetes plus no donen un límit separat.

El token de sessió resideix en una galeta HttpOnly i Secure (JS no la pot llegir), verificada al backend (no només a la vora). El temps d’espera i el tancament automàtic de sessió per inactivitat s’implementen al client, no al servidor. El token se signa amb HS256; en la verificació rebutgem estrictament qualsevol altre algorisme (inclòs «none») —l’atac clàssic de canvi d’algorisme no passa. El token de la botiga i el token del tauler de socis se separen per audiència: un token d’usuari final tècnicament no pot arribar a l’API de socis (i viceversa). Un soci eliminat es rebutja fins i tot amb un token viu.

Cada sessió de soci té un identificador estable al servidor, que es manté quan es renova el token. El tancament de sessió normal revoca tota la sessió actual, no només una emissió del token. A la secció «Sessions del compte» es veuen el dispositiu, l’adreça IP, l’hora d’inici de sessió i l’última activitat; qualsevol sessió es pot tancar per separat. L’acció «Tanca la sessió a tot arreu» finalitza totes les sessions i desconnecta les IA connectades.

L’historial d’inicis de sessió es conserva durant 90 dies i mostra els inicis de sessió correctes, els codis incorrectes i caducats, així com l’excés d’intents. Si hi ha indicis de reutilització d’una emissió del token ja bescanviada, el sistema considera que la sessió s’ha copiat, tanca totes les sessions i connexions d’IA i envia una notificació al propietari.

No hi ha tokens de sessió a l’emmagatzematge local del navegador, només configuracions d’interfície. El token de la galeta HttpOnly el col·loca la capa de servidor de Next.js; el navegador no rep l’adreça interna del backend i hi accedeix a través de Server Actions. CORS no permet que altres orígens llegeixin les respostes de l’API amb dades autoritzades.

Hi ha excepcions intencionades que controla el mateix propietari: l’exportació de la clau SSH privada després del codi rebut per correu (SR-4) i una clau nova de l’API de socis, el secret complet de la qual es mostra al navegador una sola vegada, en crear-la. Després ja no es pot recuperar de la base de dades —només s’hi conserva el hash. El domini públic de l’API és accessible des d’internet, tal com està previst, però sense una sessió vàlida, una clau d’API o un token OAuth no retorna dades protegides.

Els hosts públics de CreateYourVPN se serveixen per HTTPS amb HSTS (max-age de dos anys, includeSubDomains). Tots els frontends web que allotgem — el lloc de la plataforma, el panell de socis i les botigues dels socis, tant als nostres subdominis com al domini propi del soci — i el domini de l'API envien el mateix conjunt de capçaleres de seguretat: una Content-Security-Policy (default-src 'none' a l'API; als frontends prohibeix la incrustació en un iframe i fixa base-uri i form-action), X-Content-Type-Options: nosniff, X-Frame-Options i una Referrer-Policy blindada (no-referrer a l'API; strict-origin-when-cross-origin als frontends, que també envien una Permissions-Policy restrictiva).

Això està en producció a tots aquests hosts i es pot comprovar de manera independent — amb qualsevol inspector de capçaleres HTTP o un servei com SSL Labs.

L’aplicació d’IA es connecta mitjançant OAuth i no rep les galetes del teu tauler. A la pàgina de consentiment tries un dels tres nivells: només visualització; visualització i configuració; eliminació i concessió d’accés. El servidor verifica els permisos a cada crida. Les eliminacions crítiques requereixen un codi addicional d’un sol ús rebut per correu, i tota la connexió es pot revocar a la secció «IA connectades».

Cada crida a una eina entra en un registre visible per al propietari, amb el resultat i una còpia segura dels arguments. Les contrasenyes, els tokens, les claus d’API, les claus privades i els enllaços de subscripció se suprimeixen abans de l’enregistrament; els correus dels usuaris s’emmascaren. Tanmateix, l’aplicació d’IA triada continua sent un servei de tercers: les dades que li has demanat conscientment que llegeixi o modifiqui també es tracten segons les normes del seu proveïdor.