Sprawdzalne twierdzenia.

Hasło jest potrzebne tylko do otwarcia pierwszego połączenia SSH i zainstalowania użytkownika serwisowego. Przekazywane jest jako uwierzytelnienie SSH naszego połączenia — nie jako argument ani zmienna środowiskowa skryptu. W naszej bazie nie ma na nie pola; nie trafia do środowisk uruchomień skryptów i nie jest zapisywane w logach (błędy połączenia zawierają tylko adres i port, nigdy hasło). W pamięci jest wymazywane (best-effort) po użyciu — to obrona w głąb, nie gwarancja: Go może trzymać kopie wartości na stercie do czasu odśmiecania pamięci.

Uczciwe zastrzeżenie: pozostaje to hasłem root na twoim serwerze. Po instalacji wyłączamy logowanie hasłem i logowanie root przez SSH, ale samego hasła nie zmieniamy — zmień je sam, jeśli chcesz. „Nie przechowujemy go” to prawda; „przestało być sekretem” — nie.

PasswordAuthentication no, PermitRootLogin no, SSH przeniesiony na niestandardowy port (domyślnie 12011), włączony fail2ban (godzinna blokada po 5 nieudanych próbach), logowanie tylko kluczem. Klucz publiczny jest ściśle walidowany przed użyciem: odrzucane są znaki nowej linii (ochrona przed przemyceniem dodatkowych kluczy do authorized_keys) oraz klucze niepoprawne składniowo.

Ochrona przed zablokowaniem dostępu: port 22 nie jest zamykany, dopóki jądro nie potwierdzi (przez ss), że nowy port SSH faktycznie nasłuchuje; konfiguracja jest sprawdzana przez sshd -t, a reguła sudo przez visudo -cf, obie wycofywane przy błędzie.

Panel działa nie na twoim haśle, lecz na osobnym kluczu (ed25519), który sam generuje. Część prywatna leży w bazie zaszyfrowana AES-256-GCM. Klucz szyfrujący (KEK) jest przechowywany oddzielnie od bazy — w zmiennej środowiskowej serwera — a na produkcji jest obowiązkowy (nie ma niebezpiecznej wartości domyślnej: bez KEK podsystem kryptograficzny po prostu się nie uruchamia). To samo szyfrowanie chroni ciężkie sekrety w bazie — hasło/token/JWT admina Marzban, klucze Reality, klucze dostawców płatności, cache poświadczeń proxy, konfigurację kopii zapasowych.

Szyfrowanie nie tylko ukrywa, ale i uwierzytelnia dane (tag uwierzytelniający GCM): manipulacja zaszyfrowanym polem jest wykrywana przy odszyfrowaniu i odrzucana. Każde pole jest szyfrowane świeżym losowym nonce; wartość KEK nigdy nie trafia do logów — tylko jej krótki id.

O tokenach uprawnień: token subskrypcji /sub to sekret typu bearer. Do wyszukiwania przechowujemy tylko jego SHA-256, a kopię potrzebną do ponownego wyświetlenia już wydanego linku trzymamy jako szyfrogram AES-GCM. Starsze rekordy w postaci jawnej są migrowane do nowego formatu, fail-closed, przed startem serwera HTTP. Identyfikator URL webhooka płatności jest przechowywany jawnie, ale sam w sobie nie uwierzytelnia zdarzenia: autentyczność jest weryfikowana osobno podpisem HMAC.

Klucz jest odszyfrowywany tylko na serwerze, w pamięci; zwykłe API nigdy go nie zwracają. Jedynym sposobem na jego uzyskanie jest celowa funkcja eksportu („zabierz swój klucz”), chroniona logowaniem plus jednorazowym kodem na email (kod jest przechowywany tylko jako hash HMAC, porównywany w stałym czasie, TTL 10 minut, 5 prób). Klucz można więc pobrać świadomie, ale nie „wyciec” go zwykłym żądaniem.

