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 Partner API-kulcsok titkos része visszafordíthatatlan formában tárolódik: a teljes kulcs csak egyszer, a kiállításkor jelenik meg, az adatbázisban pedig a titkos rész SHA-256-ja marad. A csatlakoztatott MI access és refresh tokenjeit szintén nem tároljuk sima szövegként; a kapcsolat a kiválasztott hozzáférési szintre korlátozódik, és a fiók tulajdonosa visszavonhatja.

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.

A panel útvonalain a partner_id-t az aláírt munkamenetből, a Partner API-ban pedig az ellenőrzött API-kulcsból vagy az MI OAuth-kapcsolatából vezetjük le. A tulajdonos azonosítóját a rendszer sem az útvonalból, sem a lekérdezési paraméterekből, sem a kérés törzséből nem veszi át. Az API-kulcsokat ezen felül a jogosultsági kör (scope), az érvényességi idő és a csomag is korlátozza; a csatlakoztatott MI jogosultságkészletét a rendszer minden kérésnél a tulajdonos által választott szintből számítja ki.

Mielőtt bármit visszaadna vagy módosítana, a rendszer újra ellenőrzi, hogy a szerver, klaszter, inbound, útvonal, VPN-felhasználó vagy fizetés ehhez a fiókhoz tartozik-e. Az adatbázis-lekérdezések a partner_id-re vannak korlátozva, az összetett egyedi és idegen kulcsok pedig elutasítják az érvénytelen, partnerek közötti kapcsolódásokat. A tesztek jogosultsági mátrixa minden erőforrás-azonosítót fogadó végponthoz kifejezett IDOR-forgatókönyvet követel meg.

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

A végfelhasználó e-mail-címét nem tároljuk: a fiókneve visszafordíthatatlanul származtatott, és nem tartalmaz címet. A bejelentkezési kódot tartalmazó levelet mi küldjük, ezért a cím áthalad a küldési sorunkon, és közvetlenül a kiküldés után törlődik onnan — a visszatérő felhasználó felismeréséhez csak egy visszafordíthatatlan ujjlenyomat marad, amelyből a cím nem állítható helyre. Azt az egy esetet, amikor a cím mégis megmarad, kimondjuk: fizetéskor a fizetési webhookban érkezik, és korlátozott megőrzési idővel bekerül a fizetési naplóba.

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 az összes adatával együtt Ön maga törölheti a „Speciális beállítások” szakaszban, az e-mailben kapott kóddal megerősítve (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). Az OAuth-hozzájárulási oldalakon az analitika betöltése mindenképpen le van tiltva: az URL egy MI-csatlakoztatási kérés rövid élettartamú azonosítóját tartalmazza, amelyet nem szabad harmadik félnek átadni. Nincsenek más, harmadik féltől származó nyomkövetők: nincs Sentry, PostHog, Mixpanel vagy hirdetési pixel. A backendben nincs harmadik féltől származó telemetria, a végfelhasználói storefrontok pedig nem tartoznak analitika alá.

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 csatlakoztatott szolgáltató oldalán kezelik (lava.top). Csak ellenőrzött webhook-eseményt kapunk: a hitelességét az adott szolgáltató által támogatott módon állapítjuk meg, még mielőtt az egyenleg vagy a hozzáférés megváltozna. Nem kapjuk meg a teljes kártyaszámot (PAN) vagy a CVV-t. Ugyanazon esemény újbóli kézbesítése 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); az „egyáltalán semmit nem látunk a kártyáról” nem.

A fiókhoz tárolt adatok: e-mail-cím, utolsó bejelentkezés ideje, felületmód és beállítások; a számlázáshoz — egyenleg és Telegram, ha meg van adva a feltöltésekhez. A fiók védelme érdekében az aktív munkamenet tartalmazza a létrehozás és az utolsó aktivitás idejét, az IP-címet és a user-agentet. A sikeres és sikertelen bejelentkezési kísérletek előzményeit ugyanezekkel a technikai jellemzőkkel 90 napig őrizzük.

A panelen nincs általános kattintási előzmény. Külön célzott naplók léteznek: Partner API-kérések — legfeljebb az utolsó 500 bejegyzés és körülbelül 25 óra, az infrastruktúra eseményei és a diagnosztikai eredmények — legfeljebb 7 nap, a csatlakoztatott MI műveletei — a fiókkal együtt. Az MI-műveletek naplózása előtt a jelszavakat, tokeneket, kulcsokat és előfizetési linkeket eltávolítjuk, a felhasználók e-mail-címeit pedig maszkoljuk.

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 szerver generált admin jelszavára. A kódokat kriptográfiai generátor állítja elő; csak a HMAC-hashük tárolódik, az összehasonlítás pedig állandó idő alatt történik. A kód sikeres esetén azonnal törlődik, 5 hibás próbálkozás után pedig korán érvénytelenítjük. A kibocsátási gyakorisági korlátot mind a teljes cím, mind a tényleges postafiók szerint számoljuk: az IP-cím váltása, a Gmail-címekben lévő pontok és a plusz-címkék nem adnak külön keretet.

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.

