Verificerbare påstande.

Adgangskoden er kun nødvendig for at åbne den første SSH-forbindelse og installere en servicebruger. Den videregives som SSH-godkendelse for vores forbindelse — ikke som et scriptargument eller en miljøvariabel. Vores database har intet felt til den; den havner ikke i scriptets kørselsmiljøer og skrives ikke til logfiler (forbindelsesfejl indeholder kun adressen og porten, aldrig adgangskoden). I hukommelsen slettes den (best-effort) efter brug — det er forsvar i dybden, ikke en garanti: Go kan beholde kopier af værdien på heapen indtil affaldsindsamlingen (garbage collection).

Ærligt forbehold: det forbliver root-adgangskoden på din server. Efter installationen deaktiverer vi adgangskode- og root-login over SSH, men vi ændrer ikke selve adgangskoden — skift den selv, hvis du vil. „Vi gemmer den ikke“ er sandt; „den holdt op med at være en hemmelighed“ er det ikke.

PasswordAuthentication no, PermitRootLogin no, SSH flyttet til en ikke-standardport (12011 som standard), fail2ban aktiveret (en times spærring efter 5 fejl), login kun med nøgle. Den offentlige nøgle valideres strengt før brug: linjeskift (beskyttelse mod at smugle ekstra nøgler ind i authorized_keys) og syntaktisk ugyldige nøgler afvises.

Beskyttelse mod udelukkelse: port 22 lukkes ikke, før kernen (via ss) bekræfter, at den nye SSH-port faktisk lytter; konfigurationen kontrolleres med sshd -t og sudo-reglen med visudo -cf, begge rulles tilbage ved fejl.

Panelet arbejder ikke med din adgangskode, men med en separat nøgle (ed25519), som det genererer selv. Den private del ligger i databasen krypteret med AES-256-GCM. Krypteringsnøglen (KEK) gemmes adskilt fra databasen — i en miljøvariabel på serveren — og i produktion er den obligatorisk (der er ingen usikker standard: uden en KEK starter kryptoundersystemet simpelthen ikke). Den samme kryptering beskytter de tunge hemmeligheder i databasen — Marzbans admin-adgangskode/token/JWT, Reality-nøgler, betalingsudbyderens nøgler, cachen for proxy-legitimationsoplysninger, backup-konfigurationen.

Krypteringen skjuler ikke bare, men autentificerer også dataene (GCM-autentificeringstag): manipulation af et krypteret felt opdages ved dekryptering og afvises. Hvert felt krypteres med en ny tilfældig nonce; KEK-værdien når aldrig frem til logfilerne — kun dens korte id.

Om kapabilitetstokens: abonnementstokenet /sub er en bearer-hemmelighed. Til opslag gemmer vi kun dens SHA-256, mens den kopi, der skal bruges til at vise et allerede udstedt link igen, opbevares som AES-GCM-krypteret tekst. Ældre poster i klartekst migreres til det nye format, fail-closed, før HTTP-serveren starter. URL-identifikatoren for betalings-webhooken gemmes i klartekst, men autentificerer ikke i sig selv en hændelse: ægtheden verificeres separat med en HMAC-signatur.

Nøglen dekrypteres kun på serveren, i hukommelsen; almindelige API'er returnerer den aldrig. Den eneste måde at få fat i den på er en bevidst eksportfunktion („tag din nøgle“), beskyttet af login plus en engangskode via e-mail (koden gemmes kun som en HMAC-hash, sammenlignes i konstant tid, TTL på 10 minutter, 5 forsøg). Nøglen kan altså hentes bevidst, men ikke „lække“ via en almindelig anmodning.

Før serverens tilstand ændres og før eventuelle netværksoperationer i baggrunden, nulstilles felterne med administrationsnøglen synkront. Hvis databasen ikke bekræfter rydningen, returnerer operationen en fejl og kan forsøges igen. Sletningen forbliver „blød“: rækken og ikke-hemmelige servicedata bevares. Det betyder ikke fysisk sletning af allerede oprettede backups — deres livscyklus styres af opbevaringspolitikken for backups.

Reviderede partnerruter autoriserer via partner_id, som serveren udleder af det signerede login-token — ikke af det, klienten sendte i stien eller kroppen. Før noget returneres eller ændres, kontrollerer systemet på ny, at den anmodede server, klynge, inbound, rute, VPN-bruger eller betaling tilhører din konto; de tilsvarende databaseforespørgsler er begrænset af dit partner_id, og skemaet (sammensatte unikke nøgler plus sammensatte fremmednøgler) afviser ugyldige forbindelser mellem partnere. Isolationen er lagdelt: applikation, genkontrol i use-case, et partner_id-filter og skemaet.

Ærligt forbehold: dette er verificeret ved en kodegennemgang langs anmodningens vej, ikke ved en offentlig penetrationstest — så SR-16 er, ligesom resten, åben for at blive modbevist i bug bounty.

