Ellenőrizhető állítások.

A jelszó csak az első SSH-kapcsolat megnyitásához és egy szolgáltatásfelhasználó telepítéséhez szükséges. SSH-hitelesítésként adódik át a kapcsolatunkhoz — nem szkriptargumentumként vagy környezeti változóként. Az adatbázisunkban nincs mező hozzá; nem kerül be a szkriptfuttatási környezetekbe, és nem íródik naplókba (a kapcsolati hibák csak a címet és a portot tartalmazzák, a jelszót soha). A memóriában használat után törlődik (a lehetőségekhez mérten) — ez mélységi védelem, nem garancia: a Go a szemétgyűjtésig megőrizhet másolatokat az értékről a kupacban.

Őszinte fenntartás: ez továbbra is a root jelszó a szervereden. A telepítés után letiltjuk a jelszavas és a root SSH-bejelentkezést, de magát a jelszót nem változtatjuk meg — cseréld le magad, ha szeretnéd. A 'nem tároljuk' igaz; a 'megszűnt titok lenni' nem.

PasswordAuthentication no, PermitRootLogin no, az SSH nem szabványos portra (alapértelmezetten 12011) áthelyezve, fail2ban bekapcsolva (egyórás tiltás 5 sikertelen próbálkozás után), bejelentkezés csak kulccsal. A nyilvános kulcsot használat előtt szigorúan ellenőrizzük: az újsor karaktereket (védelem az extra kulcsok authorized_keys fájlba csempészése ellen) és a szintaktikailag érvénytelen kulcsokat elutasítjuk.

Kizárás elleni védelem: a 22-es port addig nem záródik be, amíg a kernel (az ss segítségével) meg nem erősíti, hogy az új SSH-port valóban figyel; a konfigurációt sshd -t paranccsal, a sudo-szabályt visudo -cf paranccsal ellenőrizzük, mindkettő hiba esetén visszavonásra kerül.

A panel nem a jelszavaddal dolgozik, hanem egy külön kulccsal (ed25519), amelyet maga generál. A privát rész az adatbázisban található, AES-256-GCM titkosítással. A titkosítási kulcs (KEK) az adatbázistól elkülönítve — a szerver egy környezeti változójában — tárolódik, és éles környezetben kötelező (nincs nem biztonságos alapértelmezés: KEK nélkül a kriptográfiai alrendszer egyszerűen nem indul el). Ugyanez a titkosítás védi az adatbázisban lévő nehéz titkokat — a Marzban admin jelszavát/tokenjét/JWT-jét, a Reality-kulcsokat, a fizetési szolgáltatók kulcsait, a proxy-hitelesítő adatok gyorsítótárát, a biztonsági mentés konfigurációját.

A titkosítás nemcsak elrejti, hanem hitelesíti is az adatokat (GCM auth tag): egy titkosított mező manipulálását a visszafejtéskor észleljük és elutasítjuk. Minden mező új, véletlenszerű noncével titkosítódik; a KEK értéke soha nem jut el a naplókba — csak a rövid azonosítója.

A képességtokenekről: a /sub előfizetési token egy bearer titok. A kereséshez csak a SHA-256-ját tároljuk, míg a már kiadott link ismételt megjelenítéséhez szükséges másolatot AES-GCM titkosított szövegként őrizzük. A régebbi, sima szöveges rekordokat az új formátumra migráljuk, fail-closed módon, még mielőtt a HTTP-szerver elindulna. A fizetési webhook URL-azonosítója titkosítatlanul tárolódik, de önmagában nem hitelesít egy eseményt: a hitelességet külön, HMAC-aláírással ellenőrizzük.

A kulcsot csak a szerveren, a memóriában fejtjük vissza; a szokásos API-k soha nem adják vissza. Az egyetlen módja a megszerzésének egy szándékos exportfunkció ('vidd el a kulcsodat'), amelyet bejelentkezés és egy egyszer használatos e-mailes kód véd (a kódot csak HMAC-hashként tároljuk, állandó időben hasonlítjuk össze, 10 perces TTL, 5 próbálkozás). A kulcs tehát szándékosan lekérhető, de egy szokásos kérésen keresztül nem 'szivároghat ki'.

