Verifieerbare beweringen.

Het wachtwoord is alleen nodig om de eerste SSH-verbinding te openen en een servicegebruiker te installeren. Het wordt doorgegeven als SSH-authenticatie voor onze verbinding — niet als scriptargument of omgevingsvariabele. Onze database heeft er geen veld voor; het komt niet in de omgeving van scriptuitvoeringen terecht en wordt niet naar logboeken geschreven (verbindingsfouten bevatten alleen het adres en de poort, nooit het wachtwoord). In het geheugen wordt het na gebruik gewist (naar beste vermogen) — dat is verdediging in de diepte, geen garantie: Go kan kopieën van de waarde op de heap bewaren tot de garbage collection.

Eerlijke kanttekening: dit blijft het root-wachtwoord op je server. Na de installatie schakelen we wachtwoord- en root-login via SSH uit, maar het wachtwoord zelf wijzigen we niet — wijzig het zelf als je dat wilt. 'We slaan het niet op' klopt; 'het is geen geheim meer' niet.

PasswordAuthentication no, PermitRootLogin no, SSH verplaatst naar een niet-standaardpoort (standaard 12011), fail2ban ingeschakeld (een ban van een uur na 5 mislukte pogingen), inloggen alleen met sleutel. De publieke sleutel wordt vóór gebruik streng gevalideerd: regeleindes (bescherming tegen het binnensmokkelen van extra sleutels in authorized_keys) en syntactisch ongeldige sleutels worden geweigerd.

Anti-uitsluiting: poort 22 wordt pas gesloten wanneer de kernel (via ss) bevestigt dat de nieuwe SSH-poort daadwerkelijk luistert; de configuratie wordt gecontroleerd met sshd -t en de sudo-regel met visudo -cf, beide worden bij een fout teruggedraaid.

Het paneel werkt niet met je wachtwoord, maar met een aparte sleutel (ed25519) die het zelf genereert. Het privégedeelte staat in de database, versleuteld met AES-256-GCM. De versleutelingssleutel (KEK) wordt gescheiden van de database bewaard — in een omgevingsvariabele van de server — en in productie is die verplicht (er is geen onveilige standaardwaarde: zonder KEK start het cryptosubsysteem simpelweg niet). Diezelfde versleuteling beschermt de zware geheimen in de database — het Marzban-adminwachtwoord/token/JWT, Reality-sleutels, sleutels van betaalproviders, de cache met proxygegevens, de back-upconfiguratie.

De versleuteling verbergt de gegevens niet alleen, maar authenticeert ze ook (GCM auth tag): geknoei met een versleuteld veld wordt bij het ontsleutelen gedetecteerd en geweigerd. Elk veld wordt versleuteld met een nieuwe willekeurige nonce; de KEK-waarde komt nooit in de logboeken terecht — alleen de korte id ervan.

Over capability-tokens: het /sub-abonnementstoken is een bearer-geheim. Voor het opzoeken bewaren we alleen de SHA-256 ervan, terwijl de kopie die nodig is om een reeds uitgegeven link opnieuw te tonen als AES-GCM-cijfertekst wordt bewaard. Oudere records in platte tekst worden naar het nieuwe formaat gemigreerd, fail-closed, voordat de HTTP-server start. De URL-identificator van de betaalwebhook wordt onversleuteld bewaard, maar authenticeert op zichzelf geen gebeurtenis: de echtheid wordt afzonderlijk geverifieerd met een HMAC-handtekening.

Geheimen van Partner-API-sleutels worden in onomkeerbare vorm opgeslagen: de volledige sleutel wordt slechts één keer getoond, bij het uitgeven, en in de database blijft alleen de SHA-256 van het geheime deel ervan over. Access- en refreshtokens van gekoppelde AI worden evenmin in platte tekst bewaard; een koppeling is beperkt tot het gekozen toegangsniveau en kan door de eigenaar van het account worden ingetrokken.

