Verifierbara påståenden.

Lösenordet behövs bara för att öppna den första SSH-anslutningen och installera en tjänsteanvändare. Det skickas som SSH-autentisering för vår anslutning — inte som ett skriptargument eller en miljövariabel. Vår databas har inget fält för det; det hamnar inte i skriptens körmiljöer och skrivs inte till loggar (anslutningsfel innehåller bara adress och port, aldrig lösenordet). I minnet rensas det (best-effort) efter användning — det är försvar på djupet, inte en garanti: Go kan behålla kopior av värdet på heapen fram till skräpinsamlingen (garbage collection).

Ärligt förbehåll: det förblir root-lösenordet på din server. Efter installationen inaktiverar vi lösenords- och root-inloggning över SSH, men vi ändrar inte själva lösenordet — ändra det själv om du vill. ”Vi lagrar det inte” är sant; ”det slutade vara en hemlighet” är det inte.

PasswordAuthentication no, PermitRootLogin no, SSH flyttad till en icke-standardport (12011 som standard), fail2ban aktiverat (en timmes blockering efter 5 misslyckanden), inloggning endast med nyckel. Den publika nyckeln valideras strikt före användning: radbrytningar (skydd mot att smuggla in extra nycklar i authorized_keys) och syntaktiskt ogiltiga nycklar avvisas.

Skydd mot utelåsning: port 22 stängs inte förrän kärnan (via ss) bekräftar att den nya SSH-porten faktiskt lyssnar; konfigurationen kontrolleras med sshd -t och sudo-regeln med visudo -cf, båda återställs vid fel.

Panelen arbetar inte med ditt lösenord utan med en separat nyckel (ed25519) som den genererar själv. Den privata delen ligger i databasen krypterad med AES-256-GCM. Krypteringsnyckeln (KEK) lagras separat från databasen — i en miljövariabel på servern — och i produktion är den obligatorisk (det finns ingen osäker standard: utan en KEK startar krypteringsdelsystemet helt enkelt inte). Samma kryptering skyddar de tunga hemligheterna i databasen — Marzbans admin-lösenord/token/JWT, Reality-nycklar, betalleverantörens nycklar, cachen för proxy-uppgifter, backup-konfigurationen.

Krypteringen döljer inte bara utan autentiserar också datan (GCM-autentiseringstagg): manipulering av ett krypterat fält upptäcks vid dekryptering och avvisas. Varje fält krypteras med en ny slumpmässig nonce; KEK-värdet når aldrig loggarna — bara dess korta id.

Om förmågetokens: prenumerationstoken /sub är en bärarhemlighet. För uppslagning lagrar vi bara dess SHA-256, medan kopian som behövs för att åter visa en redan utfärdad länk hålls som AES-GCM-krypterad text. Äldre poster i klartext migreras till det nya formatet, fail-closed, innan HTTP-servern startar. URL-identifieraren för betalnings-webhooken lagras i klartext men autentiserar inte i sig en händelse: äktheten verifieras separat med en HMAC-signatur.

Nyckeln dekrypteras endast på servern, i minnet; vanliga API:er returnerar den aldrig. Det enda sättet att få tag på den är en avsiktlig exportfunktion (”hämta din nyckel”), skyddad av inloggning plus en engångskod via e-post (koden lagras endast som en HMAC-hash, jämförs i konstant tid, TTL på 10 minuter, 5 försök). Nyckeln kan alltså hämtas avsiktligt, men inte ”läcka” via en vanlig begäran.

Innan serverns tillstånd ändras och före eventuella nätverksoperationer i bakgrunden nollställs fälten som innehåller hanteringsnyckeln synkront. Om databasen inte bekräftar rensningen returnerar operationen ett fel och kan göras om. Borttagningen förblir ”mjuk”: raden och icke-hemliga tjänstedata bevaras. Detta innebär inte fysisk radering av redan skapade säkerhetskopior — deras livscykel styrs av policyn för lagring av säkerhetskopior.

Granskade partnerrutter auktoriserar via partner_id, som servern härleder från den signerade inloggningstoken — inte från vad klienten skickade i sökvägen eller kroppen. Innan något returneras eller ändras kontrollerar systemet på nytt att den begärda servern, klustret, inbound, rutten, VPN-användaren eller betalningen tillhör ditt konto; motsvarande databasfrågor är begränsade av ditt partner_id, och schemat (sammansatta unika nycklar plus sammansatta främmande nycklar) avvisar ogiltiga länkar mellan partner. Isoleringen är skiktad: applikation, omkontroll i use-case, ett partner_id-filter och schemat.

Ärligt förbehåll: detta är verifierat genom en kodgranskning längs begärans väg, inte genom ett offentligt penetrationstest — så SR-16, liksom resten, är öppet för vederläggning i bug bounty.

