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.

Hemmelighederne i Partner-API-nøgler gemmes i irreversibel form: den fulde nøgle vises kun én gang, ved udstedelsen, og i databasen er der kun SHA-256 af dens hemmelige del tilbage. Access- og refresh-tokens for tilsluttede AI-apps gemmes heller ikke i klartekst; en forbindelse er begrænset til det valgte adgangsniveau og kan tilbagekaldes af kontoens ejer.

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.

I panelets ruter udledes partner_id af den signerede session, i Partner API af en verificeret API-nøgle eller en OAuth-forbindelse fra en AI-app. Ejerens identifikator hentes ikke fra stien, query-parametrene eller anmodningens krop. API-nøgler er desuden begrænset af scope, gyldighedsperiode og abonnement; for en tilsluttet AI beregnes rettighederne ved hver anmodning ud fra det niveau, som ejeren har valgt.

Før noget returneres eller ændres, kontrollerer systemet på ny, at den pågældende server, klynge, inbound, rute, VPN-bruger eller betaling tilhører denne konto. Databaseforespørgsler er begrænset af partner_id, og sammensatte unikke nøgler og fremmednøgler afviser ugyldige forbindelser mellem partnere. Autorisationsmatricen i testene kræver et eksplicit IDOR-scenarie for hvert endpoint med en ressourceidentifikator.

Æ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.

En slutbrugers e-mailadresse gemmes ikke hos os: kontonavnet udledes uigenkaldeligt og indeholder ingen adresse. E-mailen med login-koden sender vi, så adressen passerer vores afsendelseskø og fjernes derfra straks efter afsendelsen — til at genkende en tilbagevendende bruger er der kun et uigenkaldeligt aftryk tilbage, som adressen ikke kan genskabes ud fra. Det ene tilfælde, hvor en adresse alligevel bliver liggende, nævner vi direkte: ved betaling ankommer den i betalings-webhooket og havner i betalingsloggen med en begrænset opbevaringsperiode.

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 selv slette din konto sammen med alle dens data under »Avancerede indstillinger« ved at bekræfte med en kode fra din e-mail (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). På OAuth-samtykkesiderne er analyse tvangsdeaktiveret: URL'en indeholder en kortlivet identifikator for anmodningen om at tilslutte en AI, og den må ikke videregives til tredjepart. Der er ingen andre tredjepartstrackere: ingen Sentry, PostHog, Mixpanel eller annoncepixels. Backenden har ingen tredjepartstelemetri, og slutbrugernes butikker er ikke omfattet af analyse.

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å den tilsluttede udbyders side (lava.top). Vi modtager kun en verificeret webhook-hændelse: dens ægthed fastslås på den måde, som den pågældende udbyder understøtter, før saldo eller adgang ændres. Vi modtager ikke det fulde kortnummer (PAN) eller CVV. Genlevering af den samme hændelse 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.

For kontoen gemmes e-mail, tidspunkt for seneste login, grænsefladetilstand og indstillinger; til fakturering saldo og Telegram, hvis det er angivet til optankninger. For at beskytte kontoen indeholder en aktiv session tidspunktet for oprettelse og for seneste aktivitet, IP-adresse og user-agent. Historikken over vellykkede og mislykkede loginforsøg med de samme tekniske kendetegn gemmes i 90 dage.

Der findes ingen samlet klikhistorik for panelet. Derudover findes der formålsbestemte logge: Partner-API-anmodninger (højst de seneste 500 poster og omkring 25 timer), infrastrukturhændelser og diagnoseresultater (højst 7 dage) samt handlinger fra tilsluttede AI-apps (så længe kontoen findes). Før AI-handlinger logges, fjernes adgangskoder, tokens, nøgler og abonnementslinks, og brugeres e-mailadresser maskeres.

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 serverens genererede admin-adgangskode. Koderne genereres af en kryptografisk generator; kun deres HMAC-hash gemmes, og sammenligningen sker i konstant tid. Ved succes slettes koden straks, og efter 5 forkerte forsøg slukkes den tidligt. Hastighedsgrænsen for udstedelse tælles både pr. fuld adresse og pr. fysisk postkasse: skift af IP, punktummer i Gmail-adresser og plus-tags giver ikke en separat grænse.

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.

Hver partnersession har en stabil identifikator på serversiden, som bevares, når tokenet fornyes. Almindelig udlogning tilbagekalder hele den aktuelle session, ikke kun ét udstedt token. I afsnittet »Kontosessioner« vises enhed, IP-adresse, logintidspunkt og seneste aktivitet; enhver session kan afsluttes enkeltvis. Handlingen »Log ud overalt« afslutter alle sessioner og afbryder forbindelsen til tilsluttede AI-apps.

Login-historikken gemmes i 90 dage og viser vellykkede logins, forkerte og udløbne koder samt tilfælde af for mange forsøg. Ved tegn på genbrug af et allerede ombyttet token betragter systemet sessionen som kopieret, afslutter alle sessioner og AI-forbindelser og sender ejeren en meddelelse.

Der er ingen sessionstokens i browserens lokale lagring, kun indstillinger for grænsefladen. Tokenet placeres i en HttpOnly-cookie af serverlaget i Next.js; browseren modtager ikke backendens interne adresse og tilgår den via Server Actions. CORS tillader ikke andre oprindelser at læse API-svar med autoriserede data.

Der er bevidste undtagelser, som ejeren selv styrer: eksport af den private SSH-nøgle efter en kode fra en e-mail (SR-4) og en ny Partner-API-nøgle, hvis fulde hemmelighed vises i browseren én gang ved oprettelsen. Derefter kan den ikke gendannes fra databasen — der er kun et hash tilbage. Det offentlige API-domæne er som tilsigtet tilgængeligt fra internettet, men uden en gyldig session, API-nøgle eller OAuth-token returnerer det ingen beskyttede data.

CreateYourVPN's offentlige hosts leveres over HTTPS med HSTS (max-age to år, includeSubDomains). Hver webfrontend, vi hoster — platformens websted, partnerpanelet og partnernes butikker, både på vores subdomæner og på partnerens eget domæne — samt API-domænet sender det samme sæt sikkerhedsheaders: en Content-Security-Policy (default-src 'none' på API'et; på frontends forbyder den indlejring 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å frontends, som også sender en restriktiv Permissions-Policy).

Det kører i produktion på alle disse hosts og kan kontrolleres uafhængigt — med enhver HTTP-headerinspektør eller en tjeneste som SSL Labs.

En AI-app tilsluttes via OAuth og får ikke cookien fra dit panel. På samtykkesiden vælger du et af tre niveauer: kun visning; visning og konfiguration; sletning og tildeling af adgang. Rettighederne kontrolleres af serveren ved hvert kald. Kritiske sletninger kræver en ekstra engangskode fra en e-mail, og hele forbindelsen kan tilbagekaldes i afsnittet »Tilsluttede AI-apps«.

Hvert værktøjskald registreres i en log, som ejeren kan se, med resultatet og en sikker kopi af argumenterne. Adgangskoder, tokens, API-nøgler, private nøgler og abonnementslinks fjernes, før der skrives til loggen; brugeres e-mailadresser maskeres. Samtidig forbliver den valgte AI-app en tredjepartstjeneste: data, som du bevidst har bedt den om at læse eller ændre, behandles også efter reglerne hos appens udbyder.