De sleutel wordt alleen op de server ontsleuteld, in het geheugen; gewone API's geven hem nooit terug. De enige manier om hem te verkrijgen is een bewuste exportfunctie ('neem je sleutel mee'), beschermd met inloggen plus een eenmalige e-mailcode (de code wordt alleen als HMAC-hash bewaard, in constante tijd vergeleken, TTL van 10 minuten, 5 pogingen). De sleutel kan dus bewust worden opgehaald, maar niet via een gewoon verzoek 'uitlekken'.

Voordat de status van de server verandert en vóór welke netwerkbewerkingen op de achtergrond dan ook, worden de velden met de beheersleutel synchroon op nul gezet. Als de database het wissen niet bevestigt, geeft de bewerking een fout en kan die opnieuw worden geprobeerd. De verwijdering blijft 'zacht': de rij en niet-geheime servicegegevens blijven behouden. Dit betekent geen fysieke verwijdering van reeds gemaakte back-ups — hun levenscyclus wordt bepaald door het bewaarbeleid voor back-ups.

In de routes van het paneel wordt partner_id afgeleid uit de ondertekende sessie, in de Partner API uit een geverifieerde API-sleutel of de OAuth-koppeling van een AI. De identificator van de eigenaar wordt niet uit het pad, de queryparameters of de body van het verzoek gehaald. API-sleutels worden bovendien begrensd door scope, geldigheidsduur en abonnement; bij een gekoppelde AI worden de rechten bij elk verzoek berekend op basis van het niveau dat de eigenaar heeft gekozen.

Voordat er iets wordt teruggegeven of gewijzigd, controleert het systeem opnieuw of de betreffende server, cluster, inbound, route, VPN-gebruiker of betaling bij dit account hoort. Databasequery's zijn afgebakend op partner_id, en samengestelde unieke sleutels en foreign keys weigeren ongeldige koppelingen tussen partners. De autorisatiematrix in de tests vereist een expliciet IDOR-scenario voor elk endpoint met een resource-identificator.

Eerlijke kanttekening: dit is geverifieerd met een code-audit over het volledige verzoekpad, niet met een openbare penetratietest — dus SR-16 staat, net als de rest, open voor weerlegging in de bug bounty.

Om alles automatisch te configureren (Xray+Reality installeren, configuratie toepassen, statistieken uitlezen) heeft het paneel volledige beheerderstoegang op de server (gelijkwaardig aan root, via een servicegebruiker met wachtwoordloze sudo). Dit is nodig voor het beheer, en we noemen het NIET 'beperkt'.

Wat het risico verkleint: geheimen worden alleen via de stdin van het proces aan de server doorgegeven (niet als opdrachtargumenten — ze zijn niet zichtbaar in de proceslijst); na de eerste installatie verifieert elke beheersverbinding de vastgezette host-sleutel van de server — een serverwissel 'in het midden' wordt geweigerd. Wat jij bepaalt: de toegang berust op een sleutel die je op elk moment kunt intrekken — door de server te verwijderen (de sleutel wordt op nul gezet) of gewoon de VPS bij je host te verwijderen (dan verdwijnt alles).

De VPN-accounts zelf (VLESS/Reality) worden aangemaakt en staan in Marzban op je master-server. Centraal bewaren we alleen wat nodig is om een abonnementslink uit te geven: een willekeurig abonnementstoken en een versleutelde momentopname van proxygegevens (een cache; de bron van waarheid is je Marzban). We hebben geen verkeer, IP-adressen of bezoekgeschiedenis van gebruikers.

Het e-mailadres van een eindgebruiker bewaren wij niet: zijn accountnaam wordt onomkeerbaar afgeleid en bevat geen adres. De e-mail met de inlogcode versturen wij, dus het adres gaat door onze verzendwachtrij en wordt daar direct na verzending uit verwijderd — om een terugkerende gebruiker te herkennen blijft alleen een onomkeerbare vingerafdruk over, waaruit het adres niet te herleiden is. Het ene geval waarin een adres wel blijft staan noemen we direct: bij betaling komt het binnen in de betaal-webhook en belandt het in het betaallogboek met een beperkte bewaartermijn.