Minden partner-munkamenetnek stabil szerveroldali azonosítója van, amely a token meghosszabbításakor is megmarad. A normál kijelentkezés a teljes aktuális munkamenetet visszavonja, nem csak a token egyetlen kiadását. A „Fiókmunkamenetek” szakaszban látható az eszköz, az IP-cím, a belépés ideje és az utolsó aktivitás; bármelyik munkamenet külön is lezárható. A „Kijelentkezés mindenhol” művelet minden munkamenetet lezár, és leválasztja a csatlakoztatott MI-alkalmazásokat.

A belépési előzményeket 90 napig őrizzük; ezek a sikeres belépéseket, a hibás és lejárt kódokat, valamint a próbálkozások számának túllépését mutatják. Ha jelek utalnak egy már lecserélt tokenkiadás ismételt felhasználására, a rendszer a munkamenetet lemásoltnak tekinti, lezár minden munkamenetet és MI-kapcsolatot, és értesítést küld a tulajdonosnak.

A böngésző local storage-ában nincsenek munkamenet-tokenek, csak felületi beállítások. A tokent a Next.js szerveroldali rétege helyezi a HttpOnly cookie-ba; a böngésző nem kapja meg a backend belső címét, és a Server Actions mechanizmuson keresztül éri el. A CORS nem engedi, hogy más originek olvassák a jogosultsághoz kötött adatokat tartalmazó API-válaszokat.

Vannak szándékos kivételek, amelyeket maga a tulajdonos irányít: a privát SSH-kulcs exportálása az e-mailben kapott kód után (SR-4), valamint az új Partner API-kulcs, amelynek teljes titka létrehozáskor egyszer megjelenik a böngészőben. Ezt követően a titok az adatbázisból nem állítható vissza — ott csak a hash marad. A nyilvános API-domain rendeltetésszerűen elérhető az internetről, de érvényes munkamenet, API-kulcs vagy OAuth-token nélkül nem ad vissza védett adatokat.

A CreateYourVPN nyilvános hosztjait HTTPS-en, HSTS-sel (max-age két év, includeSubDomains) szolgáljuk ki. Minden általunk üzemeltetett webes frontend — a platform oldala, a partnerpanel és a partnerek üzletei, akár a mi aldomainjeinken, akár a partner saját domainjén — és az API-domain ugyanazt a biztonsági fejléckészletet küldi: Content-Security-Policy (az API-n default-src 'none'; a frontendeken tiltja az iframe-be ágyazást, és rögzíti a base-uri és a form-action értékét), X-Content-Type-Options: nosniff, X-Frame-Options, valamint szigorúra húzott Referrer-Policy (az API-n no-referrer; a frontendeken strict-origin-when-cross-origin, amelyek korlátozó Permissions-Policy-t is küldenek).

Ez éles üzemben fut mindezeken a hosztokon, és függetlenül ellenőrizhető — bármely HTTP-fejléc-vizsgálóval vagy olyan szolgáltatással, mint az SSL Labs.

Az MI-alkalmazás OAuth-on keresztül csatlakozik, és nem kapja meg a paneled cookie-ját. A hozzájárulási oldalon három szint közül választasz: csak megtekintés; megtekintés és konfigurálás; törlés és hozzáférés kiosztása. A jogosultságokat a szerver minden hívásnál ellenőrzi. A kritikus törlésekhez egy további, e-mailben kapott egyszer használatos kód is szükséges, a teljes kapcsolat pedig visszavonható a „Csatlakoztatott MI” szakaszban.

Minden eszközhívás bekerül a tulajdonos számára látható naplóba, az eredménnyel és az argumentumok biztonságos másolatával együtt. A jelszavakat, tokeneket, API-kulcsokat, privát kulcsokat és előfizetési linkeket a naplózás előtt kivágjuk; a felhasználók e-mail-címeit maszkoljuk. A kiválasztott MI-alkalmazás ugyanakkor harmadik féltől származó szolgáltatás marad: azokat az adatokat, amelyek olvasását vagy módosítását tudatosan rábíztad, a szolgáltatójának szabályai szerint is kezelik.