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.

Sekrety kluczy Partner API są nieodwracalne: pełny klucz jest pokazywany tylko raz przy wydaniu, a w bazie pozostaje SHA-256 jego części sekretnej. Tokeny access i refresh połączonych AI również nie są przechowywane w postaci jawnej; połączenie jest ograniczone do wybranego poziomu dostępu i może zostać cofnięte przez właściciela konta.

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.

W trasach panelu partner_id jest wyprowadzane z podpisanej sesji, a w Partner API — ze zweryfikowanego klucza API lub połączenia OAuth z AI. Identyfikator właściciela nie jest pobierany ze ścieżki, parametrów query ani treści żądania. Klucze API są dodatkowo ograniczone przez scope, okres ważności i plan; w przypadku połączonego AI zestaw uprawnień jest wyliczany przy każdym żądaniu na podstawie poziomu wybranego przez właściciela.

Zanim cokolwiek zwróci lub zmieni, system ponownie sprawdza, że serwer, klaster, inbound, trasa, użytkownik VPN lub płatność należą do tego konta. Zapytania do bazy są ograniczone przez partner_id, a złożone klucze unikalne i obce odrzucają niepoprawne powiązania międzypartnerskie. Macierz autoryzacji w testach wymaga jawnego scenariusza IDOR dla każdego endpointu z identyfikatorem zasobu.

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.

Adresu e-mail użytkownika końcowego u nas nie przechowujemy: nazwa jego konta jest wyprowadzana nieodwracalnie i nie zawiera adresu. Wiadomość z kodem logowania wysyłamy my, więc adres przechodzi przez naszą kolejkę wysyłki i jest z niej usuwany zaraz po wysłaniu — do rozpoznania powracającego użytkownika zostaje wyłącznie nieodwracalny odcisk, z którego adresu nie da się odtworzyć. Jedyny przypadek, w którym adres jednak zostaje, nazywamy wprost: przy płatności trafia w webhooku płatności do dziennika płatności z ograniczonym okresem przechowywania.

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 ze wszystkimi jego danymi możesz usunąć samodzielnie w sekcji „Ustawienia zaawansowane”, potwierdzając to kodem z wiadomości e-mail (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). Na stronach zgody OAuth analityka jest bezwarunkowo wyłączona: URL zawiera krótkotrwały identyfikator żądania połączenia AI, którego nie wolno przekazywać stronie trzeciej. Nie ma innych zewnętrznych trackerów: ani Sentry, ani PostHog, ani Mixpanel, ani pikseli reklamowych. Backend nie ma zewnętrznej telemetrii, a witryny użytkowników końcowych nie są objęte analityką.

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 podłączonego dostawcy (lava.top). Do nas trafia tylko zweryfikowane zdarzenie webhooka: jego autentyczność jest ustalana metodą obsługiwaną przez danego dostawcę, zanim zmieni się saldo lub dostęp. Nie otrzymujemy pełnego numeru karty (PAN) ani CVV. Ponowne dostarczenie tego samego zdarzenia 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.

Dla konta przechowywane są e-mail, czas ostatniego logowania, tryb interfejsu i ustawienia; do rozliczeń — saldo i Telegram, jeśli został podany do doładowań. W celu ochrony konta aktywna sesja zawiera czas utworzenia i ostatniej aktywności, adres IP oraz user-agent. Historia udanych i nieudanych prób logowania z tymi samymi danymi technicznymi jest przechowywana przez 90 dni.

Nie ma ogólnej historii kliknięć w panelu. Osobno istnieją dzienniki celowe: żądania Partner API — nie więcej niż 500 ostatnich wpisów i około 25 godzin, zdarzenia infrastruktury i wyniki diagnostyki — nie dłużej niż 7 dni, działania połączonych AI — wraz z kontem. Przed zapisaniem działań AI usuwane są hasła, tokeny, klucze i linki subskrypcji, a adresy e-mail użytkowników są maskowane.

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 serwera. Kody są generowane przez generator kryptograficzny; przechowywany jest tylko ich hash HMAC, a porównanie odbywa się w stałym czasie. Po sukcesie kod jest natychmiast usuwany, a po 5 błędnych próbach jest wygaszany wcześniej. Limit częstości wydawania liczony jest zarówno według pełnego adresu, jak i według fizycznej skrzynki pocztowej: zmiana IP, kropki w Gmailu i tagi plus nie dają osobnego limitu.

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.