For at konfigurere alt automatisk (installere Xray+Reality, anvende konfiguration, læse målinger) har panelet fuld administrativ adgang på serveren (svarende til root, via en servicebruger med adgangskodefri sudo). Dette er nødvendigt for administrationen, og vi kalder det IKKE „begrænset“.

Hvad der reducerer risikoen: hemmeligheder videregives kun til serveren via processens stdin (ikke som kommandoargumenter — de er ikke synlige i proceslisten); efter den første installation verificerer hver administrationsforbindelse serverens fastgjorte værtsnøgle — et serverskift „i midten“ afvises. Hvad du styrer: adgangen hviler på en nøgle, du kan tilbagekalde når som helst — ved at slette serveren (nøglen nulstilles) eller blot ved at slette VPS'en hos din udbyder (så forsvinder alt).

Selve VPN-kontiene (VLESS/Reality) oprettes og bor i Marzban på din masterserver. Centralt gemmer vi kun det, der kræves for at udstede et abonnementslink: et tilfældigt abonnementstoken og et krypteret øjebliksbillede af proxy-legitimationsoplysninger (en cache; kilden til sandhed er din Marzban). Vi har ingen historik over trafik, IP eller brugerbesøg.

Her er en ærlig liste over, hvor en slutbrugers e-mail faktisk passerer gennem vores centrale database: e-mailen med login-koden sendes af os, så adressen passerer gennem vores afsendelseskø (for enhver login til butikken, inklusive den gratis); ved betaling ankommer køberens e-mail i betalings-webhooken og havner i betalingsloggen; ved tilknytning af Telegram gemmes e-mailen i profilen. Dette er de eneste berøringspunkter — funktionelle og af nødvendighed; ingen af dem involverer trafik eller brugeradfærd.

Vi opbevarer kun disse servicedata, så længe det er nødvendigt, og rydder dem automatisk: e-mailen fjernes fra afsendelseskøen umiddelbart efter afsendelse, en betalingshændelses indhold efter behandling, og hændelser, der afventer et nyt forsøg, inden for et vindue på 90 dage. Du kan slette din konto sammen med de tilhørende data ved at kontakte supporten (se risiko 7 for detaljer). Vi oplyser dette åbent i stedet for at skjule det bag vage formuleringer.

Platformen CreateYourVPN modtager eller gemmer ikke oplysninger om, hvilke websteder du eller dine brugere besøger. Skemaet for indhentning af målinger er lukket: det har fysisk ingen felter til IP-adresser, domæner eller besøg — kun aggregater (antal unikke online, samlede byte, CPU/RAM/belastning). Hver node autentificerer med et HMAC-token bundet til sit eget id og kan kun skrive målinger for sig selv. Balanceren på noden (HAProxy) fungerer som en TCP-router ud fra SNI og dekrypterer ikke trafikken. På selve serveren opbevares systemjournaler i højst omkring en time og videresendes ikke til syslog.

Ud over platformsniveauet fører serverne heller ingen besøgsjournal: Xrays adgangslogning tvangsdeaktiveres ved hver konfigurationsudrulning (platformen sætter log.access til none), så edge-proxyen registrerer ikke, hvilke adresser brugerne forbinder til. Dette håndhæves i koden og er rullet ud til hele flåden.

For at forstå, hvordan webstedet og panelet bruges, anvender vi Google Analytics (cookie-banneret advarer om indsamling af cookies og statistik; detaljer findes i privatlivspolitikken). Der er ingen andre tredjepartstrackere: ingen Sentry, PostHog, Mixpanel eller annoncepixels (verificeret ved søgning i begge frontends). Backenden har slet ingen tredjepartstelemetri. Slutbrugerbutikken er slet ikke omfattet af analyse — ingen GA, ingen trackere (verificerbart ud fra dens kildekode).

Forbehold: GA modtager din IP (på Googles side) og adresserne på de viste panelsider; panelets URL'er indeholder kun en klyngeidentifikator, ikke en e-mail.

Betaling og alle kortdata håndteres på udbyderens side (Tribute / Lemon Squeezy). Vi modtager kun en signeret webhook (HMAC-SHA256, sammenligning i konstant tid, verificeret før kroppen parses og før enhver skrivning til databasen: uden kendskab til hemmeligheden består en hændelse ikke verificeringen). Vi modtager ikke det fulde kortnummer (PAN) eller CVV. Genlevering af den samme webhook (udbyderens gentagelser) medfører ikke en dobbelt kreditering — hændelser dedupliceres.

Forbehold: udbyderen kan inkludere kortmetadata (mærke og de sidste 4 cifre) samt betalerens navn og e-mail i webhookens krop. Den oprindelige krop skal bruges af workeren, indtil behandlingen er færdig; efter vellykket behandling slettes den sammen med e-mail-hintet. Hændelser, der venter på gentagelse eller manuel gennemgang, beholder kun den oprindelige krop indtil slutningen af opbevaringsvinduet (90 dage uden aktivitet), hvorefter kortmetadataene og betalerens e-mail slettes automatisk. „Der er ikke noget fuldt kortnummer“ er sandt, men det er en egenskab ved udbyderne (vi filtrerer ikke kroppen selv); „vi ser overhovedet intet om kortet“ er det ikke.