Mielőtt a szerver állapota megváltozna, és mindenféle háttérben futó hálózati művelet előtt, a kezelőkulcsot tartalmazó mezőket szinkron módon nullázzuk. Ha az adatbázis nem erősíti meg a törlést, a művelet hibát ad vissza, és újra megpróbálható. A törlés 'lágy' marad: a sor és a nem titkos szolgáltatási adatok megmaradnak. Ez nem jelenti a már létrehozott biztonsági mentések fizikai törlését — azok életciklusát a biztonsági mentések megőrzési szabályzata határozza meg.

Az auditált partnerútvonalak a partner_id alapján adnak jogosultságot, amelyet a szerver az aláírt bejelentkezési tokenből vezet le — nem abból, amit a kliens az útvonalban vagy a törzsben küldött. Mielőtt bármit visszaadna vagy módosítana, a rendszer újra ellenőrzi, hogy a kért szerver, klaszter, inbound, útvonal, VPN-felhasználó vagy fizetés a fiókodhoz tartozik-e; a megfelelő adatbázis-lekérdezések a partner_id-dre vannak korlátozva, és a séma (összetett egyedi kulcsok, valamint összetett idegen kulcsok) elutasítja az érvénytelen, partnerek közötti kapcsolódásokat. Az elkülönítés rétegzett: alkalmazás, usecase-újraellenőrzés, egy partner_id-szűrő és a séma.

Őszinte fenntartás: ezt a teljes kéréssúton végigvitt kódaudit igazolja, nem nyilvános behatolási teszt — így az SR-16, akárcsak a többi, nyitva áll a cáfolatra a bug bountyban.

Ahhoz, hogy mindent automatikusan beállítson (Xray+Reality telepítése, konfiguráció alkalmazása, mutatók olvasása), a panel teljes adminisztrátori hozzáféréssel rendelkezik a szerveren (root-egyenértékű, egy jelszó nélküli sudóval rendelkező szolgáltatásfelhasználón keresztül). Ez a kezeléshez szükséges, és NEM nevezzük 'korlátozottnak'.

Ami csökkenti a kockázatot: a titkok csak a folyamat stdin-jén keresztül jutnak el a szerverre (nem parancsargumentumként — nem láthatók a folyamatlistában); az első telepítés után minden kezelési kapcsolat ellenőrzi a szerver rögzített hosztkulcsát — a 'középen' történő szervercserét elutasítja. Amit te irányítasz: a hozzáférés egy olyan kulcson alapul, amelyet bármikor visszavonhatsz — a szerver törlésével (a kulcs nullázódik) vagy egyszerűen a VPS törlésével a szolgáltatódnál (ekkor minden eltűnik).

Maguk a VPN-fiókok (VLESS/Reality) a Marzbanban, a master szervereden jönnek létre és ott élnek. Központilag csak azt tároljuk, ami egy előfizetési link kiadásához szükséges: egy véletlenszerű előfizetési tokent és a proxy-hitelesítő adatok titkosított pillanatképét (gyorsítótár; az igazság forrása a te Marzbanod). Nincs forgalmi, IP- vagy felhasználói látogatási előzményünk.

Íme egy őszinte lista arról, hol halad át a végfelhasználó e-mailje valóban a központi adatbázisunkon: a bejelentkezési kódot tartalmazó e-mailt mi küldjük, így a cím áthalad a küldési sorunkon (bármely, az áruházba történő bejelentkezéshez, az ingyeneset is beleértve); fizetéskor a vásárló e-mailje a fizetési webhookban érkezik meg, és bekerül a fizetési naplóba; a Telegram összekapcsolásakor az e-mail a profilba mentődik. Ezek az egyetlen érintkezési pontok — szolgáltatásiak és szükségszerűek; egyikük sem érint forgalmat vagy felhasználói viselkedést.

Ezeket a szolgáltatási adatokat csak a szükséges ideig tároljuk, és automatikusan töröljük: az e-mail közvetlenül a küldés után eltávolításra kerül a küldési sorból, egy fizetési esemény tartalma a feldolgozás után, az újrapróbálkozásra váró események pedig egy 90 napos időszakon belül. Fiókját a hozzá tartozó adatokkal együtt az ügyfélszolgálattal való kapcsolatfelvétellel törölheti (részletekért lásd a 7. kockázatot). Ezt nyíltan feltárjuk, nem pedig homályos megfogalmazások mögé rejtjük.

