Überprüfbare Aussagen.

Das Passwort wird nur benötigt, um die erste SSH-Verbindung zu öffnen und einen Dienstbenutzer einzurichten. Es wird als SSH-Authentifizierung für unsere Verbindung übergeben — nicht als Skript-Argument oder Umgebungsvariable. Unsere Datenbank hat kein Feld dafür; es gelangt nicht in die Ausführungsumgebungen der Skripte und wird nicht in Logs geschrieben (Verbindungsfehler enthalten nur die Adresse und den Port, niemals das Passwort). Im Speicher wird es nach der Nutzung (best-effort) gelöscht — das ist Verteidigung in der Tiefe, keine Garantie: Go kann Kopien des Werts bis zur Garbage Collection auf dem Heap behalten.

Ehrlicher Vorbehalt: Dies bleibt das Root-Passwort auf deinem Server. Nach der Installation deaktivieren wir die Anmeldung per Passwort und als Root über SSH, ändern aber das Passwort selbst nicht — ändere es selbst, wenn du möchtest. „Wir speichern es nicht“ ist wahr; „es ist kein Geheimnis mehr“ nicht.

PasswordAuthentication no, PermitRootLogin no, SSH auf einen nicht standardmäßigen Port verschoben (standardmäßig 12011), fail2ban aktiviert (eine einstündige Sperre nach 5 Fehlversuchen), Anmeldung nur per Schlüssel. Der öffentliche Schlüssel wird vor der Nutzung streng validiert: Zeilenumbrüche (Schutz gegen das Einschleusen zusätzlicher Schlüssel in authorized_keys) und syntaktisch ungültige Schlüssel werden abgelehnt.

Anti-Aussperrung: Port 22 wird erst geschlossen, wenn der Kernel (über ss) bestätigt, dass der neue SSH-Port tatsächlich lauscht; die Konfiguration wird mit sshd -t und die sudo-Regel mit visudo -cf geprüft, beide werden bei einem Fehler zurückgerollt.

Das Panel arbeitet nicht mit deinem Passwort, sondern mit einem separaten Schlüssel (ed25519), den es selbst erzeugt. Der private Teil liegt in der Datenbank, verschlüsselt mit AES-256-GCM. Der Verschlüsselungsschlüssel (KEK) wird getrennt von der Datenbank gespeichert — in einer Umgebungsvariable des Servers — und in der Produktion ist er verpflichtend (es gibt keinen unsicheren Standardwert: ohne KEK startet das Krypto-Subsystem schlicht nicht). Dieselbe Verschlüsselung schützt die schweren Geheimnisse in der Datenbank — das Marzban-Admin-Passwort/-Token/-JWT, Reality-Schlüssel, Schlüssel der Zahlungsanbieter, den Proxy-Anmeldedaten-Cache, die Backup-Konfiguration.

Die Verschlüsselung verbirgt die Daten nicht nur, sondern authentifiziert sie (GCM-Auth-Tag): Die Manipulation eines verschlüsselten Feldes wird bei der Entschlüsselung erkannt und abgelehnt. Jedes Feld wird mit einem frischen zufälligen Nonce verschlüsselt; der KEK-Wert gelangt niemals in die Logs — nur seine kurze ID.

Zu den Capability-Token: Der /sub-Abo-Token ist ein Inhaber-Geheimnis. Für die Suche speichern wir nur seinen SHA-256, während die Kopie, die zum erneuten Anzeigen eines bereits ausgegebenen Links nötig ist, als AES-GCM-Chiffretext aufbewahrt wird. Ältere Klartext-Einträge werden vor dem Start des HTTP-Servers fail-closed in das neue Format migriert. Der URL-Bezeichner des Zahlungs-Webhooks wird im Klartext gespeichert, authentifiziert ein Ereignis aber nicht für sich allein: Die Echtheit wird separat durch eine HMAC-Signatur geprüft.

Der Schlüssel wird nur auf dem Server, im Speicher, entschlüsselt; gewöhnliche APIs geben ihn niemals zurück. Der einzige Weg, ihn zu erhalten, ist eine bewusste Export-Funktion („nimm deinen Schlüssel“), geschützt durch die Anmeldung plus einen einmaligen E-Mail-Code (der Code wird nur als HMAC-Hash gespeichert, in konstanter Zeit verglichen, TTL 10 Minuten, 5 Versuche). Der Schlüssel kann also absichtlich abgerufen, aber nicht über eine normale Anfrage „geleakt“ werden.