E-mail (nødvendig til login), tidspunkt for seneste login, grænsefladetilstand; til fakturering — saldo og Telegram (til optankninger). Partnerens IP gemmes ikke i databasen, og vi opbevarer ingen klik- eller handlingshistorik i panelet (ud over en kort adgangslog ved fejl).

Firewallen nægter indgående som standard. Åbent udad: 443 (VPN, Xray+Reality), SSH på en ikke-standardport (12011 som standard) og — på masterserveren — porten til Marzbans adminpanel, kun for control-plane-IP'er. Port 80 åbnes separat kun i Let's Encrypt-tilstand til HTTP-01. Port 22 lukkes, efter at SSH er flyttet.

Nodens administrationsporte er kun åbne for masterserverens IP, ikke udad (hvis denne binding fejler, afbrydes installationen). Hvis firewallen ikke bliver aktiv, mislykkes installationen. ICMP echo er kun begrænset for IPv4; vi lover ikke, at serveren er „usynlig“, og IPv6 ICMP bevares, for at IPv6 kan fungere korrekt.

Uovervågede opgraderinger installerer opdateringer af sikkerhedspakker automatisk. Forbehold: automatisk genstart er bevidst deaktiveret (så en uverificeret kerne ikke genstarter af sig selv) — hvilket betyder, at rettelser, der kræver en genstart (kernen, undertiden OpenSSH), først anvendes efter en manuel eller planlagt genstart. „Automatisk patching“ gælder for userland, ikke for det, der kræver en genstart.

Vi hævder IKKE, at serveren er „usynlig“ eller „ikke kan scannes“. Port 443 er åben og svarer på en TCP-forbindelse som enhver anden webserver. Egenskaben „ved en forkert forbindelse ligner den et almindeligt urelateret websted“ leveres af protokollen Reality inde i Xray — en separat komponent, som vi ikke gør til et absolut udsagn.

Partneren logger ind med en 6-cifret engangskode sendt til e-mail. Der er ingen kontoadgangskode. Dette gælder ikke interne legitimationsoplysninger for administrerede komponenter, såsom den genererede Marzban-admin-adgangskode. Koderne genereres af en kryptografisk generator; kun deres HMAC-hash gemmes, og sammenligningen sker i konstant tid. Koden er til engangsbrug: ved succes slettes den straks (ingen genafspilning); efter 5 forkerte forsøg slukkes den tidligt. Hastighedsgrænsen for udstedelse tælles pr. e-mail, ikke pr. IP — den kan ikke omgås ved at skifte adresse.

Sessionstokenet ligger i en HttpOnly- og Secure-cookie (JS kan ikke læse den), verificeret på backenden (ikke kun ved kanten). Inaktivitetstimeout og automatisk logout ved inaktivitet er implementeret på klienten, ikke på serveren. Tokenet er signeret med HS256; ved verificering afviser vi strengt enhver anden algoritme (herunder „none“) — det klassiske algoritmeskift-angreb går ikke igennem. Butikkens token og partnerpanelets token er adskilt efter målgruppe: et slutbrugertoken kan teknisk set ikke nå partner-API'et (og omvendt). En slettet partner afvises selv med et gyldigt token.

Forbehold: tilbagekaldelse er implementeret ved at kontrollere, at partneren eksisterer ved hver anmodning, ikke ved at ugyldiggøre selve tokenet; logout sletter cookien, men et udstedt token forbliver kryptografisk gyldigt indtil udløb (op til en time). Der er endnu ingen centraliseret tilbagekaldelsesliste (en bevidst MVP-forenkling).

Der er ingen tokens i browserens lokale lagring (kun UI-indstillinger); ingen hemmeligheder eller API-adressen havner i klientbundlen. Kun serveren (Next.js) placerer tokenet i en HttpOnly-cookie. Browseren taler med kernen kun via serveren (Server Actions): frontenden kalder ikke API'et direkte fra browseren, og CORS tillader ikke, at browseren læser API-svar fra andre oprindelser.

Præcisering i stedet for et tidligere absolut udsagn: selve API-domænet er en offentlig vært — teknisk kan du åbne det fra en browser, men uden en session returnerer det ingen autoriserede data.

CreateYourVPN's offentlige domæner leveres over HTTPS med HSTS (max-age to år, includeSubDomains). Både webfrontenden og API-domænet sender et strengt sæt sikkerhedsheadere: en restriktiv Content-Security-Policy, X-Content-Type-Options: nosniff, X-Frame-Options og en låst Referrer-Policy (no-referrer på API'et; strict-origin-when-cross-origin på frontenden, som også sender en restriktiv Permissions-Policy).

Dette kører i produktion på begge domæner og kan kontrolleres uafhængigt — med enhver HTTP-header-inspektør eller en tjeneste som SSL Labs.