A CreateYourVPN platform nem fogad és nem tárol információt arról, hogy te vagy a felhasználóid mely oldalakat látogatjátok. A mutatók befogadási sémája zárt: fizikailag nincsenek benne mezők IP-címekhez, domainekhez vagy látogatásokhoz — csak összesített értékek (egyedi online darabszám, összes bájt, CPU/RAM/terhelés). Minden node egy saját azonosítójához kötött HMAC-tokennel hitelesít, és csak saját magának írhat mutatókat. A node-on futó terheléselosztó (HAProxy) SNI szerinti TCP-útválasztóként működik, és nem fejti vissza a forgalmat. Magán a szerveren a rendszernaplók legfeljebb körülbelül egy óráig őrződnek meg, és nem továbbítódnak a syslogba.

A platformszinten túl a szerverek sem vezetnek látogatási naplót: az Xray hozzáférési naplózása minden konfigurációküldéskor kényszerítetten ki van kapcsolva (a platform a log.access értékét none-ra állítja), így a peremproxy nem rögzíti, hogy a felhasználók mely címekhez csatlakoznak. Ez a kódban van kikényszerítve és az egész flottára ki van osztva.

Hogy megértsük, hogyan használják az oldalt és a panelt, a Google Analyticsot alkalmazzuk (a cookie-sáv figyelmeztet a cookie-k és statisztikák gyűjtésére; a részletek az Adatvédelmi szabályzatban vannak). Nincsenek más, harmadik féltől származó nyomkövetők: nincs Sentry, PostHog, Mixpanel vagy hirdetési pixel (mindkét frontend átvizsgálásával ellenőrizve). A backendben egyáltalán nincs harmadik féltől származó telemetria. A végfelhasználói storefront egyáltalán nem tartozik analitika alá — nincs GA, nincsenek nyomkövetők (a forráskódjából ellenőrizhető).

Fenntartás: a GA megkapja az IP-címedet (a Google oldalán) és a megtekintett paneloldalak címeit; a panel URL-jei csak egy klaszterazonosítót tartalmaznak, nem e-mail-címet.

A fizetést és minden kártyaadatot a szolgáltató oldalán kezelnek (Tribute / Lemon Squeezy). Csak egy aláírt webhookot kapunk (HMAC-SHA256, állandó idejű összehasonlítás, ellenőrizve a törzs elemzése előtt és bármilyen adatbázisírás előtt: a titok ismerete nélkül egy esemény nem megy át az ellenőrzésen). Nem kapjuk meg a teljes kártyaszámot (PAN) vagy a CVV-t. Ugyanazon webhook újbóli kézbesítése (a szolgáltató újrapróbálkozásai) nem okoz kettős jóváírást — az eseményeket duplikációmentesítjük.

Fenntartás: a szolgáltató a webhook törzsében kártyametaadatokat (márka és az utolsó 4 számjegy), valamint a fizető nevét és e-mail-címét is szerepeltetheti. Az eredeti törzsre a feldolgozó munkafolyamatnak a feldolgozás befejezéséig szüksége van; sikeres feldolgozás után az e-mail-utalással együtt törlődik. Az újrapróbálkozásra vagy manuális felülvizsgálatra váró események csak a megőrzési időszak végéig (90 nap aktivitás nélkül) őrzik meg az eredeti törzset, ezután a kártya metaadatai és a fizető e-mail-címe automatikusan törlődik. A 'nincs teljes kártyaszám' igaz, de ez a szolgáltatók tulajdonsága (a törzset nem mi magunk szűrjük); a 'egyáltalán semmit nem látunk a kártyáról' nem.

E-mail (a bejelentkezéshez szükséges), utolsó bejelentkezés ideje, felületmód; a számlázáshoz — egyenleg és Telegram (a feltöltésekhez). A partner IP-címét nem tároljuk az adatbázisban, és nem őrzünk kattintási vagy műveleti előzményeket a panelben (a hibák esetén keletkező rövid hozzáférési naplón kívül).

A tűzfal alapértelmezetten tiltja a bejövő forgalmat. Kifelé nyitva: 443 (VPN, Xray+Reality), SSH nem szabványos porton (alapértelmezetten 12011), és — a master szerveren — a Marzban adminpanel portja, csak a control-plane IP-címek számára. A 80-as portot külön, csak Let's Encrypt módban nyitjuk meg a HTTP-01-hez. A 22-es port bezáródik, miután az SSH-t áthelyeztük.

A node kezelőportjai csak a master szerver IP-címe felé nyitottak, kifelé nem (e kötés meghiúsulása megszakítja a telepítést). Ha a tűzfal nem aktiválódik, a telepítés meghiúsul. Az ICMP echo csak az IPv4 esetén korlátozott; nem ígérjük, hogy a szerver 'láthatatlan', és az IPv6 ICMP megmarad, hogy az IPv6 helyesen működjön.