För att konfigurera allt automatiskt (installera Xray+Reality, tillämpa konfiguration, läsa mätvärden) har panelen full administrativ åtkomst på servern (motsvarande root, via en tjänsteanvändare med lösenordsfri sudo). Detta är nödvändigt för hanteringen, och vi kallar det INTE ”begränsad”.

Det som minskar risken: hemligheter skickas till servern endast via processens stdin (inte som kommandoargument — de syns inte i processlistan); efter den första installationen verifierar varje hanteringsanslutning serverns fästa värdnyckel — ett serverbyte ”i mitten” avvisas. Det du styr över: åtkomsten vilar på en nyckel du kan återkalla när som helst — genom att ta bort servern (nyckeln nollställs) eller helt enkelt radera VPS:en hos din leverantör (då försvinner allt).

Själva VPN-kontona (VLESS/Reality) skapas och bor i Marzban på din masterserver. Centralt lagrar vi bara det som krävs för att utfärda en prenumerationslänk: en slumpmässig prenumerationstoken och en krypterad ögonblicksbild av proxy-uppgifter (en cache; sanningskällan är din Marzban). Vi har ingen historik över trafik, IP eller användarbesök.

Här är en ärlig lista över var en slutanvändares e-post faktiskt passerar genom vår centrala databas: e-postmeddelandet med inloggningskoden skickas av oss, så adressen passerar genom vår sändningskö (för all inloggning i butiken, inklusive den kostnadsfria); vid betalning kommer köparens e-post in i betalnings-webhooken och hamnar i betalningsloggen; vid koppling av Telegram sparas e-posten i profilen. Detta är de enda kontaktpunkterna — funktionella och av nödvändighet; ingen av dem rör trafik eller användarbeteende.

Dessa tjänstedata lagrar vi bara så länge det behövs och rensar dem automatiskt: e-posten tas bort ur sändningskön direkt efter sändning, innehållet i en betalningshändelse efter behandling, och händelser som väntar på ett nytt försök inom ett fönster på 90 dagar. Du kan radera ditt konto tillsammans med tillhörande data genom att kontakta supporten (se risk 7 för detaljer). Vi redovisar detta öppet i stället för att dölja det bakom vaga formuleringar.

Plattformen CreateYourVPN tar inte emot eller lagrar information om vilka webbplatser du eller dina användare besöker. Schemat för mätvärdesinmatning är slutet: det har fysiskt inga fält för IP-adresser, domäner eller besök — bara aggregat (antal unika online, totalt antal byte, CPU/RAM/belastning). Varje nod autentiserar med en HMAC-token bunden till sitt eget id och kan bara skriva mätvärden för sig själv. Balanseraren på noden (HAProxy) fungerar som en TCP-router utifrån SNI och dekrypterar inte trafiken. På själva servern behålls systemjournaler i högst ungefär en timme och vidarebefordras inte till syslog.

Utöver plattformsnivån för servrarna inte heller någon besöksjournal: Xrays åtkomstloggning tvingas av vid varje konfigurationsutrullning (plattformen sätter log.access till none), så kantproxyn registrerar inte vilka adresser användarna ansluter till. Detta är framtvingat i koden och utrullat till hela flottan.

För att förstå hur webbplatsen och panelen används tillämpar vi Google Analytics (cookie-bannern varnar om insamling av cookies och statistik; detaljer finns i integritetspolicyn). Det finns inga andra spårare från tredje part: ingen Sentry, PostHog, Mixpanel eller annonspixlar (verifierat genom sökning i båda frontenderna). Backenden har ingen tredjepartstelemetri alls. Slutanvändarbutiken omfattas inte av analys alls — ingen GA, inga spårare (verifierbart från dess källkod).

Förbehåll: GA tar emot din IP (på Googles sida) och adresserna till de panelsidor som visas; panelens URL:er innehåller bara en klusteridentifierare, inte en e-postadress.

Betalning och alla kortdata hanteras på leverantörens sida (Tribute / Lemon Squeezy). Vi tar bara emot en signerad webhook (HMAC-SHA256, jämförelse i konstant tid, verifierad innan kroppen tolkas och före all skrivning till databasen: utan att känna hemligheten klarar en händelse inte verifieringen). Vi tar inte emot det fullständiga kortnumret (PAN) eller CVV. Ny leverans av samma webhook (leverantörens omförsök) leder inte till en dubbel kreditering — händelser dedupliceras.

Förbehåll: leverantören kan inkludera kortmetadata (märke och de sista 4 siffrorna) samt betalarens namn och e-post i webhookens kropp. Den ursprungliga kroppen behövs av workern tills behandlingen är klar; efter lyckad behandling raderas den tillsammans med e-postledtråden. Händelser som väntar på omförsök eller manuell granskning behåller den ursprungliga kroppen endast till slutet av lagringsfönstret (90 dagar utan aktivitet), varefter kortmetadata och betalarens e-post raderas automatiskt. ”Det finns inget fullständigt kortnummer” är sant, men det är en egenskap hos leverantörerna (vi filtrerar inte kroppen själva); ”vi ser ingenting alls om kortet” är det inte.