Deze servicegegevens bewaren we alleen zolang als nodig en wissen we automatisch: het e-mailadres wordt direct na verzending uit de verzendwachtrij verwijderd, de inhoud van een betalingsgebeurtenis na verwerking, en gebeurtenissen die op een nieuwe poging wachten binnen een venster van 90 dagen. Je kunt je account met alle bijbehorende gegevens zelf verwijderen in het gedeelte ‘Geavanceerde instellingen’, na bevestiging met een code uit je e-mail (zie risico 7 voor details). We maken dit openlijk bekend in plaats van het te verbergen achter vage bewoordingen.

Het CreateYourVPN-platform ontvangt of bewaart geen informatie over welke sites jij of je gebruikers bezoeken. Het schema voor metrische invoer is gesloten: het heeft fysiek geen velden voor IP-adressen, domeinen of bezoeken — alleen aggregaten (aantal unieke online gebruikers, totaal aantal bytes, CPU/RAM/belasting). Elke node authenticeert met een HMAC-token dat aan de eigen id is gekoppeld en kan alleen metrieken voor zichzelf wegschrijven. De balancer op de node (HAProxy) werkt als een TCP-router op basis van SNI en ontsleutelt geen verkeer. Op de server zelf worden systeemjournalen niet langer dan ongeveer een uur bewaard en niet doorgestuurd naar syslog.

Buiten het platformniveau houden ook de servers geen bezoekjournaal bij: access logging van Xray wordt bij elke configuratiepush gedwongen uitgeschakeld (het platform zet log.access op none), zodat de edge proxy niet vastlegt met welke adressen gebruikers verbinding maken. Dit wordt in de code afgedwongen en is uitgerold naar de vloot.

Om te begrijpen hoe de site en het paneel worden gebruikt, zetten we Google Analytics in (de cookiebanner waarschuwt voor het verzamelen van cookies en statistieken; details staan in het Privacybeleid). Op de OAuth-toestemmingspagina's is analyse gedwongen uitgeschakeld: de URL bevat een kortlevende identificator van het verzoek om een AI te koppelen, en die mag niet aan derden worden doorgegeven. Er zijn geen andere trackers van derden: geen Sentry, PostHog, Mixpanel of advertentiepixels. De backend heeft geen telemetrie van derden, en de storefronts voor eindgebruikers vallen niet onder analyse.

Kanttekening: GA ontvangt je IP-adres (aan de kant van Google) en de adressen van de bekeken paneelpagina's; paneel-URL's bevatten alleen een clusteridentificator, geen e-mailadres.

De betaling en alle kaartgegevens worden afgehandeld aan de kant van de gekoppelde provider (lava.top). Wij ontvangen alleen een geverifieerde webhook-gebeurtenis: de echtheid ervan wordt vastgesteld op de manier die de betreffende provider ondersteunt, voordat het saldo of de toegang wordt gewijzigd. We ontvangen niet het volledige kaartnummer (PAN) of de CVV. Het opnieuw afleveren van dezelfde gebeurtenis leidt niet tot een dubbele toekenning: gebeurtenissen worden ontdubbeld.

Kanttekening: de provider kan in de body van de webhook kaartmetadata (merk en laatste 4 cijfers) en de naam en het e-mailadres van de betaler opnemen. De worker heeft de oorspronkelijke body nodig totdat de verwerking klaar is; na een geslaagde verwerking wordt die samen met de e-mailhint verwijderd. Gebeurtenissen die wachten op een nieuwe poging of handmatige beoordeling behouden de oorspronkelijke body alleen tot het einde van het bewaarvenster (90 dagen zonder activiteit), waarna de kaartmetadata en het e-mailadres van de betaler automatisch worden gewist. ‘Er is geen volledig kaartnummer’ klopt, maar dat is een eigenschap van de providers (we filteren de body niet zelf); ‘we zien helemaal niets over de kaart’ niet.

