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

Die Geheimnisse von Partner-API-Schlüsseln werden unumkehrbar gespeichert: Der vollständige Schlüssel wird nur einmal bei der Ausstellung angezeigt, und in der Datenbank verbleibt der SHA-256 seines geheimen Teils. Auch Access- und Refresh-Tokens verbundener KI werden nicht im Klartext gespeichert; die Verbindung ist auf die gewählte Zugriffsstufe beschränkt und kann vom Kontoinhaber widerrufen werden.

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.

In den Routen des Panels wird die partner_id aus der signierten Sitzung abgeleitet, in der Partner-API aus einem geprüften API-Schlüssel oder einer geprüften OAuth-Verbindung einer KI. Der Bezeichner des Eigentümers wird nicht aus dem Pfad, den Query-Parametern oder dem Body der Anfrage übernommen. API-Schlüssel sind zusätzlich durch Scopes, Gültigkeitsdauer und Tarif beschränkt; bei einer verbundenen KI werden die Rechte bei jeder Anfrage aus der vom Kontoinhaber gewählten Stufe berechnet.

Bevor irgendetwas zurückgegeben oder geändert wird, prüft das System erneut, dass der Server, Cluster, Inbound, die Route, der VPN-Nutzer oder die Zahlung zu diesem Konto gehören. Datenbankabfragen sind auf die partner_id beschränkt, und zusammengesetzte Unique-Keys und Fremdschlüssel weisen ungültige partnerübergreifende Verknüpfungen ab. Die Autorisierungsmatrix in den Tests verlangt für jeden Endpunkt mit einem Ressourcenbezeichner ein explizites IDOR-Szenario.

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.

Die E-Mail-Adresse eines Endnutzers wird bei uns nicht gespeichert: Sein Kontoname wird unumkehrbar abgeleitet und enthält keine Adresse. Die E-Mail mit dem Anmeldecode versenden wir, daher läuft die Adresse durch unsere Sendewarteschlange und wird direkt nach dem Versand daraus entfernt — zum Wiedererkennen eines zurückkehrenden Nutzers bleibt nur ein unumkehrbarer Fingerabdruck, aus dem sich die Adresse nicht wiederherstellen lässt. Den einen Fall, in dem eine Adresse doch liegen bleibt, benennen wir direkt: Bei der Zahlung kommt sie im Zahlungs-Webhook an und landet mit begrenzter Aufbewahrungsfrist im Zahlungsprotokoll.

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. Ihr Konto samt allen zugehörigen Daten können Sie selbst im Bereich „Erweiterte Einstellungen“ löschen, bestätigt mit einem Code aus Ihrer E-Mail (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). Auf den OAuth-Zustimmungsseiten wird das Laden von Analytics zwangsweise unterbunden: Die URL enthält einen kurzlebigen Bezeichner der KI-Verbindungsanfrage, der nicht an Dritte weitergegeben werden darf. Es gibt keine anderen Drittanbieter-Tracker: kein Sentry, PostHog, Mixpanel oder Werbepixel. Das Backend hat keine Drittanbieter-Telemetrie, und die Storefronts für Endnutzer sind nicht von Analytics abgedeckt.

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 angebundenen Anbieters abgewickelt (lava.top). Wir erhalten nur ein verifiziertes Webhook-Ereignis: Seine Echtheit wird mit dem Verfahren festgestellt, das der jeweilige Anbieter unterstützt, bevor Guthaben oder Zugang geändert werden. Wir erhalten nicht die vollständige Kartennummer (PAN) oder CVV. Eine erneute Zustellung desselben Ereignisses 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.

Für das Konto werden E-Mail, Zeitpunkt der letzten Anmeldung, Oberflächenmodus und Einstellungen gespeichert; für die Abrechnung — Guthaben und Telegram, falls es für Aufladungen angegeben ist. Zum Schutz des Kontos enthält eine aktive Sitzung den Zeitpunkt der Erstellung und der letzten Aktivität, die IP-Adresse und den User-Agent. Der Verlauf erfolgreicher und fehlgeschlagener Anmeldeversuche mit denselben technischen Merkmalen wird 90 Tage aufbewahrt.

