Ověřitelná tvrzení.

Heslo je potřeba jen k otevření prvního SSH připojení a instalaci servisního uživatele. Předává se jako SSH autentizace našeho připojení — ne jako argument nebo proměnná prostředí skriptu. Naše databáze pro něj nemá pole; nedostává se do prostředí běhu skriptů a nezapisuje se do logů (chyby připojení obsahují jen adresu a port, nikdy heslo). V paměti se po použití vymaže (best-effort) — to je obrana do hloubky, ne záruka: Go může držet kopie hodnoty na haldě až do úklidu paměti.

Poctivá výhrada: zůstává to heslem root na tvém serveru. Po instalaci vypneme přihlášení heslem a přihlášení root přes SSH, ale samotné heslo neměníme — pokud chceš, změň si ho sám. „Neukládáme ho” je pravda; „přestalo být tajemstvím” ne.

PasswordAuthentication no, PermitRootLogin no, SSH přesunuto na nestandardní port (výchozí 12011), zapnutý fail2ban (hodinový ban po 5 neúspěších), přihlášení jen klíčem. Veřejný klíč je před použitím přísně validován: odmítají se konce řádků (ochrana proti propašování dalších klíčů do authorized_keys) a syntakticky neplatné klíče.

Ochrana proti uzamčení: port 22 se nezavře, dokud jádro nepotvrdí (přes ss), že nový SSH port skutečně naslouchá; konfigurace se ověřuje pomocí sshd -t a pravidlo sudo pomocí visudo -cf, obojí se při chybě vrátí zpět.

Panel nepracuje s tvým heslem, ale se samostatným klíčem (ed25519), který si sám generuje. Soukromá část leží v databázi zašifrovaná AES-256-GCM. Šifrovací klíč (KEK) je uložen odděleně od databáze — v proměnné prostředí serveru — a v produkci je povinný (neexistuje nebezpečná výchozí hodnota: bez KEK se kryptografický subsystém prostě nespustí). Týmž šifrováním jsou chráněna těžká tajemství v databázi — admin heslo/token/JWT Marzbanu, klíče Reality, klíče poskytovatelů plateb, cache přihlašovacích údajů proxy, konfigurace záloh.

Šifrování data nejen skrývá, ale i autentizuje (autentizační tag GCM): manipulace se zašifrovaným polem se při dešifrování odhalí a odmítne. Každé pole je šifrováno čerstvým náhodným nonce; hodnota KEK se nikdy nedostane do logů — jen její krátké id.

K tokenům oprávnění: token předplatného /sub je bearer tajemství. Pro vyhledání ukládáme jen jeho SHA-256, zatímco kopii potřebnou k opětovnému zobrazení již vydaného odkazu držíme jako šifrotext AES-GCM. Starší záznamy v otevřené podobě se před startem HTTP serveru migrují do nového formátu, fail-closed. Identifikátor URL platebního webhooku je uložen otevřeně, ale sám o sobě událost neautentizuje: pravost se ověřuje zvlášť podpisem HMAC.

Tajemství klíčů Partner API jsou nevratná: celý klíč se zobrazí jen jednou při vydání a v databázi zůstává SHA-256 jeho tajné části. Ani access a refresh tokeny připojené AI se neukládají v otevřené podobě; připojení je omezeno zvolenou úrovní přístupu a vlastník účtu ho může odvolat.

Klíč se dešifruje jen na serveru, v paměti; běžná API ho nikdy nevrací. Jediný způsob, jak ho získat, je záměrná exportní funkce („vezmi si svůj klíč”), chráněná přihlášením plus jednorázovým kódem na email (kód je uložen jen jako HMAC hash, porovnává se v konstantním čase, TTL 10 minut, 5 pokusů). Klíč tak lze získat záměrně, ne však „unést” běžným požadavkem.

Před změnou stavu serveru a před jakýmikoli síťovými operacemi na pozadí se pole s klíčem pro správu synchronně vynulují. Pokud databáze vymazání nepotvrdí, operace vrátí chybu a lze ji zopakovat. Smazání zůstává „měkké”: řádek a netajná servisní data se zachovávají. Neznamená to fyzické vymazání již vytvořených záloh — jejich životní cyklus řídí zásada uchovávání záloh.

