Etterprøvbare påstander.
Dette er ikke en «vi er sikre»-markedsføringsside, men et sett med etterprøvbare påstander (SR-N), som du kan utfordre hver enkelt av i vårt bug bounty-program mot en belønning.
Tilgang til serveren din
SR-1Root-passordet brukes én gang og lagres ikke hos oss.bekreftet+
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.
SR-2Etter installasjonen er passord- og root-innlogging via SSH deaktivert.bekreftet+
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.
SR-3Administrasjonsnøkkelen lagres kun i kryptert form.bekreftet+
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.
SR-4Den private nøkkelen når aldri nettleseren.bekreftet+
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.
SR-5Når en server slettes, fjernes nøkkelen synkront fra oppføringen.bekreftet+
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.
SR-16Reviderte partner-API-er avgrenser tilgang til ressurseieren.bekreftet+
Reviderte partnerruter autoriserer etter partner_id, som serveren utleder fra det signerte innloggingstokenet — ikke fra det klienten sendte i stien eller kroppen. Før noe returneres eller endres, kontrollerer systemet på nytt at den forespurte serveren, klyngen, inbound-en, ruten, VPN-brukeren eller betalingen tilhører din konto; de tilsvarende databasespørringene avgrenses av din partner_id, og skjemaet (sammensatte unike nøkler pluss sammensatte fremmednøkler) avviser ugyldige koblinger på tvers av partnere. Isolasjonen er lagdelt: applikasjon, ny kontroll i usecase, et partner_id-filter og skjemaet.
Æ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.
Ærlig om panelets tilgang — det er full admin, ikke «begrenset».ærlig merknad+
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).
Dine data og personvern
SR-6VPN-brukere bor på serveren din; vi beholder et minimum av tjenestemetadata.bekreftet+
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.
Her er en ærlig liste over hvor en sluttbrukers e-post faktisk passerer gjennom vår sentrale database: e-posten med innloggingskoden sendes av oss, så adressen passerer gjennom sendekøen vår (for enhver innlogging til butikken, inkludert den gratis); ved betaling ankommer kjøperens e-post i betalings-webhooken og havner i betalingsloggen; ved tilkobling av Telegram lagres e-posten i profilen. Dette er de eneste berøringspunktene — funksjonelle og av nødvendighet; ingen av dem involverer trafikk eller brukeratferd.
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 slette kontoen din sammen med tilhørende data ved å kontakte kundestøtte (se risiko 7 for detaljer). Vi opplyser dette åpent i stedet for å skjule det bak vage formuleringer.
SR-7Vi samler ikke inn logger over trafikken eller besøkene dine, og serverne fører ingen besøksjournal.bekreftet+
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.
SR-8Web-analysen er Google Analytics; det finnes ingen andre sporere.bekreftet+
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). Det finnes ingen andre tredjepartssporere: ingen Sentry, PostHog, Mixpanel eller annonsepiksler (verifisert ved søk i begge frontendene). Backenden har ingen tredjepartstelemetri i det hele tatt. Sluttbrukerens butikkfront dekkes ikke av analyse overhodet — ingen GA, ingen sporere (kan verifiseres fra kildekoden).
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.
SR-9Betalinger er eksterne — vi mottar ikke det fulle kortnummeret.bekreftet+
Betaling og alle kortdata håndteres hos leverandøren (Tribute / Lemon Squeezy). Vi mottar bare en signert webhook (HMAC-SHA256, sammenligning i konstant tid, verifisert før kroppen tolkes og før enhver skriving til databasen: uten å kjenne hemmeligheten består ikke en hendelse verifiseringen). Vi mottar ikke det fulle kortnummeret (PAN) eller CVV. Ny levering av samme webhook (leverandørens gjentatte forsøk) 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.
Hva vi lagrer om deg (partneren), ærlig.ærlig merknad+
E-post (nødvendig for innlogging), tidspunkt for siste innlogging, grensesnittmodus; for fakturering — saldo og Telegram (for påfyll). Partnerens IP lagres ikke i databasen, og vi beholder ingen klikk- eller handlingshistorikk i panelet (bortsett fra en kort tilgangslogg ved feil).
Herding av serveren
SR-10Brannmuren nekter alt bortsett fra det som trengs.bekreftet+
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.
SR-11Automatiske sikkerhetsoppdateringer.bekreftet+
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.
Ærlig om «usynlighet» — vi hevder det ikke.ærlig merknad+
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.
Plattformen (kontrollpanelet)
SR-12Innlogging på CreateYourVPN-kontoen din uten passord.bekreftet+
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 det genererte Marzban-adminpassordet. Kodene genereres av en kryptografisk generator; bare deres HMAC-hash lagres, og sammenligningen skjer i konstant tid. Koden er til engangsbruk: ved suksess slettes den umiddelbart (ingen replay); etter 5 gale forsøk ugyldiggjøres den tidlig. Utstedelsesgrensen telles per e-post, ikke per IP — den kan ikke omgås ved å bytte adresser.
SR-13Økten er beskyttet.bekreftet+
Ø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.
Forbehold: tilbakekalling er implementert ved å sjekke at partneren finnes ved hver forespørsel, ikke ved å ugyldiggjøre selve tokenet; utlogging sletter informasjonskapselen, men et utstedt token forblir kryptografisk gyldig frem til utløp (opptil én time). Det finnes ennå ingen sentralisert tilbakekallingsliste (en bevisst MVP-forenkling).
SR-14Tokener og hemmeligheter lekker ikke til nettleseren.bekreftet+
Det finnes ingen tokener i nettleserens local storage (bare UI-innstillinger); ingen hemmeligheter eller API-adressen havner i klientbunten. Bare serveren (Next.js) plasserer tokenet i en HttpOnly-informasjonskapsel. Nettleseren snakker med kjernen kun gjennom serveren (Server Actions): frontenden kaller ikke API-et direkte fra nettleseren, og CORS tillater ikke at nettleseren leser API-svar fra andre opphav.
Presisering i stedet for en tidligere absolutt: selve API-domenet er en offentlig vert — teknisk sett kan du åpne det fra en nettleser, men uten en økt returnerer det ingen autoriserte data.
SR-15Plattformens offentlige domener bruker HTTPS med strenge sikkerhetshoder.bekreftet+
CreateYourVPNs offentlige domener leveres over HTTPS med HSTS (max-age to år, includeSubDomains). Både web-frontenden og API-domenet sender et strengt sett med sikkerhetshoder: 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 kjører i produksjon på begge domener og kan kontrolleres uavhengig — med hvilken som helst HTTP-header-inspektør eller en tjeneste som SSL Labs.
Ærlig om risikoene (det vi IKKE lover)
En rapport uten denne delen er markedsføring. Her er de reelle grensene:
Kontrollpanelet lagrer de krypterte tilgangsnøklene til hele serverflåten. Det er naturligvis systemets mest følsomme komponent — og vi beskytter det deretter.
Hva som beskytter det: tunge hemmeligheter ligger i databasen kun som chiffertekst; krypteringsnøkkelen (KEK) lagres atskilt fra databasen; nøklene når aldri frem til nettleseren; og de nullstilles når en server slettes. Abonnementstokener har et ekstra lag — hash-oppslag (hash lookup) pluss AES-GCM — slik at selv en databasedump uten KEK ikke inneholder noen fungerende /sub-lenker.
Det ærlige taket: kryptering beskytter pålitelig mot tyveri av selve databasen — en sikkerhetskopi, en replika eller en dump. Det fjerner ikke risikoen for en full kompromittering av selve panelverten, der både KEK og databasen er tilgjengelige for én enkelt prosess. Derfor er hovedfokuset i vårt forsvar å forhindre nettopp en overtakelse av verten: isolasjon, automatiske sikkerhetsoppdateringer og en minimal eksponert flate.
En dedikert KMS/HSM kommer i en av de kommende sikkerhetsutgivelsene.
Når du legger til en server, kobler vi oss til den nøyaktig én gang — med et midlertidig passord du skriver inn. Det er nettopp ved denne første tilkoblingen at et Man-in-the-Middle-angrep (MITM) teoretisk er mulig. Vi nøytraliserer det gjennom flere uavhengige tiltak, slik at den praktiske risikoen er redusert til null.
Passordet er til engangsbruk: det brukes til nøyaktig én tilkobling, lagres ingen steder hos oss og gjenbrukes aldri. Den private nøkkelen sendes aldri over nettverket — den påfølgende autentiseringen bygger på et nøkkelpar (autentisering med offentlig nøkkel, pubkey) og ikke på passordet.
Umiddelbart etter oppsettet deaktiveres passordautentisering og root-innlogging på serveren, SSH-porten endres, og tilgangen legges om til utelukkende nøkler. Fra det øyeblikket låser selv et avlyttet passord ingenting opp.
Hver videre administrasjonstilkobling verifiserer serverens festede fingeravtrykk (host-key pinning) — en server som er byttet ut «i midten», avvises.
Resultatet er at avlytting bare ville være mulig for en angriper som fysisk befinner seg på nettverksstien mellom oss og serveren i løpet av de få sekundene den første installasjonen tar — og selv i dette ekstreme tilfellet blir de avlyttede dataene umiddelbart verdiløse.
Dette er en egenskap ved enhver leid server, ikke bare vår: øyeblikksbilder (snapshots), rescue-modus og lignende er tilgjengelige for leverandøren, og ingen programvare beskytter mot det. På den annen side er valget av en pålitelig leverandør i dine hender, og serveren er helt din — du kan bytte leverandør eller slette maskinen når som helst.
Ingen kan love absolutt beskyttelse — nye sårbarheter dukker opp i all programvare. Det vi gjør: sikkerhetsoppdateringer installeres automatisk, og rettelser som krever en omstart (kjernen, iblant OpenSSH) trer i kraft etter en omstart — enten den er manuell eller planlagt (se SR-11).
Din e-post for innlogging, og sluttbrukeres e-post i noen få servicetilfeller (se SR-6). Den oppbevares bare så lenge det er nødvendig og slettes automatisk (se risiko 9).
Siden innlogging bygger på en engangskode via e-post, er postkassen din i praksis nøkkelen til kontoen — verdt å beskytte godt. En andre faktor finnes ennå ikke: rimelig for dette stadiet, men verdt å vite.
Vi oppbevarer personopplysninger bare så lenge en operasjon trenger dem, og sletter dem deretter automatisk. E-posten fjernes fra køen så snart meldingen er sendt, og råinnholdet i en vellykket betalingshendelse så snart det er behandlet.
Bare én ting varer lenger: betalingshendelser som venter på et nytt forsøk eller manuell gjennomgang. Deres opprinnelige innhold oppbevares ikke på ubestemt tid, men til slutten av et vindu på 90 dager uten aktivitet, hvoretter personopplysningene slettes automatisk.
En selvbetjent «slett dataene mine»-funksjon i grensesnittet finnes ennå ikke — den er planlagt. I mellomtiden kan du slette kontoen din, sammen med tilhørende data, ved å kontakte kundestøtte.
En /sub-lenke er et permanent bærertoken frem til manuell tilbakekalling eller sletting av brukeren; det finnes ingen automatisk utløp eller rotasjon (en lekket lenke forblir aktiv).
Hvis du aktiverer eksport av sikkerhetskopier til Google Drive eller S3, forlater brukerdataene serveren din, og beskyttelsen av dem avhenger deretter av din egen sky — denne rapporten dekker den ikke separat. Det er ditt bevisste valg: funksjonen er en du selv slår på.
Slik sjekker du dette.
Hver påstand ovenfor er et offentlig veddemål. Vi inviterer deg til å finne hvor vi tok feil eller pyntet på sannheten:
Spor A — klassiske sårbarheter (RCE, omgåelse av autorisasjon, IDOR, lekkasjer og så videre).
Spor B — gjendrivelse av denne rapporten: bevis at en hvilken som helst SR-N er usann, få en belønning, og vi publiserer rettelsen offentlig.
Funnet noe?
Skriv til oss med et reproduserbart proof of concept. Vi svarer innen 72 timer og gjør triage internt.