Voor het account worden het e-mailadres, het tijdstip van de laatste login, de interfacemodus en de instellingen bewaard; voor facturering het saldo en Telegram, als dat voor bijstortingen is opgegeven. Ter bescherming van het account bevat een actieve sessie het tijdstip van aanmaak en van de laatste activiteit, het IP-adres en de user-agent. De geschiedenis van geslaagde en mislukte inlogpogingen met dezelfde technische kenmerken wordt 90 dagen bewaard.

Een algemene klikgeschiedenis van het paneel is er niet. Daarnaast bestaan er doelgebonden logboeken: verzoeken aan de Partner API (hoogstens de laatste 500 records en ongeveer 25 uur), infrastructuurgebeurtenissen en diagnoseresultaten (hoogstens 7 dagen) en acties van gekoppelde AI (zolang het account bestaat). Voordat AI-acties worden vastgelegd, worden wachtwoorden, tokens, sleutels en abonnementslinks verwijderd en worden e-mailadressen van gebruikers gemaskeerd.

De firewall weigert inkomend verkeer standaard. Naar buiten open: 443 (VPN, Xray+Reality), SSH op een niet-standaardpoort (standaard 12011) en — op de master-server — de poort van het Marzban-adminpaneel, alleen voor control-plane-IP's. Poort 80 wordt apart alleen geopend in de Let's Encrypt-modus voor HTTP-01. Poort 22 wordt gesloten nadat SSH is verplaatst.

De beheerpoorten van de node zijn alleen open voor het IP-adres van de master-server, niet naar buiten (een mislukking van deze koppeling breekt de installatie af). Als de firewall niet actief wordt, mislukt de installatie. ICMP-echo is alleen beperkt voor IPv4; we beloven niet dat de server 'onzichtbaar' is, en ICMP voor IPv6 blijft behouden zodat IPv6 correct werkt.

Unattended upgrades installeren updates van beveiligingspakketten automatisch. Kanttekening: automatisch opnieuw opstarten is bewust uitgeschakeld (zodat een niet-geverifieerde kernel niet vanzelf herstart) — dat betekent dat fixes die een herstart vereisen (kernel, soms OpenSSH) pas van kracht worden na een handmatige of geplande herstart. 'Automatisch patchen' klopt voor de userland, niet voor wat een herstart vereist.

We beweren NIET dat de server 'onzichtbaar' is of 'niet gescand kan worden'. Poort 443 is open en beantwoordt een TCP-verbinding zoals elke webserver. De eigenschap 'bij een onjuiste verbinding lijkt het op een gewone, niet-gerelateerde website' wordt geleverd door het Reality-protocol binnen Xray — een apart onderdeel dat we niet tot een absolute waarheid verheffen.

Partners loggen in met een eenmalige 6-cijferige code die per e-mail wordt verstuurd. Er is geen accountwachtwoord. Dit geldt niet voor interne inloggegevens van beheerde componenten, zoals het gegenereerde adminwachtwoord van de server. Codes worden gegenereerd door een cryptografische generator; alleen hun HMAC-hash wordt bewaard en de vergelijking gebeurt in constante tijd. Bij succes wordt de code onmiddellijk verwijderd, en na 5 foute pogingen wordt hij vroegtijdig uitgeschakeld. De frequentielimiet voor uitgifte wordt zowel per volledig adres als per fysieke mailbox geteld: wisselen van IP-adres, punten in Gmail-adressen en plus-tags leveren geen aparte limiet op.

Het sessietoken zit in een HttpOnly- en Secure-cookie (JS kan het niet lezen) en wordt op de backend geverifieerd (niet alleen aan de edge). Time-out bij inactiviteit en automatisch uitloggen bij inactiviteit zijn op de client geïmplementeerd, niet op de server. Het token is ondertekend met HS256; bij de verificatie weigeren we strikt elk ander algoritme (waaronder ‘none’) — de klassieke aanval waarbij het algoritme wordt verwisseld, komt er niet doorheen. Het storefront-token en het token van het partnerpaneel zijn gescheiden op basis van audience: een token van een eindgebruiker kan technisch de partner-API niet bereiken (en omgekeerd). Een verwijderde partner wordt geweigerd, zelfs met een geldig token.

