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.

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.

Auditované partnerské trasy autorizují podle partner_id, které server odvozuje z podepsaného přihlašovacího tokenu — ne z toho, co klient poslal v cestě nebo těle požadavku. Než cokoli vrátí nebo změní, systém znovu ověří, že požadovaný server, klastr, inbound, trasa, VPN uživatel nebo platba patří tvému účtu; příslušné databázové dotazy jsou omezeny tvým partner_id a schéma (složené unikátní klíče plus složené cizí klíče) odmítá neplatné mezipartnerské vazby. Izolace je vrstvená: aplikace, opětovné ověření v usecase, filtr partner_id a schéma.

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

Zde je poctivý seznam míst, kudy e-mail koncového uživatele skutečně prochází naší centrální databází: e-mail s přihlašovacím kódem odesíláme my, takže adresa prochází odesílací frontou (pro jakékoli přihlášení do obchodu, včetně bezplatného); při platbě přichází e-mail kupujícího v platebním webhooku a dostává se do protokolu plateb; při propojení Telegramu se e-mail ukládá do profilu. To jsou jediné styčné body — servisní a z nutnosti; netýkají se provozu ani chování uživatelů.

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 spolu se souvisejícími daty můžete smazat kontaktováním podpory (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ů). Žádné jiné trackery třetích stran nejsou: žádný Sentry, PostHog, Mixpanel ani reklamní pixely (ověřeno prohledáním obou frontendů). Backend nemá žádnou telemetrii třetích stran. Výloha pro koncové uživatele není analytikou pokryta vůbec — žádné GA, žádné trackery (ověřitelné z jejích zdrojů).

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ě poskytovatele (Tribute / Lemon Squeezy). K nám přichází jen podepsaný webhook (HMAC-SHA256, porovnání v konstantním čase, ověřený před parsováním těla a před jakýmkoli zápisem do databáze: bez znalosti tajemství událost neprojde ověřením). Plné číslo karty (PAN) ani CVV nedostáváme. Opětovné doručení téhož webhooku (opakování poskytovatele) 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.

Email (potřebný k přihlášení), čas posledního přihlášení, režim rozhraní; pro fakturaci — zůstatek a Telegram (pro dobití). IP partnera se v databázi neukládá a historii kliknutí ani akcí v panelu nevedeme (kromě krátkého přístupového logu při chybách).

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 Marzbanu. Kódy generuje kryptografický generátor; ukládá se jen jejich HMAC hash a porovnání je v konstantním čase. Kód je jednorázový: při úspěchu se okamžitě smaže (žádné opakování); po 5 chybných pokusech se předčasně zhasne. Limit četnosti vydávání se počítá podle emailu, ne podle IP — nelze ho obejít změnou adresy.

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.

Výhrada: odvolání je řešeno kontrolou existence partnera při každém požadavku, ne zneplatněním samotného tokenu; odhlášení smaže cookie, ale vydaný token zůstává kryptograficky platný do vypršení (až hodinu). Centralizovaný seznam odvolání zatím neexistuje (vědomé zjednodušení MVP).

V lokálním úložišti prohlížeče nejsou žádné tokeny (jen nastavení UI); tajemství ani adresa API se nedostanou do klientského balíčku. Token do cookie HttpOnly vkládá jen server (Next.js). Prohlížeč komunikuje s jádrem výhradně přes server (Server Actions): frontend nevolá API přímo z prohlížeče a CORS nepovoluje prohlížeči číst odpovědi API z jiných origin.

Upřesnění místo dřívějšího absolutu: samotná doména API je veřejný host — technicky ji z prohlížeče otevřít lze, ale bez relace nevrátí žádná autorizovaná data.

Veřejné domény CreateYourVPN jsou obsluhovány přes HTTPS s HSTS (max-age dva roky, includeSubDomains). Webový frontend i doména API posílají přísnou sadu bezpečnostních hlaviček: restriktivní Content-Security-Policy, X-Content-Type-Options: nosniff, X-Frame-Options a uzamčenou Referrer-Policy (no-referrer na API; strict-origin-when-cross-origin na frontendu, který navíc posílá restriktivní Permissions-Policy).

To běží v produkci na obou doménách a lze to nezávisle ověřit — libovolným inspektorem HTTP hlaviček nebo službou jako SSL Labs.