Przed zmianą stanu serwera i przed jakimikolwiek operacjami sieciowymi w tle pola z kluczem zarządzania są synchronicznie zerowane. Jeśli baza nie potwierdzi wyczyszczenia, operacja zwraca błąd i można ją ponowić. Usunięcie pozostaje „miękkie”: wiersz i niesekretne dane serwisowe są zachowywane. Nie oznacza to fizycznego skasowania już utworzonych kopii zapasowych — ich cykl życia reguluje polityka retencji kopii.

Zaudytowane trasy partnera autoryzują po partner_id, które serwer wyprowadza z podpisanego tokenu logowania — a nie z tego, co klient przysłał w ścieżce lub treści żądania. Zanim cokolwiek zwróci lub zmieni, system ponownie sprawdza, że żądany serwer, klaster, inbound, trasa, użytkownik VPN lub płatność należą do twojego konta; odpowiednie zapytania do bazy są ograniczone twoim partner_id, a schemat (złożone klucze unikalne oraz złożone klucze obce) odrzuca niepoprawne powiązania międzypartnerskie. Izolacja jest warstwowa: aplikacja, ponowna weryfikacja w usecase, filtr partner_id oraz schemat.

Uczciwe zastrzeżenie: jest to zweryfikowane audytem kodu na całej ścieżce żądania, a nie publicznym testem penetracyjnym — więc SR-16, jak i reszta, jest otwarte na obalenie w bug bounty.

Aby wszystko konfigurować automatycznie (instalować Xray+Reality, stosować konfigurację, czytać metryki), panel ma na serwerze pełny dostęp administracyjny (odpowiednik root, przez użytkownika serwisowego z sudo bez hasła). Jest to niezbędne do zarządzania i NIE nazywamy tego „ograniczonym”.

Co zmniejsza ryzyko: sekrety są przekazywane na serwer wyłącznie przez stdin procesu (nie jako argumenty polecenia — nie są widoczne na liście procesów); po pierwszej instalacji każde połączenie zarządzające weryfikuje przypięty klucz hosta serwera — podmiana serwera „w środku” jest odrzucana. Co ty kontrolujesz: dostęp opiera się na kluczu, który w każdej chwili możesz odwołać — usuwając serwer (klucz zostaje wyzerowany) albo po prostu usuwając VPS u swojego dostawcy (wtedy znika wszystko).

Same konta VPN (VLESS/Reality) są tworzone i żyją w Marzban na twoim serwerze master. Centralnie przechowujemy tylko to, co jest niezbędne do wydania linku subskrypcyjnego: losowy token subskrypcji i zaszyfrowaną migawkę poświadczeń proxy (cache; źródłem prawdy jest twój Marzban). Nie mamy ruchu, IP ani historii odwiedzin użytkowników.

Oto uczciwa lista miejsc, w których e-mail użytkownika końcowego rzeczywiście przechodzi przez naszą centralną bazę danych: wiadomość z kodem logowania wysyłamy my, więc adres przechodzi przez naszą kolejkę wysyłkową (dla każdego logowania do sklepu, w tym bezpłatnego); przy płatności e-mail kupującego trafia do webhooka płatności i wchodzi do dziennika płatności; przy łączeniu Telegrama e-mail jest zapisywany w profilu. To jedyne punkty styku — służbowe i z konieczności; nie dotyczą ruchu ani zachowania użytkowników.

Te dane serwisowe przechowujemy tylko tak długo, jak to konieczne, i czyścimy je automatycznie: e-mail jest usuwany z kolejki wysyłkowej zaraz po wysłaniu, treść zdarzenia płatności po przetworzeniu, a zdarzenia oczekujące na ponowną próbę w ramach 90-dniowego okna. Swoje konto wraz z powiązanymi danymi możesz usunąć, kontaktując się ze wsparciem (szczegóły w ryzyku 7). Ujawniamy to otwarcie, zamiast ukrywać za ogólnikowymi sformułowaniami.

