Etterprøvbare påstander.

Passordet trengs bare for å åpne den første SSH-tilkoblingen og installere en tjenestebruker. Det sendes som SSH-autentisering for vår tilkobling — ikke som et skriptargument eller en miljøvariabel. Databasen vår har ikke noe felt for det; det havner ikke i skriptenes kjøremiljø og skrives ikke til logger (tilkoblingsfeil inneholder bare adresse og port, aldri passordet). I minnet slettes det (best-effort) etter bruk — det er dybdeforsvar, ikke en garanti: Go kan beholde kopier av verdien på heapen inntil søppelrydding (garbage collection).

Ærlig forbehold: dette forblir root-passordet på serveren din. Etter installasjonen deaktiverer vi passord- og root-innlogging over SSH, men vi endrer ikke selve passordet — endre det selv om du ønsker. «Vi lagrer det ikke» er sant; «det sluttet å være en hemmelighet» er det ikke.

PasswordAuthentication no, PermitRootLogin no, SSH flyttet til en ikke-standard port (12011 som standard), fail2ban aktivert (én times utestengelse etter 5 mislykkede forsøk), innlogging kun med nøkkel. Den offentlige nøkkelen valideres strengt før bruk: linjeskift (beskyttelse mot å smugle inn ekstra nøkler i authorized_keys) og syntaktisk ugyldige nøkler avvises.

Anti-utestengelse: port 22 stenges ikke før kjernen bekrefter (via ss) at den nye SSH-porten faktisk lytter; konfigurasjonen sjekkes med sshd -t og sudo-regelen med visudo -cf, begge tilbakestilles ved feil.

Panelet arbeider ikke med passordet ditt, men med en egen nøkkel (ed25519) som det genererer selv. Den private delen ligger i databasen kryptert med AES-256-GCM. Krypteringsnøkkelen (KEK) lagres atskilt fra databasen — i en miljøvariabel på serveren — og i produksjon er den obligatorisk (det finnes ingen usikker standardverdi: uten en KEK starter rett og slett ikke kryptosystemet). Samme kryptering beskytter de tunge hemmelighetene i databasen — Marzban-adminpassord/-token/-JWT, Reality-nøkler, nøkler til betalingsleverandører, hurtigbufferen for proxy-legitimasjon, sikkerhetskopikonfigurasjon.

Krypteringen skjuler ikke bare, men autentiserer dataene (GCM-autentiseringstagg): manipulering av et kryptert felt oppdages ved dekryptering og avvises. Hvert felt krypteres med en ny tilfeldig nonce; KEK-verdien når aldri loggene — bare dens korte id.

Om kapabilitetstokener: abonnementstokenet /sub er en bærerhemmelighet. For oppslag lagrer vi bare dens SHA-256, mens kopien som trengs for å vise en allerede utstedt lenke på nytt, oppbevares som AES-GCM-krypteringstekst. Eldre klartekstoppføringer migreres til det nye formatet, fail-closed, før HTTP-serveren starter. URL-identifikatoren for betalings-webhook lagres i klartekst, men autentiserer ikke i seg selv en hendelse: autentisiteten verifiseres separat med en HMAC-signatur.

Hemmelighetene i Partner-API-nøkler lagres i irreversibel form: hele nøkkelen vises bare én gang, ved utstedelse, og i databasen står bare SHA-256 av den hemmelige delen igjen. Access- og refresh-tokener for tilkoblede AI-apper lagres heller ikke i klartekst; en tilkobling er begrenset til det valgte tilgangsnivået og kan tilbakekalles av kontoeieren.

Nøkkelen dekrypteres bare på serveren, i minnet; vanlige API-er returnerer den aldri. Den eneste måten å få tak i den på er en bevisst eksportfunksjon («ta med deg nøkkelen din»), beskyttet av innlogging pluss en engangskode på e-post (koden lagres kun som en HMAC-hash, sammenlignes i konstant tid, 10 minutters TTL, 5 forsøk). Nøkkelen kan altså hentes ut med vilje, men ikke «lekkes» gjennom en vanlig forespørsel.

Før serverens tilstand endres og før eventuelle nettverksoperasjoner i bakgrunnen, nullstilles feltene som holder administrasjonsnøkkelen synkront. Hvis databasen ikke bekrefter slettingen, returnerer operasjonen en feil og kan prøves på nytt. Slettingen forblir «myk»: raden og ikke-hemmelige tjenestedata bevares. Dette betyr ikke fysisk sletting av sikkerhetskopier som allerede er opprettet — deres livssyklus styres av oppbevaringspolicyen for sikkerhetskopier.