Bevor sich der Zustand des Servers ändert und vor allen Netzwerkoperationen im Hintergrund werden die Felder mit dem Verwaltungsschlüssel synchron auf null gesetzt. Bestätigt die Datenbank die Löschung nicht, gibt die Operation einen Fehler zurück und kann wiederholt werden. Die Löschung bleibt „weich“: Die Zeile und die nicht geheimen Dienstdaten bleiben erhalten. Das bedeutet keine physische Löschung bereits erstellter Backups — ihr Lebenszyklus wird durch die Aufbewahrungsrichtlinie für Backups geregelt.

Auditierte Partner-Routen autorisieren anhand der partner_id, die der Server aus dem signierten Login-Token ableitet — nicht aus dem, was der Client im Pfad oder Body gesendet hat. Bevor irgendetwas zurückgegeben oder geändert wird, prüft das System erneut, dass der angefragte Server, Cluster, Inbound, die Route, der VPN-Nutzer oder die Zahlung zu deinem Konto gehören; die entsprechenden Datenbankabfragen sind auf deine partner_id beschränkt, und das Schema (zusammengesetzte Unique-Keys plus zusammengesetzte Fremdschlüssel) weist ungültige partnerübergreifende Verknüpfungen ab. Die Isolation ist mehrschichtig: Anwendung, erneute Prüfung im Usecase, ein partner_id-Filter und das Schema.

Ehrlicher Vorbehalt: Dies ist durch ein Code-Audit entlang des Anfragepfads verifiziert, nicht durch einen öffentlichen Penetrationstest — daher ist SR-16, wie der Rest, im Bug Bounty zur Widerlegung offen.

Um alles automatisch zu konfigurieren (Xray+Reality installieren, Konfiguration anwenden, Metriken lesen), hält das Panel vollen administrativen Zugang auf dem Server (Root-äquivalent, über einen Dienstbenutzer mit passwortlosem sudo). Das ist für die Verwaltung notwendig, und wir nennen es NICHT „eingeschränkt“.

Was das Risiko senkt: Geheimnisse werden dem Server nur über den stdin des Prozesses übergeben (nicht als Kommandozeilen-Argumente — sie sind in der Prozessliste nicht sichtbar); nach der Erstinstallation prüft jede Verwaltungsverbindung den gepinnten Host-Key des Servers — ein Server-Austausch „in der Mitte“ wird abgelehnt. Was du kontrollierst: Der Zugang beruht auf einem Schlüssel, den du jederzeit widerrufen kannst — indem du den Server löschst (der Schlüssel wird auf null gesetzt) oder einfach die VPS bei deinem Hoster löschst (dann verschwindet alles).

Die VPN-Konten selbst (VLESS/Reality) werden in Marzban auf deinem Master-Server erstellt und leben dort. Zentral speichern wir nur, was zum Ausstellen eines Abo-Links nötig ist: einen zufälligen Abo-Token und einen verschlüsselten Snapshot der Proxy-Anmeldedaten (ein Cache; die Quelle der Wahrheit ist dein Marzban). Wir haben keinerlei Verlauf von Datenverkehr, IP oder Nutzerbesuchen.

Hier ist eine ehrliche Liste, wo die E-Mail eines Endnutzers tatsächlich durch unsere zentrale Datenbank läuft: Die E-Mail mit dem Anmeldecode versenden wir, also läuft die Adresse durch unsere Sendewarteschlange (für jede Anmeldung im Storefront, einschließlich der kostenlosen); bei der Bezahlung trifft die E-Mail des Käufers im Zahlungs-Webhook ein und gelangt ins Zahlungsprotokoll; beim Verknüpfen von Telegram wird die E-Mail im Profil gespeichert. Das sind die einzigen Berührungspunkte — dienstlich und aus Notwendigkeit; keiner davon betrifft Traffic oder Nutzerverhalten.

Diese Dienstdaten bewahren wir nur so lange wie nötig auf und löschen sie automatisch: die E-Mail wird unmittelbar nach dem Versand aus der Sendewarteschlange entfernt, der Inhalt eines Zahlungsereignisses nach der Verarbeitung, und Ereignisse, die auf einen erneuten Versuch warten, innerhalb eines 90-Tage-Fensters. Sie können Ihr Konto samt den zugehörigen Daten löschen, indem Sie sich an den Support wenden (Einzelheiten siehe Risiko 7). Wir legen das offen dar, anstatt es hinter vagen Formulierungen zu verbergen.