Einen allgemeinen Klickverlauf im Panel gibt es nicht. Separat existieren zweckgebundene Protokolle: Anfragen an die Partner-API — höchstens die letzten 500 Einträge und etwa 25 Stunden; Infrastrukturereignisse und Diagnoseergebnisse — höchstens 7 Tage; Aktionen verbundener KI — zusammen mit dem Konto. Vor der Aufzeichnung von KI-Aktionen werden Passwörter, Tokens, Schlüssel und Abo-Links entfernt, und E-Mail-Adressen von Nutzern werden maskiert.

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 Admin-Passwort des Servers. Die Codes werden von einem kryptografischen Generator erzeugt; gespeichert wird nur ihr HMAC-Hash, und der Vergleich erfolgt in konstanter Zeit. Bei Erfolg wird der Code sofort gelöscht, und nach 5 falschen Versuchen wird er vorzeitig gelöscht. Das Rate-Limit für die Ausgabe wird sowohl pro vollständiger Adresse als auch pro tatsächlichem Postfach gezählt: Ein IP-Wechsel, Punkte in Gmail-Adressen und Plus-Tags ergeben kein separates Limit.

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.

Jede Partnersitzung hat einen stabilen serverseitigen Bezeichner, der bei der Erneuerung des Tokens erhalten bleibt. Eine normale Abmeldung widerruft die gesamte aktuelle Sitzung und nicht nur eine einzelne Token-Ausgabe. Im Bereich „Kontositzungen“ sind Gerät, IP-Adresse, Anmeldezeitpunkt und letzte Aktivität zu sehen; jede Sitzung kann einzeln beendet werden. Die Aktion „Überall abmelden“ beendet alle Sitzungen und trennt verbundene KI-Dienste.

Der Anmeldeverlauf wird 90 Tage aufbewahrt und zeigt erfolgreiche Anmeldungen, falsche und abgelaufene Codes sowie Überschreitungen der zulässigen Versuchsanzahl. Gibt es Anzeichen dafür, dass eine bereits eingetauschte Token-Ausgabe erneut verwendet wird, stuft das System die Sitzung als kopiert ein, beendet alle Sitzungen und KI-Verbindungen und benachrichtigt den Kontoinhaber.

Im Local Storage des Browsers gibt es keine Sitzungs-Token, nur Einstellungen der Oberfläche. Den Token legt die Serverschicht von Next.js in ein HttpOnly-Cookie; der Browser erhält die interne Adresse des Backends nicht und spricht es über Server Actions an. CORS erlaubt anderen Origins nicht, API-Antworten mit autorisierten Daten zu lesen.

Es gibt bewusste Ausnahmen, die der Kontoinhaber selbst steuert: den Export des privaten SSH-Schlüssels nach Eingabe eines Codes aus der E-Mail (SR-4) und einen neuen Partner-API-Schlüssel, dessen vollständiges Geheimnis bei der Erstellung einmal im Browser angezeigt wird. Danach lässt sich das Geheimnis nicht aus der Datenbank wiederherstellen — dort bleibt nur ein Hash. Die öffentliche API-Domain ist bestimmungsgemäß aus dem Internet erreichbar, gibt aber ohne gültige Sitzung, API-Schlüssel oder OAuth-Token keine geschützten Daten zurück.

Die öffentlichen Hosts von CreateYourVPN werden über HTTPS mit HSTS (max-age zwei Jahre, includeSubDomains) ausgeliefert. Jedes Web-Frontend, das wir betreiben — die Plattform-Website, das Partner-Panel und die Storefronts der Partner, ob auf unseren Subdomains oder auf der eigenen Domain eines Partners —, sowie die API-Domain senden denselben Satz von Security-Headern: eine Content-Security-Policy (default-src 'none' bei der API; bei den Frontends verbietet sie das Einbetten in ein iframe und fixiert base-uri und form-action), X-Content-Type-Options: nosniff, X-Frame-Options und eine abgeriegelte Referrer-Policy (no-referrer bei der API; strict-origin-when-cross-origin bei den Frontends, die zudem eine restriktive Permissions-Policy senden).

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

Eine KI-App verbindet sich über OAuth und erhält keine Cookies Ihres Panels. Auf der Zustimmungsseite wählen Sie eine von drei Stufen: nur ansehen; ansehen und konfigurieren; löschen und Zugang gewähren. Die Rechte prüft der Server bei jedem Aufruf. Kritische Löschvorgänge erfordern zusätzlich einen Einmalcode aus einer E-Mail, und die gesamte Verbindung lässt sich im Bereich „Verbundene KI“ widerrufen.

Jeder Tool-Aufruf landet in einem für den Kontoinhaber sichtbaren Protokoll, mit dem Ergebnis und einer sicheren Kopie der Argumente. Passwörter, Tokens, API-Schlüssel, private Schlüssel und Abo-Links werden vor der Aufzeichnung entfernt; E-Mail-Adressen von Nutzern werden maskiert. Die gewählte KI-App bleibt dabei ein Drittanbieterdienst: Daten, die Sie ihr bewusst zum Lesen oder Ändern überlassen haben, werden auch nach den Regeln ihres Anbieters verarbeitet.