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.

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.

Les rutes de soci auditades autoritzen per partner_id, que el servidor deriva del token d’inici de sessió signat —no del que el client ha enviat a la ruta o al cos. 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 sol·licitat pertany al teu compte; les consultes corresponents a la base de dades queden limitades pel teu partner_id, i l’esquema (claus úniques compostes més claus foranes compostes) rebutja els enllaços entre socis no vàlids. L’aïllament es fa per capes: aplicació, revisió al cas d’ús, un filtre per partner_id i l’esquema.

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.

Aquesta és una llista honesta d'on el correu electrònic d'un usuari final sí que passa per la nostra base de dades central: el correu amb el codi d'inici de sessió l'enviem nosaltres, així que l'adreça passa per la cua d'enviament (per a qualsevol inici de sessió a la botiga, inclòs el gratuït); en pagar, el correu del comprador arriba al webhook de pagament i entra al registre de pagaments; en vincular Telegram, el correu es desa al perfil. Aquests són els únics punts de contacte —de servei i per necessitat—; cap d'ells implica trànsit ni comportament de l'usuari.

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 les dades associades contactant amb el suport (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). No hi ha cap altre rastrejador de tercers: ni Sentry, ni PostHog, ni Mixpanel, ni píxels publicitaris (verificat cercant en tots dos frontends). El backend no té cap mena de telemetria de tercers. La botiga de l’usuari final no està coberta per cap analítica —ni GA, ni rastrejadors (verificable des del seu codi font).

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 (Tribute / Lemon Squeezy). Nosaltres només rebem un webhook signat (HMAC-SHA256, comparació en temps constant, verificat abans d’analitzar el cos i abans de qualsevol escriptura a la base de dades: sense conèixer el secret, un esdeveniment no supera la verificació). No rebem el número complet de la targeta (PAN) ni el CVV. El reenviament del mateix webhook (reintents del proveïdor) 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.

El correu electrònic (necessari per iniciar la sessió), l’hora de l’últim inici de sessió, el mode d’interfície; per a la facturació —el saldo i Telegram (per a les recàrregues). La IP del soci no s’emmagatzema a la base de dades, i no conservem cap historial de clics ni d’accions al tauler (a part d’un breu registre d’accés en cas d’errors).

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 de Marzban generada. Els codis els genera un generador criptogràfic; només se n’emmagatzema el resum HMAC, i la comparació es fa en temps constant. El codi és d’un sol ús: en cas d’èxit s’elimina immediatament (sense repetició); després de 5 intents erronis s’anul·la abans d’hora. El límit de freqüència d’emissió es compta per correu electrònic, no per IP —no es pot eludir canviant d’adreça.

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.

Salvetat: la revocació s’implementa comprovant que el soci existeix a cada petició, no invalidant el token en si; el tancament de sessió elimina la galeta, però un token emès continua sent criptogràficament vàlid fins que caduca (fins a una hora). Encara no hi ha cap llista de revocació centralitzada (una simplificació conscient del MVP).

No hi ha tokens a l’emmagatzematge local del navegador (només configuracions d’interfície); ni els secrets ni l’adreça de l’API arriben al paquet del client. Només el servidor (Next.js) col·loca el token en una galeta HttpOnly. El navegador es comunica amb el nucli només a través del servidor (Server Actions): el frontend no crida l’API directament des del navegador, i CORS no permet que el navegador llegeixi les respostes de l’API des d’altres orígens.

Aclariment en lloc d’un antic absolut: el domini de l’API en si és un host públic —tècnicament el pots obrir des d’un navegador, però sense una sessió no retorna cap dada autoritzada.

Els dominis públics de CreateYourVPN es serveixen mitjançant HTTPS amb HSTS (max-age de dos anys, includeSubDomains). Tant el frontend web com el domini de l'API envien un conjunt estricte de capçaleres de seguretat: una Content-Security-Policy restrictiva, X-Content-Type-Options: nosniff, X-Frame-Options i una Referrer-Policy blindada (no-referrer a l'API; strict-origin-when-cross-origin al frontend, que també envia una Permissions-Policy restrictiva).

Això funciona en producció als dos dominis i es pot comprovar de manera independent — amb qualsevol inspector de capçaleres HTTP o un servei com SSL Labs.