Platforma CreateYourVPN nie otrzymuje ani nie przechowuje informacji o tym, jakie strony odwiedzasz ty lub twoi użytkownicy. Schemat przyjmowania metryk jest zamknięty: fizycznie nie ma w nim pól na IP, domeny czy odwiedziny — tylko agregaty (liczba unikalnych online, łączne bajty, CPU/RAM/obciążenie). Każdy węzeł uwierzytelnia się tokenem HMAC powiązanym z własnym id i może zapisywać metryki tylko za siebie. Balanser na węźle (HAProxy) działa jako router TCP po SNI i nie odszyfrowuje ruchu. Na samym serwerze dzienniki systemowe są przechowywane nie dłużej niż około godzinę i nie są przekazywane do syslog.

Poza poziomem platformy również serwery nie prowadzą dziennika odwiedzin: logowanie dostępu Xray jest wymuszenie wyłączane przy każdym wypchnięciu konfiguracji (platforma ustawia log.access na none), więc serwer brzegowy nie rejestruje, z jakimi adresami łączą się użytkownicy. Jest to egzekwowane w kodzie i wdrożone na całą flotę.

Aby rozumieć, jak używane są strona i panel, stosujemy Google Analytics (o zbieraniu cookie i statystyk ostrzega baner cookie; szczegóły w Polityce prywatności). Nie ma innych zewnętrznych trackerów: ani Sentry, ani PostHog, ani Mixpanel, ani pikseli reklamowych (zweryfikowane przez przeszukanie obu frontendów). Backend nie ma żadnej zewnętrznej telemetrii. Witryna dla użytkowników końcowych nie jest w ogóle objęta analityką — bez GA, bez trackerów (sprawdzalne w jej źródłach).

Zastrzeżenie: GA otrzymuje twój IP (po stronie Google) oraz adresy oglądanych stron panelu; adresy URL panelu zawierają tylko identyfikator klastra, nie email.

Płatność i wszystkie dane karty są obsługiwane po stronie dostawcy (Tribute / Lemon Squeezy). Do nas trafia tylko podpisany webhook (HMAC-SHA256, porównanie w stałym czasie, weryfikowany przed parsowaniem treści i przed jakimkolwiek zapisem do bazy: bez znajomości sekretu zdarzenie nie przechodzi weryfikacji). Nie otrzymujemy pełnego numeru karty (PAN) ani CVV. Ponowne dostarczenie tego samego webhooka (ponowienia dostawcy) nie powoduje podwójnego przyznania — zdarzenia są deduplikowane.

Zastrzeżenie: dostawca może zawrzeć w treści webhooka metadane karty (marka i ostatnie 4 cyfry) oraz imię i email płatnika. Oryginalna treść jest potrzebna workerowi do zakończenia przetwarzania; po pomyślnym przetworzeniu jest usuwana wraz z podpowiedzią email. Zdarzenia oczekujące na ponowienie lub ręczny przegląd zachowują oryginalną treść tylko do końca okna retencji (90 dni bez aktywności), po czym metadane karty i email płatnika są automatycznie usuwane. „Nie ma pełnego numeru karty” to prawda, ale to właściwość dostawców (sami nie filtrujemy treści); „w ogóle niczego nie widzimy o karcie” — nie.

Email (potrzebny do logowania), czas ostatniego logowania, tryb interfejsu; do rozliczeń — saldo i Telegram (do doładowań). IP partnera nie jest przechowywane w bazie, a historii kliknięć czy działań w panelu nie prowadzimy (poza krótkim logiem dostępu przy błędach).

Zapora domyślnie odrzuca ruch przychodzący. Na zewnątrz otwarte: 443 (VPN, Xray+Reality), SSH na niestandardowym porcie (domyślnie 12011) oraz — na serwerze master — port panelu admina Marzban, tylko dla IP control-plane. Port 80 jest otwierany osobno tylko w trybie Let's Encrypt dla HTTP-01. Port 22 jest zamykany po przeniesieniu SSH.

Porty zarządzające węzła są otwarte tylko dla IP serwera master, a nie na zewnątrz (niepowodzenie tego powiązania przerywa instalację). Jeśli zapora nie stanie się aktywna, instalacja kończy się błędem. ICMP echo jest ograniczone tylko dla IPv4; nie obiecujemy, że serwer jest „niewidzialny”, a ICMP IPv6 jest zachowane, by IPv6 działało poprawnie.