Elke partnersessie heeft een stabiele identificator aan de serverkant die behouden blijft wanneer het token wordt verlengd. Normaal uitloggen trekt de volledige huidige sessie in, niet slechts één uitgegeven token. In het gedeelte ‘Accountsessies’ zijn het apparaat, het IP-adres, het aanmeldtijdstip en de laatste activiteit te zien; elke sessie kan afzonderlijk worden beëindigd. De actie ‘Overal uitloggen’ beëindigt alle sessies en verbreekt de AI-koppelingen.

De aanmeldgeschiedenis wordt 90 dagen bewaard en toont geslaagde aanmeldingen, verkeerde en verlopen codes en gevallen van te veel pogingen. Bij aanwijzingen dat een al ingewisseld token opnieuw wordt gebruikt, beschouwt het systeem de sessie als gekopieerd, beëindigt het alle sessies en AI-koppelingen en stuurt het de eigenaar een melding.

Er staan geen sessietokens in de local storage van de browser, alleen interface-instellingen. Het token wordt door de serverlaag van Next.js in een HttpOnly-cookie geplaatst; de browser krijgt het interne adres van de backend niet en spreekt de backend aan via Server Actions. CORS staat niet toe dat andere origins API-antwoorden met geautoriseerde gegevens lezen.

Er zijn bewuste uitzonderingen die de eigenaar zelf in de hand heeft: de export van de SSH-privésleutel na een code uit een e-mail (SR-4) en een nieuwe Partner-API-sleutel, waarvan het volledige geheim bij het aanmaken één keer in de browser wordt getoond. Daarna is het niet meer uit de database te herstellen — daar blijft alleen een hash over. Het openbare API-domein is zoals bedoeld bereikbaar vanaf het internet, maar geeft zonder geldige sessie, API-sleutel of OAuth-token geen beschermde gegevens terug.

De publieke hosts van CreateYourVPN worden via HTTPS met HSTS (max-age twee jaar, includeSubDomains) uitgeleverd. Elke webfrontend die wij hosten — de platformsite, het partnerpaneel en de storefronts van partners, zowel op onze subdomeinen als op het eigen domein van een partner — en het API-domein sturen dezelfde set beveiligingsheaders: een Content-Security-Policy (default-src 'none' op de API; op de frontends verbiedt die het insluiten in een iframe en zet base-uri en form-action vast), X-Content-Type-Options: nosniff, X-Frame-Options en een dichtgetimmerde Referrer-Policy (no-referrer op de API; strict-origin-when-cross-origin op de frontends, die ook een restrictieve Permissions-Policy sturen).

Dit draait in productie op al deze hosts en is onafhankelijk te controleren — met elke HTTP-headerinspector of een dienst als SSL Labs.

Een AI-app wordt via OAuth gekoppeld en krijgt de cookie van je paneel niet. Op de toestemmingspagina kies je een van drie niveaus: alleen bekijken; bekijken en configureren; verwijderen en toegang geven. De server controleert de rechten bij elke aanroep. Kritieke verwijderingen vereisen een extra eenmalige code uit een e-mail, en de hele koppeling kan worden ingetrokken in het gedeelte ‘Gekoppelde AI’.

Elke aanroep van een tool komt terecht in een logboek dat de eigenaar kan inzien, met het resultaat en een veilige kopie van de argumenten. Wachtwoorden, tokens, API-sleutels, privésleutels en abonnementslinks worden vóór het vastleggen verwijderd; e-mailadressen van gebruikers worden gemaskeerd. Tegelijk blijft de gekozen AI-app een dienst van derden: gegevens die je de app bewust hebt opgedragen te lezen of te wijzigen, worden ook verwerkt volgens de regels van de aanbieder van die app.