E-post (behövs för inloggning), tidpunkt för senaste inloggning, gränssnittsläge; för fakturering — saldo och Telegram (för påfyllningar). Partnerns IP lagras inte i databasen, och vi behåller ingen klick- eller åtgärdshistorik i panelen (utöver en kort åtkomstlogg vid fel).

Brandväggen nekar inkommande som standard. Öppet utåt: 443 (VPN, Xray+Reality), SSH på en icke-standardport (12011 som standard) och — på masterservern — porten till Marzbans adminpanel, endast för control-plane-IP:er. Port 80 öppnas separat endast i Let's Encrypt-läge för HTTP-01. Port 22 stängs efter att SSH har flyttats.

Nodens hanteringsportar är öppna endast för masterserverns IP, inte utåt (om denna bindning misslyckas avbryts installationen). Om brandväggen inte blir aktiv misslyckas installationen. ICMP echo är begränsat endast för IPv4; vi lovar inte att servern är ”osynlig”, och IPv6 ICMP bevaras för att IPv6 ska fungera korrekt.

Obevakade uppgraderingar installerar uppdateringar av säkerhetspaket automatiskt. Förbehåll: automatisk omstart är avsiktligt inaktiverad (så att en overifierad kärna inte startar om av sig själv) — vilket innebär att korrigeringar som kräver omstart (kärnan, ibland OpenSSH) tillämpas först efter en manuell eller schemalagd omstart. ”Automatisk patchning” gäller för userland, inte för det som kräver omstart.

Vi hävdar INTE att servern är ”osynlig” eller ”inte kan skannas”. Port 443 är öppen och svarar på en TCP-anslutning som vilken webbserver som helst. Egenskapen ”vid en felaktig anslutning ser den ut som en vanlig orelaterad webbplats” tillhandahålls av protokollet Reality inuti Xray — en separat komponent som vi inte gör till ett absolut påstående.

Partnern loggar in med en 6-siffrig engångskod som skickas till e-post. Det finns inget kontolösenord. Detta gäller inte interna uppgifter för hanterade komponenter, som det genererade Marzban-adminlösenordet. Koderna genereras av en kryptografisk generator; endast deras HMAC-hash lagras, och jämförelsen sker i konstant tid. Koden är för engångsbruk: vid lyckad inloggning raderas den omedelbart (ingen återuppspelning); efter 5 felaktiga försök släcks den i förtid. Frekvensgränsen för utfärdande räknas per e-post, inte per IP — den kan inte kringgås genom att byta adress.

Sessionstoken ligger i en HttpOnly- och Secure-cookie (JS kan inte läsa den), verifierad på backenden (inte bara vid kanten). Inaktivitetstimeout och automatisk utloggning vid inaktivitet är implementerade på klienten, inte på servern. Token är signerad med HS256; vid verifiering avvisar vi strikt alla andra algoritmer (inklusive ”none”) — den klassiska attacken med algoritmbyte passerar inte. Butikens token och partnerpanelens token är åtskilda genom målgrupp: en slutanvändartoken kan tekniskt sett inte nå partner-API:et (och tvärtom). En borttagen partner avvisas även med en giltig token.

Förbehåll: återkallning är implementerad genom att kontrollera att partnern finns vid varje begäran, inte genom att ogiltigförklara själva token; utloggning raderar cookien, men en utfärdad token förblir kryptografiskt giltig till utgången (upp till en timme). Det finns ännu ingen centraliserad återkallningslista (en medveten MVP-förenkling).

Det finns inga tokens i webbläsarens lokala lagring (bara UI-inställningar); inga hemligheter eller API-adressen hamnar i klientbunten. Endast servern (Next.js) placerar token i en HttpOnly-cookie. Webbläsaren talar med kärnan endast via servern (Server Actions): frontenden anropar inte API:et direkt från webbläsaren, och CORS tillåter inte att webbläsaren läser API-svar från andra ursprung.

Förtydligande i stället för ett tidigare absolut påstående: själva API-domänen är en publik värd — tekniskt kan du öppna den från en webbläsare, men utan en session returnerar den inga auktoriserade data.

CreateYourVPN:s publika domäner levereras över HTTPS med HSTS (max-age två år, includeSubDomains). Både webbfrontenden och API-domänen skickar en strikt uppsättning säkerhetsheaders: en restriktiv Content-Security-Policy, X-Content-Type-Options: nosniff, X-Frame-Options och en låst Referrer-Policy (no-referrer på API:et; strict-origin-when-cross-origin på frontenden, som även skickar en restriktiv Permissions-Policy).

Detta körs i produktion på båda domänerna och kan kontrolleras oberoende — med valfri HTTP-headerinspektör eller en tjänst som SSL Labs.