V trasách panelu se partner_id odvozuje z podepsané relace, v Partner API z ověřeného API klíče nebo z OAuth připojení AI. Identifikátor vlastníka se nebere z cesty, query parametrů ani těla požadavku. API klíče jsou navíc omezeny oprávněními (scope), dobou platnosti a tarifem; u připojené AI se sada oprávnění vypočítává při každém požadavku z úrovně, kterou zvolil vlastník.

Než cokoli vrátí nebo změní, systém znovu ověří, že server, klastr, inbound, trasa, VPN uživatel nebo platba patří tomuto účtu. Databázové dotazy jsou omezeny partner_id a složené unikátní a cizí klíče odmítají neplatné mezipartnerské vazby. Autorizační matice v testech vyžaduje výslovný scénář IDOR pro každý endpoint s identifikátorem zdroje.

Poctivá výhrada: toto je ověřeno auditem kódu po celé cestě požadavku, ne veřejným penetračním testem — takže SR-16, stejně jako ostatní, je otevřené k vyvrácení v bug bounty.

Aby vše nastavoval automaticky (instaloval Xray+Reality, aplikoval konfiguraci, četl metriky), drží panel na serveru plný administrátorský přístup (ekvivalent root, přes servisního uživatele se sudo bez hesla). To je pro správu nezbytné a NEnazýváme to „omezeným”.

Co snižuje riziko: tajemství se na server předávají pouze přes stdin procesu (ne jako argumenty příkazu — nejsou vidět v seznamu procesů); po první instalaci každé připojení pro správu ověřuje připnutý klíč hosta serveru — podvržení serveru „uprostřed” je odmítnuto. Co ovládáš ty: přístup stojí na klíči, který můžeš kdykoli odvolat — smazáním serveru (klíč se vynuluje) nebo prostě smazáním VPS u svého poskytovatele (pak zmizí úplně vše).

Samotné VPN účty (VLESS/Reality) se vytvářejí a žijí v Marzban na tvém master serveru. Centrálně ukládáme jen to, co je nutné k vydání odkazu na předplatné: náhodný token předplatného a zašifrovaný snímek přihlašovacích údajů proxy (cache; zdrojem pravdy je tvůj Marzban). Nemáme žádný provoz, IP ani historii návštěv uživatelů.

E-mailovou adresu koncového uživatele u nás neuchováváme: název jeho účtu je odvozen nevratně a adresu neobsahuje. E-mail s přihlašovacím kódem posíláme my, takže adresa projde naší odesílací frontou a hned po odeslání se z ní odstraní — k rozpoznání vracejícího se uživatele zůstává jen nevratný otisk, ze kterého adresu obnovit nelze. Jediný případ, kdy adresa přece jen zůstane, pojmenováváme přímo: při platbě přijde v platebním webhooku a dostane se do protokolu plateb s omezenou dobou uchování.

Tato servisní data uchováváme jen po nezbytnou dobu a mažeme je automaticky: e-mail se z odesílací fronty odstraní hned po odeslání, tělo platební události po zpracování a události čekající na opakování do 90denního okna. Svůj účet se všemi jeho daty můžete smazat sami v sekci „Pokročilá nastavení“ a smazání potvrdit kódem z e-mailu (podrobnosti viz riziko 7). Zveřejňujeme to otevřeně, místo abychom to skrývali za vágní formulace.

Platforma CreateYourVPN nedostává ani neukládá informace o tom, jaké stránky navštěvuješ ty nebo tvoji uživatelé. Schéma příjmu metrik je uzavřené: fyzicky v něm nejsou pole pro IP, domény ani návštěvy — jen agregáty (počet unikátních online, celkové bajty, CPU/RAM/zátěž). Každý uzel se autentizuje HMAC tokenem navázaným na vlastní id a může zapisovat metriky jen za sebe. Balancer na uzlu (HAProxy) funguje jako TCP router podle SNI a nedešifruje provoz. Na samotném serveru se systémové deníky uchovávají nejdéle asi hodinu a nepředávají se do syslogu.

Nad rámec úrovně platformy nevedou žádný deník návštěv ani servery: přístupové logování Xray je při každém nasazení konfigurace vynuceně vypnuto (platforma nastavuje log.access na none), takže okrajová proxy nezaznamenává, na jaké adresy se uživatelé připojují. To je vynuceno v kódu a nasazeno na celou flotilu.