Die CreateYourVPN-Plattform empfängt oder speichert keine Informationen darüber, welche Websites du oder deine Nutzer besuchen. Das Schema zur Metrik-Aufnahme ist geschlossen: Es hat physisch keine Felder für IPs, Domains oder Besuche — nur Aggregate (Anzahl eindeutiger Online-Nutzer, Gesamtbytes, CPU/RAM/Auslastung). Jeder Node authentifiziert sich mit einem HMAC-Token, das an seine eigene ID gebunden ist, und kann Metriken nur für sich selbst schreiben. Der Balancer auf dem Node (HAProxy) arbeitet als TCP-Router nach SNI und entschlüsselt den Datenverkehr nicht. Auf dem Server selbst werden Systemjournale höchstens etwa eine Stunde aufbewahrt und nicht an syslog weitergeleitet.

Über die Plattformebene hinaus führen auch die Server kein Besuchsjournal: Das Zugriffs-Logging von Xray wird bei jedem Konfigurations-Push zwangsweise deaktiviert (die Plattform setzt log.access auf none), sodass der Edge-Proxy nicht aufzeichnet, mit welchen Adressen sich Nutzer verbinden. Das ist im Code erzwungen und auf die gesamte Flotte ausgerollt.

Um zu verstehen, wie die Website und das Panel genutzt werden, setzen wir Google Analytics ein (das Cookie-Banner weist auf die Erfassung von Cookies und Statistiken hin; Details stehen in der Datenschutzerklärung). Es gibt keine anderen Drittanbieter-Tracker: kein Sentry, PostHog, Mixpanel oder Werbepixel (durch Durchsuchen beider Frontends verifiziert). Das Backend hat überhaupt keine Drittanbieter-Telemetrie. Die Storefront für Endnutzer ist gar nicht von Analytics abgedeckt — kein GA, keine Tracker (aus ihren Quellen überprüfbar).

Vorbehalt: GA erhält deine IP (auf Googles Seite) und die Adressen der aufgerufenen Panel-Seiten; die Panel-URLs enthalten nur einen Cluster-Bezeichner, keine E-Mail.

Die Zahlung und alle Kartendaten werden auf der Seite des Anbieters abgewickelt (Tribute / Lemon Squeezy). Wir erhalten nur einen signierten Webhook (HMAC-SHA256, Vergleich in konstanter Zeit, verifiziert, bevor der Body geparst wird und vor jedem Datenbankschreibvorgang: Ohne Kenntnis des Geheimnisses besteht ein Ereignis die Prüfung nicht). Wir erhalten nicht die vollständige Kartennummer (PAN) oder CVV. Eine erneute Zustellung desselben Webhooks (Wiederholungen des Anbieters) führt nicht zu einer doppelten Gewährung — Ereignisse werden dedupliziert.

Vorbehalt: Der Anbieter kann im Body des Webhooks Kartenmetadaten (Kartennetzwerk und letzte 4 Ziffern) sowie Namen und E-Mail des Zahlers enthalten. Der Original-Body wird vom Worker bis zum Abschluss der Verarbeitung benötigt; nach erfolgreicher Verarbeitung wird er zusammen mit dem E-Mail-Hinweis gelöscht. Ereignisse, die auf eine Wiederholung oder eine manuelle Prüfung warten, behalten den Original-Body nur bis zum Ende des Aufbewahrungsfensters (90 Tage ohne Aktivität), danach werden die Kartenmetadaten und die E-Mail des Zahlers automatisch gelöscht. „Es gibt keine vollständige Kartennummer“ ist wahr, aber das ist eine Eigenschaft der Anbieter (wir filtern den Body nicht selbst); „wir sehen überhaupt nichts von der Karte“ nicht.

E-Mail (für die Anmeldung nötig), Zeitpunkt der letzten Anmeldung, Oberflächenmodus; für die Abrechnung — Guthaben und Telegram (für Aufladungen). Die IP des Partners wird nicht in der Datenbank gespeichert, und wir führen keinen Klick- oder Aktionsverlauf im Panel (abgesehen von einem kurzen Zugriffslog bei Fehlern).

Die Firewall verweigert eingehenden Verkehr standardmäßig. Nach außen offen: 443 (VPN, Xray+Reality), SSH auf einem nicht standardmäßigen Port (standardmäßig 12011) und — auf dem Master-Server — der Port des Marzban-Admin-Panels, nur für Control-Plane-IPs. Port 80 wird separat nur im Let's Encrypt-Modus für HTTP-01 geöffnet. Port 22 wird nach dem Verschieben von SSH geschlossen.

Die Verwaltungsports des Nodes sind nur für die IP des Master-Servers offen, nicht nach außen (ein Fehlschlag dieser Bindung bricht die Installation ab). Wird die Firewall nicht aktiv, schlägt die Installation fehl. ICMP-Echo ist nur für IPv4 begrenzt; wir versprechen nicht, dass der Server „unsichtbar“ ist, und ICMP über IPv6 bleibt erhalten, damit IPv6 korrekt funktioniert.