I panelets ruter utledes partner_id fra den signerte økten, i Partner API fra en verifisert API-nøkkel eller en OAuth-tilkobling fra en AI-app. Eierens identifikator hentes ikke fra stien, query-parameterne eller forespørselskroppen. API-nøkler er i tillegg avgrenset av scope, gyldighetstid og abonnement; for en tilkoblet AI beregnes rettighetene ved hver forespørsel ut fra nivået eieren har valgt.

Før noe returneres eller endres, kontrollerer systemet på nytt at den aktuelle serveren, klyngen, inbound-en, ruten, VPN-brukeren eller betalingen tilhører denne kontoen. Databasespørringer avgrenses av partner_id, og sammensatte unike nøkler og fremmednøkler avviser ugyldige koblinger på tvers av partnere. Autorisasjonsmatrisen i testene krever et eksplisitt IDOR-scenario for hvert endepunkt med en ressursidentifikator.

Ærlig forbehold: dette er verifisert gjennom en kodegjennomgang langs hele forespørselsstien, ikke gjennom en offentlig penetrasjonstest — så SR-16 er, som resten, åpen for gjendrivelse i bug bounty-programmet.

For å konfigurere alt automatisk (installere Xray+Reality, ta i bruk konfigurasjon, lese måltall) har panelet full administrativ tilgang på serveren (root-ekvivalent, via en tjenestebruker med passordløs sudo). Dette er nødvendig for administrasjonen, og vi kaller det IKKE «begrenset».

Det som reduserer risikoen: hemmeligheter sendes til serveren kun via prosessens stdin (ikke som kommandoargumenter — de er ikke synlige i prosesslisten); etter den første installasjonen verifiserer hver administrasjonstilkobling serverens festede vertsnøkkel — et serverbytte «i midten» avvises. Det du kontrollerer: tilgangen hviler på en nøkkel du kan tilbakekalle når som helst — ved å slette serveren (nøkkelen nullstilles) eller ganske enkelt slette VPS-en hos verten din (da forsvinner alt).

Selve VPN-kontoene (VLESS/Reality) opprettes og bor i Marzban på masterserveren din. Sentralt lagrer vi bare det som kreves for å utstede en abonnementslenke: et tilfeldig abonnementstoken og et kryptert øyeblikksbilde av proxy-legitimasjon (en hurtigbuffer; kilden til sannhet er din Marzban). Vi har ingen historikk over trafikk, IP eller brukerbesøk.

En sluttbrukers e-postadresse lagres ikke hos oss: kontonavnet utledes ugjenkallelig og inneholder ingen adresse. E-posten med innloggingskoden sender vi, så adressen går gjennom sendekøen vår og fjernes derfra rett etter utsending — for å kjenne igjen en bruker som kommer tilbake, står bare et ugjenkallelig avtrykk igjen, og adressen kan ikke gjenskapes fra det. Det ene tilfellet der en adresse likevel blir liggende, sier vi rett ut: ved betaling kommer den inn i betalings-webhooken og havner i betalingsloggen med begrenset lagringstid.

Disse tjenestedataene oppbevarer vi bare så lenge det er nødvendig, og vi sletter dem automatisk: e-posten fjernes fra sendekøen rett etter sending, innholdet i en betalingshendelse etter behandling, og hendelser som venter på et nytt forsøk innen et vindu på 90 dager. Du kan selv slette kontoen din sammen med alle dataene i den, i seksjonen «Avanserte innstillinger», ved å bekrefte med en kode fra e-posten din (se risiko 7 for detaljer). Vi opplyser dette åpent i stedet for å skjule det bak vage formuleringer.

CreateYourVPN-plattformen mottar eller lagrer ikke informasjon om hvilke nettsteder du eller brukerne dine besøker. Skjemaet for innsamling av måltall er lukket: det har fysisk ingen felter for IP-er, domener eller besøk — bare aggregater (antall unike pålogget, totalt antall byte, CPU/RAM/belastning). Hver node autentiserer med et HMAC-token knyttet til sin egen id og kan bare skrive måltall for seg selv. Balansereren på noden (HAProxy) fungerer som en TCP-ruter etter SNI og dekrypterer ikke trafikk. På selve serveren beholdes systemjournalene i høyst omtrent én time og videresendes ikke til syslog.

Utover plattformnivået fører heller ikke serverne noen besøksjournal: Xray-tilgangslogging tvinges av ved hver konfigurasjonsutrulling (plattformen setter log.access til none), så kantproxyen registrerer ikke hvilke adresser brukerne kobler til. Dette håndheves i koden og er rullet ut til flåten.