Abychom rozuměli, jak se web a panel používají, používáme Google Analytics (o sběru cookie a statistik varuje cookie banner; podrobnosti jsou v Zásadách ochrany osobních údajů). Na stránkách souhlasu OAuth je načítání analytiky vynuceně zakázáno: URL obsahuje krátkodobý identifikátor požadavku na připojení AI, který se nesmí předávat třetí straně. Žádné jiné trackery třetích stran nejsou: žádný Sentry, PostHog, Mixpanel ani reklamní pixely. Backend nemá žádnou telemetrii třetích stran a výlohy koncových uživatelů nejsou analytikou pokryty.

Výhrada: GA dostává tvou IP (na straně Google) a adresy prohlížených stránek panelu; URL panelu obsahují jen identifikátor klastru, ne email.

Platba a všechna data karty se zpracovávají na straně připojeného poskytovatele (lava.top). K nám přichází jen ověřená událost webhooku: její pravost se ověřuje způsobem, který podporuje konkrétní poskytovatel, ještě před změnou zůstatku nebo přístupu. Plné číslo karty (PAN) ani CVV nedostáváme. Opětovné doručení téže události nezpůsobí dvojí přiznání: události se deduplikují.

Výhrada: poskytovatel může do těla webhooku zahrnout metadata karty (značku a poslední 4 číslice) a jméno a email plátce. Původní tělo potřebuje worker do dokončení zpracování; po úspěšném zpracování se smaže spolu s emailovou nápovědou. Události čekající na opakování nebo ruční přezkum si původní tělo uchovávají jen do konce retenčního okna (90 dní bez aktivity), po kterém se metadata karty a email plátce automaticky vymažou. „Plné číslo karty tu není” je pravda, ale to je vlastnost poskytovatelů (tělo sami nefiltrujeme); „o kartě nevidíme vůbec nic” ne.

K účtu se ukládají e-mail, čas posledního přihlášení, režim rozhraní a nastavení; pro fakturaci — zůstatek a Telegram, pokud je uveden pro dobíjení. Kvůli ochraně účtu obsahuje aktivní relace čas vytvoření a poslední aktivity, IP adresu a user-agent. Historie úspěšných a neúspěšných pokusů o přihlášení se stejnými technickými údaji se uchovává 90 dní.

Obecná historie kliknutí v panelu neexistuje. Odděleně existují účelové protokoly: požadavky na Partner API — nejvýše 500 posledních záznamů a přibližně 25 hodin, události infrastruktury a výsledky diagnostiky — nejvýše 7 dní, akce připojené AI — spolu s účtem. Před zápisem akcí AI se odstraňují hesla, tokeny, klíče a odkazy na předplatné a e-maily uživatelů se maskují.

Firewall ve výchozím stavu zakazuje příchozí provoz. Ven jsou otevřené: 443 (VPN, Xray+Reality), SSH na nestandardním portu (výchozí 12011) a — na master serveru — port admin panelu Marzbanu, jen pro IP control-plane. Port 80 se otevírá zvlášť jen v režimu Let's Encrypt pro HTTP-01. Port 22 se po přesunu SSH zavře.

Porty pro správu uzlu jsou otevřené jen pro IP master serveru, ne ven (selhání této vazby přeruší instalaci). Pokud se firewall nestane aktivním, instalace selže. ICMP echo je omezeno jen pro IPv4; neslibujeme, že server je „neviditelný”, a ICMP IPv6 je zachováno, aby IPv6 fungovalo správně.

Unattended upgrades instaluje bezpečnostní aktualizace balíčků automaticky. Výhrada: automatický restart je záměrně vypnutý (aby se neověřené jádro samo nerestartovalo) — což znamená, že opravy vyžadující restart (jádro, občas OpenSSH) se aplikují až po ručním nebo plánovaném restartu. „Automatické patchování” platí pro uživatelský prostor, ne pro to, co vyžaduje restart.

NEtvrdíme, že server je „neviditelný” ani že „ho nelze naskenovat”. Port 443 je otevřený a odpovídá na TCP připojení jako každý webový server. Vlastnost „při nesprávném připojení vypadá jako obyčejná nesouvisející stránka” zajišťuje protokol Reality uvnitř Xray — samostatná komponenta, kterou nepovyšujeme na absolut.