Unattended Upgrades installieren Sicherheits-Paketupdates automatisch. Vorbehalt: Der automatische Neustart ist bewusst deaktiviert (damit ein ungeprüfter Kernel nicht von selbst neu startet) — das bedeutet, dass Korrekturen, die einen Neustart erfordern (Kernel, manchmal OpenSSH), erst nach einem manuellen oder geplanten Neustart wirksam werden. „Auto-Patching“ gilt für den Userland-Bereich, nicht für das, was einen Neustart erfordert.

Wir behaupten NICHT, dass der Server „unsichtbar“ oder „nicht scanbar“ ist. Port 443 ist offen und beantwortet eine TCP-Verbindung wie jeder Webserver. Die Eigenschaft „bei einer falschen Verbindung sieht er wie eine gewöhnliche, unzusammenhängende Website aus“ wird vom Reality-Protokoll innerhalb von Xray bereitgestellt — eine separate Komponente, die wir nicht zu einem Absolutum machen.

Die Partner-Anmeldung erfolgt per einmaligem 6-stelligen Code, der per E-Mail gesendet wird. Es gibt kein Kontopasswort. Das gilt nicht für interne Anmeldedaten verwalteter Komponenten, etwa das generierte Marzban-Admin-Passwort. Die Codes werden von einem kryptografischen Generator erzeugt; gespeichert wird nur ihr HMAC-Hash, und der Vergleich erfolgt in konstanter Zeit. Der Code ist einmalig nutzbar: Bei Erfolg wird er sofort gelöscht (kein Replay); nach 5 falschen Versuchen wird er vorzeitig gelöscht. Das Rate-Limit für die Ausgabe wird pro E-Mail gezählt, nicht pro IP — es lässt sich nicht durch Adresswechsel umgehen.

Der Sitzungs-Token liegt in einem HttpOnly- und Secure-Cookie (JS kann ihn nicht lesen), verifiziert auf dem Backend (nicht nur am Edge). Idle-Timeout und automatische Abmeldung bei Inaktivität sind auf dem Client implementiert, nicht auf dem Server. Der Token ist mit HS256 signiert; bei der Verifizierung lehnen wir jeden anderen Algorithmus (einschließlich „none“) strikt ab — der klassische Algorithmus-Austausch-Angriff geht nicht durch. Der Storefront-Token und der Partner-Panel-Token sind nach Audience getrennt: Ein Endnutzer-Token kann technisch die Partner-API nicht erreichen (und umgekehrt). Ein gelöschter Partner wird selbst mit einem gültigen Token abgelehnt.

Vorbehalt: Der Widerruf ist so umgesetzt, dass bei jeder Anfrage geprüft wird, ob der Partner existiert, nicht durch Invalidieren des Tokens selbst; die Abmeldung löscht das Cookie, aber ein ausgegebener Token bleibt bis zum Ablauf kryptografisch gültig (bis zu einer Stunde). Es gibt noch keine zentrale Widerrufsliste (eine bewusste MVP-Vereinfachung).

Es gibt keine Token im Local Storage des Browsers (nur UI-Einstellungen); keine Geheimnisse und nicht die API-Adresse gelangen in das Client-Bundle. Nur der Server (Next.js) legt den Token in ein HttpOnly-Cookie. Der Browser spricht nur über den Server (Server Actions) mit dem Kern: Das Frontend ruft die API nicht direkt aus dem Browser auf, und CORS erlaubt dem Browser nicht, API-Antworten von anderen Ursprüngen zu lesen.

Klarstellung anstelle eines früheren Absolutums: Die API-Domain selbst ist ein öffentlicher Host — technisch kannst du sie aus einem Browser öffnen, aber ohne Sitzung gibt sie keine autorisierten Daten zurück.

Die öffentlichen Domains von CreateYourVPN werden über HTTPS mit HSTS (max-age zwei Jahre, includeSubDomains) ausgeliefert. Sowohl das Web-Frontend als auch die API-Domain senden einen strengen Satz von Security-Headern: eine restriktive Content-Security-Policy, X-Content-Type-Options: nosniff, X-Frame-Options und eine abgeriegelte Referrer-Policy (no-referrer bei der API; strict-origin-when-cross-origin beim Frontend, das zudem eine restriktive Permissions-Policy sendet).

Das läuft produktiv auf beiden Domains und ist unabhängig überprüfbar — mit jedem HTTP-Header-Inspektor oder einem Dienst wie SSL Labs.