For å forstå hvordan nettstedet og panelet brukes, benytter vi Google Analytics (informasjonskapsel-banneret varsler om innsamling av informasjonskapsler og statistikk; detaljer finnes i personvernerklæringen). På OAuth-samtykkesidene er analyse tvangsdeaktivert: URL-en inneholder en kortlivet identifikator for forespørselen om å koble til en AI, og den må ikke gis videre til tredjepart. Det finnes ingen andre tredjepartssporere: ingen Sentry, PostHog, Mixpanel eller annonsepiksler. Backenden har ingen tredjepartstelemetri, og sluttbrukernes butikkfronter dekkes ikke av analyse.

Forbehold: GA mottar IP-en din (på Googles side) og adressene til panelsidene som vises; panel-URL-er inneholder bare en klyngeidentifikator, ikke en e-post.

Betaling og alle kortdata håndteres hos den tilkoblede leverandøren (lava.top). Vi mottar bare en verifisert webhook-hendelse: autentisiteten fastslås på den måten den aktuelle leverandøren støtter, før saldo eller tilgang endres. Vi mottar ikke det fulle kortnummeret (PAN) eller CVV. Ny levering av samme hendelse fører ikke til dobbel tildeling: hendelser dedupliseres.

Forbehold: leverandøren kan inkludere kortmetadata (merke og de siste 4 sifrene) og betalerens navn og e-post i webhook-kroppen. Den opprinnelige kroppen trengs av arbeideren til behandlingen er fullført; etter vellykket behandling slettes den sammen med e-posthintet. Hendelser som venter på nytt forsøk eller manuell gjennomgang, beholder den opprinnelige kroppen bare til slutten av oppbevaringsvinduet (90 dager uten aktivitet), hvoretter kortmetadataene og betalerens e-post slettes automatisk. «Det finnes ikke noe fullt kortnummer» er sant, men det er en egenskap ved leverandørene (vi filtrerer ikke kroppen selv); «vi ser ingenting om kortet i det hele tatt» er det ikke.

For kontoen lagres e-post, tidspunkt for siste innlogging, grensesnittmodus og innstillinger; for fakturering saldo og Telegram, hvis det er oppgitt for påfyll. For å beskytte kontoen inneholder en aktiv økt tidspunktet for opprettelse og for siste aktivitet, IP-adresse og user-agent. Historikken over vellykkede og mislykkede påloggingsforsøk med de samme tekniske kjennetegnene lagres i 90 dager.

Det finnes ingen samlet klikkhistorikk for panelet. I tillegg finnes det formålsbestemte logger: Partner-API-forespørsler (høyst de siste 500 oppføringene og omtrent 25 timer), infrastrukturhendelser og diagnoseresultater (høyst 7 dager) samt handlinger fra tilkoblede AI-apper (så lenge kontoen finnes). Før AI-handlinger logges, fjernes passord, tokener, nøkler og abonnementslenker, og brukernes e-postadresser maskeres.

Brannmuren nekter innkommende trafikk som standard. Åpne utover: 443 (VPN, Xray+Reality), SSH på en ikke-standard port (12011 som standard), og — på masterserveren — porten til Marzban-adminpanelet, kun for control-plane-IP-er. Port 80 åpnes separat kun i Let's Encrypt-modus for HTTP-01. Port 22 stenges etter at SSH er flyttet.

Nodens administrasjonsporter er åpne kun mot masterserverens IP, ikke utover (en svikt i denne bindingen avbryter installasjonen). Hvis brannmuren ikke blir aktiv, mislykkes installasjonen. ICMP-ekko er begrenset kun for IPv4; vi lover ikke at serveren er «usynlig», og IPv6-ICMP bevares for at IPv6 skal fungere korrekt.

Unattended upgrades installerer sikkerhetsoppdateringer for pakker automatisk. Forbehold: automatisk omstart er bevisst deaktivert (slik at en uverifisert kjerne ikke starter på nytt av seg selv) — som betyr at rettelser som krever omstart (kjerne, av og til OpenSSH), først trer i kraft etter en manuell eller planlagt omstart. «Automatisk oppdatering» gjelder for userland, ikke for det som krever omstart.

Vi hevder IKKE at serveren er «usynlig» eller «umulig å skanne». Port 443 er åpen og svarer på en TCP-tilkobling som en hvilken som helst webserver. Egenskapen «ved en feilaktig tilkobling ser den ut som et vanlig, urelatert nettsted» leveres av Reality-protokollen inne i Xray — en separat komponent vi ikke gjør til en absolutt.