Każda sesja partnera ma stabilny identyfikator po stronie serwera, który zostaje zachowany przy odświeżaniu tokenu. Zwykłe wylogowanie unieważnia całą bieżącą sesję, a nie tylko jedno wydanie tokenu. W sekcji „Sesje konta” widoczne są urządzenie, adres IP, czas logowania i ostatnia aktywność; każdą sesję można zakończyć osobno. Działanie „Wyloguj wszędzie” kończy wszystkie sesje i odłącza połączone AI.

Historia logowań jest przechowywana przez 90 dni i pokazuje udane logowania, błędne i wygasłe kody, a także przekroczenie liczby prób. Przy oznakach ponownego użycia już wymienionego wydania tokenu system uznaje sesję za skopiowaną, kończy wszystkie sesje i połączenia AI oraz wysyła powiadomienie właścicielowi.

W lokalnym magazynie przeglądarki nie ma tokenów sesji, tylko ustawienia interfejsu. Token do ciasteczka HttpOnly wkłada warstwa serwerowa Next.js; przeglądarka nie otrzymuje wewnętrznego adresu backendu i komunikuje się z nim przez Server Actions. CORS nie pozwala innym origin odczytywać odpowiedzi API z autoryzowanymi danymi.

Istnieją celowe wyjątki, którymi zarządza sam właściciel: eksport prywatnego klucza SSH po podaniu kodu z wiadomości e-mail (SR-4) oraz nowy klucz Partner API, którego pełny sekret jest pokazywany w przeglądarce jeden raz przy tworzeniu. Później nie da się go odtworzyć z bazy — pozostaje tam tylko hash. Publiczna domena API jest zgodnie z przeznaczeniem dostępna z internetu, ale bez ważnej sesji, klucza API lub tokenu OAuth nie zwraca chronionych danych.

Publiczne hosty CreateYourVPN są serwowane przez HTTPS z HSTS (max-age dwa lata, includeSubDomains). Każdy frontend webowy, który hostujemy — witryna platformy, panel partnera i sklepy partnerów, zarówno na naszych subdomenach, jak i na własnej domenie partnera — oraz domena API wysyłają ten sam zestaw nagłówków bezpieczeństwa: Content-Security-Policy (default-src 'none' na API; na frontendach zakazuje osadzania w ramce iframe i blokuje base-uri oraz form-action), X-Content-Type-Options: nosniff, X-Frame-Options i szczelną Referrer-Policy (no-referrer na API; strict-origin-when-cross-origin na frontendach, które wysyłają też restrykcyjną Permissions-Policy).

Działa to na produkcji na wszystkich tych hostach i można to sprawdzić niezależnie — dowolnym inspektorem nagłówków HTTP lub serwisem takim jak SSL Labs.

Aplikacja AI łączy się przez OAuth i nie otrzymuje ciasteczka twojego panelu. Na stronie zgody wybierasz jeden z trzech poziomów: tylko podgląd; podgląd i konfiguracja; usuwanie i przyznawanie dostępu. Uprawnienia są sprawdzane przez serwer przy każdym wywołaniu. Krytyczne usunięcia wymagają dodatkowego jednorazowego kodu z wiadomości e-mail, a całe połączenie można cofnąć w sekcji „Połączone AI”.

Każde wywołanie narzędzia trafia do widocznego dla właściciela dziennika wraz z wynikiem i bezpieczną kopią argumentów. Hasła, tokeny, klucze API, klucze prywatne i linki subskrypcji są usuwane przed zapisem; adresy e-mail użytkowników są maskowane. Wybrana aplikacja AI pozostaje jednak usługą zewnętrzną: dane, które świadomie powierzasz jej do odczytu lub zmiany, są przetwarzane także zgodnie z zasadami jej dostawcy.