Přihlášení partnera probíhá jednorázovým 6místným kódem zaslaným na email. Heslo k účtu neexistuje. Netýká se to interních přihlašovacích údajů spravovaných komponent, například vygenerovaného admin hesla serveru. Kódy generuje kryptografický generátor; ukládá se jen jejich HMAC hash a porovnání probíhá v konstantním čase. Při úspěchu se kód okamžitě smaže a po 5 chybných pokusech se předčasně zneplatní. Limit četnosti vydávání se počítá podle celé adresy i podle fyzické poštovní schránky: změna IP, tečky v Gmailu ani plus-tagy nedávají samostatný limit.

Token relace sedí v cookie HttpOnly a Secure (JS ho nepřečte), ověřuje se na backendu (nejen na okraji). Timeout nečinnosti a automatické odhlášení po nečinnosti jsou implementovány na klientovi, ne na serveru. Token je podepsán HS256; při ověřování striktně odmítáme jakýkoli jiný algoritmus (včetně „none”) — klasický útok záměny algoritmu neprojde. Token výlohy a token partnerského panelu jsou odděleny přes audience: token koncového uživatele se technicky nemůže dostat k partnerskému API (a naopak). Smazaný partner je odmítnut i s živým tokenem.

Každá partnerská relace má stabilní serverový identifikátor, který se zachovává při obnově tokenu. Běžné odhlášení odvolá celou aktuální relaci, nejen jedno vydání tokenu. V sekci „Relace účtu“ je vidět zařízení, IP adresa, čas přihlášení a poslední aktivita; kteroukoli relaci lze ukončit samostatně. Akce „Odhlásit se všude“ ukončí všechny relace a odpojí připojenou AI.

Historie přihlášení se uchovává 90 dní a ukazuje úspěšná přihlášení, chybné a prošlé kódy i překročení počtu pokusů. Při známkách opětovného použití již vyměněného vydání tokenu systém považuje relaci za zkopírovanou, ukončí všechny relace i připojení AI a pošle vlastníkovi upozornění.

V lokálním úložišti prohlížeče nejsou žádné relační tokeny, jen nastavení rozhraní. Token do cookie HttpOnly vkládá serverová vrstva Next.js; prohlížeč nedostává interní adresu backendu a komunikuje s ním přes Server Actions. CORS nepovoluje jiným origin číst odpovědi API s autorizovanými daty.

Existují záměrné výjimky, které řídí sám vlastník: export soukromého SSH klíče po zadání kódu z e-mailu (SR-4) a nový klíč Partner API, jehož celé tajemství se v prohlížeči zobrazí jednou při vytvoření. Poté ho z databáze obnovit nelze — zůstává tam jen hash. Veřejná doména API je z internetu dostupná záměrně, ale bez platné relace, API klíče nebo OAuth tokenu chráněná data nevrací.

Veřejné hosty CreateYourVPN jsou obsluhovány přes HTTPS s HSTS (max-age dva roky, includeSubDomains). Každý webový frontend, který provozujeme — web platformy, partnerský panel a obchody partnerů, ať už na našich subdoménách, nebo na vlastní doméně partnera — i doména API posílají stejnou sadu bezpečnostních hlaviček: Content-Security-Policy (default-src 'none' na API; na frontendech zakazuje vložení do iframu a fixuje base-uri a form-action), X-Content-Type-Options: nosniff, X-Frame-Options a uzamčenou Referrer-Policy (no-referrer na API; strict-origin-when-cross-origin na frontendech, které navíc posílají restriktivní Permissions-Policy).

Běží to v produkci na všech těchto hostech a lze to nezávisle ověřit — libovolným inspektorem HTTP hlaviček nebo službou jako SSL Labs.

AI aplikace se připojuje přes OAuth a nedostává cookie tvého panelu. Na stránce souhlasu vybíráš jednu ze tří úrovní: jen prohlížení; prohlížení a konfigurace; mazání a udělování přístupu. Oprávnění ověřuje server při každém volání. Kritická mazání vyžadují navíc jednorázový kód z e-mailu a celé připojení lze odvolat v sekci „Připojená AI“.

Každé volání nástroje se zapíše do protokolu viditelného vlastníkovi, spolu s výsledkem a bezpečnou kopií argumentů. Hesla, tokeny, API klíče, soukromé klíče a odkazy na předplatné se před zápisem odstraní; e-maily uživatelů se maskují. Zvolená AI aplikace však zůstává službou třetí strany: data, která jí vědomě svěřuješ ke čtení nebo změně, se zpracovávají také podle pravidel jejího poskytovatele.