Unattended upgrades instaluje aktualizacje bezpieczeństwa pakietów automatycznie. Zastrzeżenie: automatyczny restart jest celowo wyłączony (aby niezweryfikowane jądro nie uruchomiło się ponownie samo) — co oznacza, że poprawki wymagające restartu (jądro, czasem OpenSSH) są stosowane dopiero po ręcznym lub zaplanowanym restarcie. „Auto-patchowanie” to prawda dla przestrzeni użytkownika, nie dla tego, co wymaga restartu.

NIE twierdzimy, że serwer jest „niewidzialny” ani „nie da się go zeskanować”. Port 443 jest otwarty i odpowiada na połączenie TCP jak każdy serwer WWW. Właściwość „przy niepoprawnym połączeniu wygląda jak zwykła, niepowiązana strona” zapewnia protokół Reality wewnątrz Xray — osobny komponent, którego nie podnosimy do absolutu.

Logowanie partnera odbywa się jednorazowym 6-cyfrowym kodem wysyłanym na email. Nie ma hasła do konta. Nie dotyczy to wewnętrznych poświadczeń zarządzanych komponentów, takich jak wygenerowane hasło admina Marzban. Kody są generowane przez generator kryptograficzny; przechowywany jest tylko ich hash HMAC, a porównanie odbywa się w stałym czasie. Kod jest jednorazowy: po sukcesie jest natychmiast usuwany (brak powtórzenia); po 5 błędnych próbach jest wygaszany wcześniej. Limit częstości wydawania liczony jest per email, nie per IP — nie da się go obejść zmianą adresu.

Token sesji siedzi w ciasteczku HttpOnly i Secure (JS go nie odczyta), weryfikowanym na backendzie (nie tylko na brzegu). Limit bezczynności i automatyczne wylogowanie po bezczynności są zaimplementowane po stronie klienta, nie serwera. Token jest podpisany HS256; przy weryfikacji stanowczo odrzucamy każdy inny algorytm (w tym „none”) — klasyczny atak podmiany algorytmu nie przechodzi. Token witryny i token panelu partnera są rozdzielone przez audience: token użytkownika końcowego technicznie nie może sięgnąć do API partnera (i odwrotnie). Usunięty partner jest odrzucany nawet z żywym tokenem.

Zastrzeżenie: unieważnianie jest zrealizowane przez sprawdzanie istnienia partnera przy każdym żądaniu, a nie przez unieważnienie samego tokenu; wylogowanie usuwa ciasteczko, ale wydany token pozostaje kryptograficznie ważny do wygaśnięcia (do godziny). Nie ma jeszcze scentralizowanej listy unieważnień (świadome uproszczenie MVP).

W lokalnym magazynie przeglądarki nie ma tokenów (tylko ustawienia UI); sekrety ani adres API nie trafiają do bundla klienckiego. Token do ciasteczka HttpOnly wkłada tylko serwer (Next.js). Przeglądarka rozmawia z rdzeniem wyłącznie przez serwer (Server Actions): frontend nie woła API bezpośrednio z przeglądarki, a CORS nie pozwala na przeglądarkowe odczyty odpowiedzi API z innych origin.

Doprecyzowanie zamiast dawnego absolutu: sama domena API to publiczny host — technicznie można ją otworzyć z przeglądarki, ale bez sesji nie zwraca żadnych autoryzowanych danych.

Publiczne domeny CreateYourVPN są serwowane przez HTTPS z HSTS (max-age dwa lata, includeSubDomains). Zarówno frontend webowy, jak i domena API wysyłają ścisły zestaw nagłówków bezpieczeństwa: restrykcyjną Content-Security-Policy, X-Content-Type-Options: nosniff, X-Frame-Options oraz zablokowaną Referrer-Policy (no-referrer na API; strict-origin-when-cross-origin na frontendzie, który wysyła też restrykcyjną Permissions-Policy).

Działa to na produkcji na obu domenach i można to niezależnie sprawdzić — dowolnym inspektorem nagłówków HTTP lub usługą taką jak SSL Labs.