Partnerinnlogging skjer med en 6-sifret engangskode sendt på e-post. Det finnes ikke noe kontopassord. Dette gjelder ikke intern legitimasjon for administrerte komponenter, som serverens genererte adminpassord. Kodene genereres av en kryptografisk generator; bare deres HMAC-hash lagres, og sammenligningen skjer i konstant tid. Ved suksess slettes koden umiddelbart, og etter 5 gale forsøk ugyldiggjøres den tidlig. Utstedelsesgrensen telles både per fullstendig adresse og per fysisk postkasse: bytte av IP, punktum i Gmail-adresser og plus-tagger gir ikke en egen grense.

Økttokenet ligger i en HttpOnly- og Secure-informasjonskapsel (JS kan ikke lese det), verifisert på backenden (ikke bare på edge). Inaktivitetstidsavbrudd og automatisk utlogging ved inaktivitet er implementert på klienten, ikke på serveren. Tokenet er signert med HS256; ved verifisering avviser vi strengt enhver annen algoritme (inkludert «none») — det klassiske algoritmebytte-angrepet slipper ikke gjennom. Butikkfront-tokenet og partnerpanel-tokenet er atskilt etter målgruppe: et sluttbrukertoken kan teknisk sett ikke nå partner-API-et (og omvendt). En slettet partner avvises selv med et levende token.

Hver partnerøkt har en stabil identifikator på serversiden, som beholdes når tokenet fornyes. Vanlig utlogging tilbakekaller hele den gjeldende økten, ikke bare ett utstedt token. I seksjonen «Kontoøkter» vises enhet, IP-adresse, påloggingstidspunkt og siste aktivitet; hver økt kan avsluttes enkeltvis. Handlingen «Logg ut overalt» avslutter alle økter og kobler fra tilkoblede AI-apper.

Påloggingshistorikken lagres i 90 dager og viser vellykkede pålogginger, koder som var feil eller utløpt, og tilfeller av for mange forsøk. Ved tegn på gjenbruk av et token som allerede er byttet inn, anser systemet økten som kopiert, avslutter alle økter og AI-tilkoblinger og sender eieren et varsel.

Det finnes ingen økttokener i nettleserens local storage, bare grensesnittinnstillinger. Tokenet plasseres i en HttpOnly-informasjonskapsel av serverlaget i Next.js; nettleseren får ikke backendens interne adresse og når den via Server Actions. CORS tillater ikke andre opphav å lese API-svar med autoriserte data.

Det finnes bevisste unntak som eieren selv styrer: eksport av den private SSH-nøkkelen etter en kode fra e-post (SR-4) og en ny Partner-API-nøkkel, der hele hemmeligheten vises i nettleseren én gang ved opprettelse. Etter det kan den ikke gjenopprettes fra databasen — der står bare en hash igjen. Det offentlige API-domenet er tilgjengelig fra internett slik det er tiltenkt, men uten en gyldig økt, API-nøkkel eller OAuth-token returnerer det ingen beskyttede data.

CreateYourVPNs offentlige verter serveres over HTTPS med HSTS (max-age to år, includeSubDomains). Hver webfrontend vi drifter — plattformens nettsted, partnerpanelet og partnernes butikker, både på våre subdomener og på partnerens eget domene — og API-domenet sender det samme settet med sikkerhetsheadere: en Content-Security-Policy (default-src 'none' på API-et; på frontendene forbyr den innbygging i en iframe og låser base-uri og form-action), X-Content-Type-Options: nosniff, X-Frame-Options og en stram Referrer-Policy (no-referrer på API-et; strict-origin-when-cross-origin på frontendene, som også sender en restriktiv Permissions-Policy).

Dette kjører i produksjon på alle disse vertene og kan kontrolleres uavhengig — med en hvilken som helst HTTP-headerinspektør eller en tjeneste som SSL Labs.

En AI-app kobles til via OAuth og får ikke informasjonskapselen fra panelet ditt. På samtykkesiden velger du ett av tre nivåer: bare visning; visning og konfigurering; sletting og tildeling av tilgang. Rettighetene kontrolleres av serveren ved hvert kall. Kritiske slettinger krever en ekstra engangskode fra e-post, og hele tilkoblingen kan tilbakekalles i seksjonen «Tilkoblede AI-apper».

Hvert verktøykall havner i en logg som eieren kan se, med resultatet og en trygg kopi av argumentene. Passord, tokener, API-nøkler, private nøkler og abonnementslenker fjernes før oppføringen skrives; brukernes e-postadresser maskeres. Samtidig er den valgte AI-appen fortsatt en tredjepartstjeneste: data du bevisst har gitt den i oppdrag å lese eller endre, behandles også etter reglene til leverandøren av appen.