Az unattended upgrades automatikusan telepíti a biztonsági csomagok frissítéseit. Fenntartás: az automatikus újraindítás szándékosan le van tiltva (hogy egy nem ellenőrzött kernel ne induljon újra magától) — ami azt jelenti, hogy az újraindítást igénylő javítások (kernel, néha OpenSSH) csak kézi vagy ütemezett újraindítás után lépnek életbe. Az 'automatikus foltozás' igaz a userlandra, de nem arra, ami újraindítást igényel.

NEM állítjuk, hogy a szerver 'láthatatlan' vagy 'nem szkennelhető'. A 443-as port nyitva van, és úgy válaszol egy TCP-kapcsolatra, mint bármely webszerver. A 'helytelen kapcsolat esetén egy közönséges, független weboldalnak tűnik' tulajdonságot az Xrayen belüli Reality-protokoll biztosítja — egy külön komponens, amelyet nem emelünk abszolút szintre.

A partner egy egyszer használatos, 6 számjegyű, e-mailben küldött kóddal jelentkezik be. Nincs fiókjelszó. Ez nem vonatkozik a kezelt komponensek belső hitelesítő adataira, például a generált Marzban admin jelszóra. A kódokat kriptográfiai generátor állítja elő; csak a HMAC-hashük tárolódik, és az összehasonlítás állandó idejű. A kód egyszer használatos: sikeres esetén azonnal törlődik (nincs visszajátszás); 5 hibás próbálkozás után korán érvénytelenítjük. A kibocsátási gyakorisági korlát e-mail-címenként számít, nem IP-nként — nem kerülhető meg a címek váltogatásával.

A munkamenet-token egy HttpOnly és Secure cookie-ban ül (a JS nem olvashatja), és a backenden ellenőrizzük (nem csak a peremen). A tétlenségi időtúllépés és az inaktivitás miatti automatikus kijelentkezés a kliensen van megvalósítva, nem a szerveren. A token HS256-tal van aláírva; az ellenőrzéskor szigorúan elutasítunk minden más algoritmust (beleértve a 'none'-t is) — a klasszikus algoritmuscserés támadás nem megy át. A storefront-token és a partnerpanel-token az audience alapján van elkülönítve: egy végfelhasználói token technikailag nem juthat el a partner-API-hoz (és fordítva). Egy törölt partnert még élő tokennel is elutasítunk.

Fenntartás: a visszavonás úgy van megvalósítva, hogy minden kérésnél ellenőrizzük, létezik-e a partner, nem magának a tokennek az érvénytelenítésével; a kijelentkezés törli a cookie-t, de egy kiadott token kriptográfiailag érvényes marad a lejáratáig (legfeljebb egy óráig). Egyelőre nincs központi visszavonási lista (tudatos MVP-egyszerűsítés).

A böngésző local storage-ában nincsenek tokenek (csak felületi beállítások); sem titkok, sem az API-cím nem kerül a kliensoldali csomagba. Csak a szerver (Next.js) helyezi a tokent egy HttpOnly cookie-ba. A böngésző csak a szerveren keresztül beszél a maggal (Server Actions): a frontend nem hívja közvetlenül az API-t a böngészőből, és a CORS nem engedi, hogy a böngésző más eredetű API-válaszokat olvasson.

Pontosítás egy korábbi abszolútum helyett: maga az API-domain nyilvános hoszt — technikailag megnyithatod egy böngészőből, de munkamenet nélkül nem ad vissza jogosultsághoz kötött adatokat.

A CreateYourVPN nyilvános domainjeit HTTPS-en keresztül, HSTS-sel szolgáljuk ki (max-age két év, includeSubDomains). Mind a webes frontend, mind az API-domain szigorú biztonsági fejléckészletet küld: egy megszorító Content-Security-Policy-t, X-Content-Type-Options: nosniff, X-Frame-Options és egy lezárt Referrer-Policy (no-referrer az API-n; strict-origin-when-cross-origin a frontenden, amely egy megszorító Permissions-Policy-t is küld).

Ez élesben fut mindkét domainen, és függetlenül ellenőrizhető — bármely HTTP-fejléc-vizsgálóval vagy egy olyan szolgáltatással, mint az SSL Labs.