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.

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.

Geauditeerde partnerroutes autoriseren op basis van partner_id, die de server afleidt uit het ondertekende logintoken — niet uit wat de client in het pad of de body meestuurde. Voordat er iets wordt teruggegeven of gewijzigd, controleert het systeem opnieuw of de opgevraagde server, cluster, inbound, route, VPN-gebruiker of betaling bij je account hoort; de bijbehorende databasequery's zijn afgebakend op je partner_id, en het schema (samengestelde unieke sleutels plus samengestelde foreign keys) weigert ongeldige koppelingen tussen partners. De isolatie is gelaagd: applicatie, hercontrole in de usecase, een partner_id-filter en het schema.

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.

Hier is een eerlijke lijst van waar het e-mailadres van een eindgebruiker wél door onze centrale database gaat: de e-mail met de aanmeldcode versturen wij, dus het adres gaat door onze verzendwachtrij (voor elke aanmelding bij de winkel, inclusief de gratis); bij betaling komt het e-mailadres van de koper binnen in de betalings-webhook en belandt het in het betalingslogboek; bij het koppelen van Telegram wordt het e-mailadres in het profiel opgeslagen. Dit zijn de enige raakpunten — functioneel en uit noodzaak; geen ervan betreft verkeer of gebruikersgedrag.

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 samen met de bijbehorende gegevens verwijderen door contact op te nemen met de ondersteuning (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). Er zijn geen andere trackers van derden: geen Sentry, PostHog, Mixpanel of advertentiepixels (geverifieerd door beide frontends te doorzoeken). De backend heeft helemaal geen telemetrie van derden. De storefront voor eindgebruikers valt helemaal niet onder analyse — geen GA, geen trackers (te verifiëren in de broncode ervan).

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 aan de kant van de provider afgehandeld (Tribute / Lemon Squeezy). Wij ontvangen alleen een ondertekende webhook (HMAC-SHA256, vergelijking in constante tijd, geverifieerd voordat de body wordt geparseerd en vóór welke databaseschrijfactie dan ook: zonder het geheim te kennen, doorstaat een gebeurtenis de verificatie niet). We ontvangen niet het volledige kaartnummer (PAN) of de CVV. Het opnieuw afleveren van dezelfde webhook (nieuwe pogingen van de provider) 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.

E-mailadres (nodig om in te loggen), tijdstip van laatste login, interfacemodus; voor facturering — saldo en Telegram (voor bijstortingen). Het IP-adres van de partner wordt niet in de database bewaard, en we houden geen klik- of actiegeschiedenis bij in het paneel (afgezien van een kort toegangslogboek bij fouten).

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 Marzban-adminwachtwoord. Codes worden gegenereerd door een cryptografische generator; alleen hun HMAC-hash wordt bewaard en de vergelijking gebeurt in constante tijd. De code is voor eenmalig gebruik: bij succes wordt hij onmiddellijk verwijderd (geen replay); na 5 foute pogingen wordt hij vroegtijdig uitgeschakeld. De frequentielimiet voor uitgifte wordt per e-mailadres geteld, niet per IP — hij kan niet worden omzeild door van adres te wisselen.

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.

Kanttekening: intrekking is geïmplementeerd door bij elk verzoek te controleren of de partner bestaat, niet door het token zelf ongeldig te maken; uitloggen verwijdert de cookie, maar een uitgegeven token blijft cryptografisch geldig tot het verloopt (tot een uur). Er is nog geen centrale intrekkingslijst (een bewuste MVP-vereenvoudiging).

Er staan geen tokens in de local storage van de browser (alleen UI-instellingen); geen geheimen of het API-adres belanden in de clientbundel. Alleen de server (Next.js) plaatst het token in een HttpOnly-cookie. De browser praat alleen via de server met de kern (Server Actions): de frontend roept de API niet rechtstreeks vanuit de browser aan, en CORS staat niet toe dat de browser API-antwoorden van andere origins leest.

Verduidelijking in plaats van een eerdere absolute uitspraak: het API-domein zelf is een openbare host — technisch kun je het vanuit een browser openen, maar zonder sessie geeft het geen geautoriseerde gegevens terug.

De publieke domeinen van CreateYourVPN worden via HTTPS met HSTS (max-age twee jaar, includeSubDomains) aangeboden. Zowel de webfrontend als het API-domein sturen een strikte set beveiligingsheaders: een restrictieve Content-Security-Policy, X-Content-Type-Options: nosniff, X-Frame-Options en een vergrendelde Referrer-Policy (no-referrer op de API; strict-origin-when-cross-origin op de frontend, die ook een restrictieve Permissions-Policy stuurt).

Dit draait in productie op beide domeinen en is onafhankelijk te controleren — met elke HTTP-headerinspecteur of een dienst zoals SSL Labs.