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.

Hemligheterna i Partner-API-nycklar lagras i irreversibel form: hela nyckeln visas bara en gång, när den utfärdas, och i databasen finns endast SHA-256 av dess hemliga del kvar. Access- och refresh-tokens för anslutna AI-appar lagras inte heller i klartext; en anslutning är begränsad till den valda åtkomstnivån och kan återkallas av kontots ägare.

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.

I panelens rutter härleds partner_id från den signerade sessionen, i Partner API från en verifierad API-nyckel eller en OAuth-anslutning från en AI-app. Ägarens identifierare hämtas inte från sökvägen, query-parametrarna eller begärans kropp. API-nycklar begränsas dessutom av scope, giltighetstid och plan; för en ansluten AI beräknas rättigheterna vid varje begäran utifrån den nivå som ägaren har valt.

Innan något returneras eller ändras kontrollerar systemet på nytt att den aktuella servern, klustret, inbound, rutten, VPN-användaren eller betalningen tillhör det här kontot. Databasfrågor är begränsade av partner_id, och sammansatta unika och främmande nycklar avvisar ogiltiga länkar mellan partner. Auktoriseringsmatrisen i testerna kräver ett uttryckligt IDOR-scenario för varje endpoint med en resursidentifierare.

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

En slutanvändares e-postadress lagras inte hos oss: kontonamnet härleds oåterkalleligt och innehåller ingen adress. E-postmeddelandet med inloggningskoden skickas av oss, så adressen passerar vår sändningskö och tas bort ur den direkt efter utskicket — för att känna igen en återvändande användare återstår bara ett oåterkalleligt avtryck, ur vilket adressen inte kan återskapas. Det enda fall där en adress ändå blir kvar nämner vi rakt ut: vid betalning kommer den in i betalnings-webhooken och hamnar i betalningsloggen med en begränsad lagringstid.

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 själv radera ditt konto tillsammans med all dess data, i avsnittet ”Avancerade inställningar”, genom att bekräfta med en kod från din e-post (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). På OAuth-samtyckessidorna är analys tvångsavstängd: URL:en innehåller en kortlivad identifierare för begäran om att ansluta en AI, och den får inte lämnas vidare till tredje part. Det finns inga andra spårare från tredje part: ingen Sentry, PostHog, Mixpanel eller annonspixlar. Backenden har ingen tredjepartstelemetri, och slutanvändarnas butiker omfattas inte av analys.

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å den anslutna leverantörens sida (lava.top). Vi tar bara emot en verifierad webhook-händelse: dess äkthet fastställs på det sätt som den aktuella leverantören stöder, innan saldo eller åtkomst ändras. Vi tar inte emot det fullständiga kortnumret (PAN) eller CVV. Ny leverans av samma händelse 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.

För kontot lagras e-post, tidpunkt för senaste inloggning, gränssnittsläge och inställningar; för fakturering saldo och Telegram, om det har angetts för påfyllningar. För att skydda kontot innehåller en aktiv session tidpunkterna för skapande och senaste aktivitet, IP-adress och user-agent. Historiken över lyckade och misslyckade inloggningsförsök med samma tekniska kännetecken lagras i 90 dagar.

Det finns ingen samlad klickhistorik för panelen. Separat finns ändamålsspecifika loggar: förfrågningar till Partner API (högst de senaste 500 posterna och cirka 25 timmar), infrastrukturhändelser och diagnostikresultat (högst 7 dagar) samt åtgärder från anslutna AI-appar (så länge kontot finns). Innan AI-åtgärder loggas tas lösenord, tokens, nycklar och prenumerationslänkar bort, och användarnas e-postadresser maskeras.

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 serverns genererade adminlösenord. Koderna genereras av en kryptografisk generator; endast deras HMAC-hash lagras, och jämförelsen sker i konstant tid. Vid lyckad inloggning raderas koden omedelbart, och efter 5 felaktiga försök släcks den i förtid. Frekvensgränsen för utfärdande räknas både per fullständig adress och per fysisk brevlåda: byte av IP, punkter i Gmail-adresser och plus-taggar ger inte en separat gräns.

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.

Varje partnersession har en stabil identifierare på serversidan som behålls när token förnyas. Vanlig utloggning återkallar hela den aktuella sessionen, inte bara en enskild utfärdad token. I avsnittet ”Kontosessioner” visas enhet, IP-adress, inloggningstid och senaste aktivitet; varje session kan avslutas separat. Åtgärden ”Logga ut överallt” avslutar alla sessioner och kopplar från anslutna AI-appar.

Inloggningshistoriken lagras i 90 dagar och visar lyckade inloggningar, felaktiga och utgångna koder samt fall med för många försök. Vid tecken på återanvändning av en token som redan har bytts ut betraktar systemet sessionen som kopierad, avslutar alla sessioner och AI-anslutningar och skickar ett meddelande till ägaren.

Det finns inga sessionstokens i webbläsarens lokala lagring, bara gränssnittsinställningar. Token placeras i en HttpOnly-cookie av serverlagret i Next.js; webbläsaren får inte backendens interna adress och når den via Server Actions. CORS tillåter inte andra ursprung att läsa API-svar med auktoriserade data.

Det finns avsiktliga undantag som ägaren själv styr: export av den privata SSH-nyckeln efter en kod från ett e-postmeddelande (SR-4) och en ny Partner-API-nyckel, vars fullständiga hemlighet visas i webbläsaren en gång när den skapas. Därefter kan den inte återställas från databasen — där finns bara en hash kvar. Den publika API-domänen är, som avsett, nåbar från internet, men utan en giltig session, API-nyckel eller OAuth-token returnerar den inga skyddade data.

CreateYourVPN:s publika värdar levereras över HTTPS med HSTS (max-age två år, includeSubDomains). Varje webbfrontend vi driftar — plattformens webbplats, partnerpanelen och partnernas butiker, både på våra subdomäner och på partnerns egen domän — och API-domänen skickar samma uppsättning säkerhetsheaders: en Content-Security-Policy (default-src 'none' på API:et; på frontenderna förbjuder den inbäddning i en iframe och låser base-uri och form-action), X-Content-Type-Options: nosniff, X-Frame-Options och en hårt låst Referrer-Policy (no-referrer på API:et; strict-origin-when-cross-origin på frontenderna, som dessutom skickar en restriktiv Permissions-Policy).

Detta är i produktion på alla dessa värdar och går att kontrollera oberoende — med valfri HTTP-headerinspektör eller en tjänst som SSL Labs.

En AI-app ansluts via OAuth och får inte cookien från din panel. På samtyckessidan väljer du en av tre nivåer: endast visning; visning och konfiguration; radering och tilldelning av åtkomst. Rättigheterna kontrolleras av servern vid varje anrop. Kritiska raderingar kräver en extra engångskod från ett e-postmeddelande, och hela anslutningen kan återkallas i avsnittet ”Anslutna AI-appar”.

Varje verktygsanrop hamnar i en logg som ägaren kan se, med resultatet och en säker kopia av argumenten. Lösenord, tokens, API-nycklar, privata nycklar och prenumerationslänkar tas bort innan posten skrivs; användarnas e-postadresser maskeras. Samtidigt förblir den valda AI-appen en tredjepartstjänst: data som du medvetet har gett den i uppdrag att läsa eller ändra behandlas även enligt reglerna hos appens leverantör.