Afirmações verificáveis.

A palavra-passe só é necessária para abrir a primeira ligação SSH e instalar um utilizador de serviço. É passada como autenticação SSH da nossa ligação — não como argumento de script nem variável de ambiente. A nossa base de dados não tem um campo para ela; não entra nos ambientes de execução dos scripts e não é escrita nos registos (os erros de ligação contêm apenas o endereço e a porta, nunca a palavra-passe). Na memória é apagada (na medida do possível) após a utilização — isto é defesa em profundidade, não uma garantia: o Go pode manter cópias do valor na heap até à recolha de lixo.

Ressalva honesta: esta continua a ser a palavra-passe root do seu servidor. Após a instalação, desativamos o início de sessão por palavra-passe e como root através de SSH, mas não alteramos a própria palavra-passe — altere-a você mesmo, se assim o desejar. «Não a armazenamos» é verdade; «deixou de ser um segredo» não.

PasswordAuthentication no, PermitRootLogin no, SSH movido para uma porta não padrão (12011 por predefinição), fail2ban ativado (uma hora de bloqueio após 5 falhas), início de sessão apenas por chave. A chave pública é rigorosamente validada antes de ser usada: quebras de linha (proteção contra a introdução de chaves adicionais no authorized_keys) e chaves sintaticamente inválidas são rejeitadas.

Anti-bloqueio: a porta 22 não é fechada enquanto o kernel não confirmar (através de ss) que a nova porta SSH está efetivamente à escuta; a configuração é verificada com sshd -t e a regra de sudo com visudo -cf, ambas revertidas em caso de erro.

O painel não trabalha com a sua palavra-passe, mas com uma chave separada (ed25519) que gera por si próprio. A parte privada fica na base de dados encriptada com AES-256-GCM. A chave de encriptação (KEK) é armazenada separadamente da base de dados — numa variável de ambiente do servidor — e em produção é obrigatória (não existe uma predefinição insegura: sem uma KEK, o subsistema de criptografia simplesmente não arranca). A mesma encriptação protege os segredos sensíveis na base de dados — a palavra-passe/token/JWT de administrador do Marzban, as chaves Reality, as chaves dos fornecedores de pagamento, a cache de credenciais de proxy, a configuração de backup.

A encriptação não apenas oculta como autentica os dados (etiqueta de autenticação GCM): a adulteração de um campo encriptado é detetada na desencriptação e rejeitada. Cada campo é encriptado com um nonce aleatório novo; o valor da KEK nunca chega aos registos — apenas o seu id curto.

Sobre os tokens de capacidade: o token de subscrição /sub é um segredo bearer. Para a consulta armazenamos apenas o seu SHA-256, enquanto a cópia necessária para voltar a mostrar uma ligação já emitida é mantida como texto cifrado AES-GCM. Os registos mais antigos em texto simples são migrados para o novo formato, com falha segura, antes de o servidor HTTP arrancar. O identificador do URL do webhook de pagamento é armazenado em claro, mas não autentica por si só um evento: a autenticidade é verificada separadamente por uma assinatura HMAC.

Os segredos das chaves da API de parceiros são armazenados de forma irreversível: a chave completa é mostrada apenas uma vez, no momento da emissão, e na base de dados fica o hash SHA-256 da sua parte secreta. Os tokens de acesso e de atualização das IAs conectadas também não são armazenados em texto simples; a conexão está limitada ao nível de acesso escolhido e pode ser revogada pelo proprietário da conta.

A chave é desencriptada apenas no servidor, em memória; as APIs comuns nunca a devolvem. A única forma de a obter é uma função de exportação deliberada («levar a sua chave»), protegida pelo início de sessão mais um código de uso único enviado por email (o código é armazenado apenas como um hash HMAC, comparado em tempo constante, TTL de 10 minutos, 5 tentativas). Assim, a chave pode ser obtida intencionalmente, mas não «fugir» através de um pedido normal.

Antes de o estado do servidor mudar e antes de quaisquer operações de rede em segundo plano, os campos que contêm a chave de gestão são colocados a zero de forma síncrona. Se a base de dados não confirmar a limpeza, a operação devolve um erro e pode ser repetida. A eliminação continua a ser «suave»: a linha e os dados de serviço não secretos são preservados. Isto não significa a eliminação física dos backups já criados — o seu ciclo de vida é regido pela política de retenção de backups.

Nas rotas do painel, o partner_id é derivado da sessão assinada; na API de parceiros, de uma chave de API verificada ou de uma conexão OAuth de uma IA. O identificador do proprietário não é retirado do caminho, dos parâmetros de consulta nem do corpo do pedido. As chaves de API estão ainda limitadas por scope, prazo de validade e plano; numa IA conectada, o conjunto de permissões é calculado em cada pedido a partir do nível escolhido pelo proprietário.

Antes de devolver ou alterar seja o que for, o sistema volta a verificar que o servidor, cluster, inbound, rota, utilizador de VPN ou pagamento pertence a esta conta. As consultas à base de dados são limitadas pelo partner_id, e as chaves únicas e estrangeiras compostas rejeitam ligações inválidas entre parceiros. A matriz de autorização nos testes exige um cenário IDOR explícito para cada endpoint com identificador de recurso.

Ressalva honesta: isto é verificado por uma auditoria de código ao longo do percurso do pedido, não por um teste de penetração público — por isso o SR-16, como os restantes, está aberto a refutação no bug bounty.

Para configurar tudo automaticamente (instalar Xray+Reality, aplicar a configuração, ler métricas), o painel detém acesso administrativo total no servidor (equivalente a root, através de um utilizador de serviço com sudo sem palavra-passe). Isto é necessário para a gestão e NÃO lhe chamamos «limitado».

O que reduz o risco: os segredos são passados ao servidor apenas através do stdin do processo (não como argumentos de comando — não ficam visíveis na lista de processos); após a instalação inicial, cada ligação de gestão verifica a chave de anfitrião fixada do servidor — a troca de um servidor «a meio» é rejeitada. O que você controla: o acesso assenta numa chave que pode revogar a qualquer momento — eliminando o servidor (a chave é colocada a zero) ou simplesmente eliminando o VPS no seu fornecedor (e então tudo desaparece).

As próprias contas de VPN (VLESS/Reality) são criadas e vivem no Marzban no seu servidor principal. De forma centralizada, armazenamos apenas o necessário para emitir uma ligação de subscrição: um token de subscrição aleatório e um instantâneo encriptado das credenciais de proxy (uma cache; a fonte de verdade é o seu Marzban). Não temos histórico de tráfego, de IP nem de visitas dos utilizadores.

O endereço de e-mail de um utilizador final não fica guardado connosco: o nome da sua conta é derivado de forma irreversível e não contém qualquer endereço. O e-mail com o código de início de sessão é enviado por nós, pelo que o endereço passa pela nossa fila de envio e é removido dela logo após o envio — para reconhecer um utilizador que regressa fica apenas uma impressão irreversível, da qual não é possível recuperar o endereço. O único caso em que um endereço fica mesmo registado nomeamo-lo diretamente: no pagamento chega no webhook de pagamento e entra no registo de pagamentos com um prazo de conservação limitado.

Mantemos estes dados de serviço apenas durante o tempo necessário e apagamo-los automaticamente: o e-mail é removido da fila de envio logo após o envio, o corpo de um evento de pagamento após o processamento, e os eventos à espera de uma nova tentativa dentro de uma janela de 90 dias. Pode eliminar a sua conta com todos os respetivos dados de forma autónoma, na secção «Configurações avançadas», confirmando com um código recebido por e-mail (consulte o risco 7 para mais detalhes). Divulgamos isto abertamente em vez de o escondermos atrás de formulações vagas.

A plataforma CreateYourVPN não recebe nem armazena informação sobre que sites você ou os seus utilizadores visitam. O esquema de ingestão de métricas é fechado: fisicamente não tem campos para IPs, domínios ou visitas — apenas agregados (contagem de únicos online, total de bytes, CPU/RAM/carga). Cada nó autentica-se com um token HMAC associado ao seu próprio id e só pode escrever métricas para si próprio. O balanceador no nó (HAProxy) funciona como um encaminhador TCP por SNI e não desencripta o tráfego. No próprio servidor, os registos de sistema são retidos por não mais de cerca de uma hora e não são reencaminhados para o syslog.

Para além do nível da plataforma, os servidores também não mantêm um diário de visitas: o registo de acessos do Xray é forçosamente desativado em cada envio de configuração (a plataforma define log.access como none), pelo que o proxy de borda não regista a que endereços os utilizadores se ligam. Isto é imposto no código e implementado em toda a frota.

Para perceber como o site e o painel são usados, aplicamos o Google Analytics (o aviso de cookies alerta para a recolha de cookies e de estatísticas; os detalhes estão na Política de Privacidade). Nas páginas de consentimento OAuth, a análise não é carregada em caso algum: o URL contém um identificador de curta duração do pedido de conexão de uma IA, que não pode ser transmitido a terceiros. Não há outros rastreadores de terceiros: sem Sentry, PostHog, Mixpanel ou pixels publicitários. O backend não tem telemetria de terceiros, e as lojas dos utilizadores finais não são abrangidas pela análise.

Ressalva: o GA recebe o seu IP (do lado da Google) e os endereços das páginas do painel visualizadas; os URLs do painel contêm apenas um identificador de cluster, não um email.

O pagamento e todos os dados do cartão são tratados do lado do fornecedor conectado (lava.top). Recebemos apenas um evento de webhook verificado: a sua autenticidade é estabelecida pelo método que o fornecedor em causa suporta, antes de qualquer alteração ao saldo ou ao acesso. Não recebemos o número completo do cartão (PAN) nem o CVV. O reenvio do mesmo evento não provoca uma concessão em duplicado: os eventos são desduplicados.

Ressalva: o fornecedor pode incluir metadados do cartão (marca e últimos 4 dígitos) e o nome e email do pagador no corpo do webhook. O corpo original é necessário ao worker até à conclusão do processamento; após o processamento com sucesso, é eliminado juntamente com a dica de email. Os eventos que aguardam repetição ou revisão manual mantêm o corpo original apenas até ao fim da janela de retenção (90 dias sem atividade), após o que os metadados do cartão e o email do pagador são apagados automaticamente. «Não há número completo do cartão» é verdade, mas isso é uma propriedade dos fornecedores (não filtramos o corpo por nós próprios); «não vemos absolutamente nada sobre o cartão» não.

Para a conta são armazenados o email, a hora do último início de sessão, o modo da interface e as definições; para a faturação — o saldo e o Telegram, se tiver sido indicado para os carregamentos. Para proteger a conta, uma sessão ativa contém a hora de criação e da última atividade, o endereço IP e o user-agent. O histórico de tentativas de início de sessão bem-sucedidas e falhadas, com os mesmos atributos técnicos, é guardado durante 90 dias.

Não existe um histórico geral de cliques no painel. Existem, à parte, registos específicos: pedidos à API de parceiros — no máximo as últimas 500 entradas e cerca de 25 horas; eventos de infraestrutura e resultados de diagnóstico — no máximo 7 dias; ações das IAs conectadas — enquanto a conta existir. Antes do registo das ações da IA, as palavras-passe, os tokens, as chaves e as ligações de subscrição são removidos, e os emails dos utilizadores são mascarados.

A firewall nega o tráfego de entrada por predefinição. Aberto para o exterior: 443 (VPN, Xray+Reality), SSH numa porta não padrão (12011 por predefinição) e — no servidor principal — a porta do painel de administração do Marzban, apenas para os IPs do plano de controlo. A porta 80 é aberta separadamente apenas no modo Let's Encrypt para o HTTP-01. A porta 22 é fechada após o SSH ser movido.

As portas de gestão do nó estão abertas apenas ao IP do servidor principal, não para o exterior (uma falha desta associação aborta a instalação). Se a firewall não ficar ativa, a instalação falha. O eco ICMP é limitado apenas para IPv4; não prometemos que o servidor seja «invisível», e o ICMP IPv6 é preservado para que o IPv6 funcione corretamente.

As atualizações não assistidas instalam automaticamente as atualizações de pacotes de segurança. Ressalva: o reinício automático está deliberadamente desativado (para que um kernel não verificado não reinicie sozinho) — o que significa que as correções que exigem um reinício (kernel, por vezes o OpenSSH) só são aplicadas após um reinício manual ou agendado. A «aplicação automática de correções» é verdade para o espaço de utilizador, não para o que exige um reinício.

NÃO afirmamos que o servidor é «invisível» ou «impossível de analisar». A porta 443 está aberta e responde a uma ligação TCP como qualquer servidor web. A propriedade «numa ligação incorreta parece um site comum e sem relação» é fornecida pelo protocolo Reality dentro do Xray — um componente separado que não transformamos num absoluto.

O início de sessão do parceiro é feito por um código de 6 dígitos de uso único enviado por email. Não existe palavra-passe de conta. Isto não se aplica às credenciais internas dos componentes geridos, como a palavra-passe de administrador gerada para o servidor. Os códigos são gerados por um gerador criptográfico; apenas o seu hash HMAC é armazenado, e a comparação é feita em tempo constante. Em caso de sucesso, o código é eliminado imediatamente e, após 5 tentativas erradas, é anulado antecipadamente. O limite de taxa de emissão é contado tanto pelo endereço completo como pela caixa de correio física: mudar de IP, os pontos nos endereços Gmail e as etiquetas plus não dão origem a um limite separado.

O token de sessão fica num cookie HttpOnly e Secure (o JS não o consegue ler), verificado no backend (não apenas na periferia). O tempo limite de inatividade e o encerramento automático de sessão por inatividade são implementados no cliente, não no servidor. O token é assinado com HS256; na verificação rejeitamos rigorosamente qualquer outro algoritmo (incluindo «none») — o clássico ataque de troca de algoritmo não passa. O token da loja e o token do painel de parceiro estão separados por audiência: um token de utilizador final não pode tecnicamente alcançar a API de parceiro (e vice-versa). Um parceiro eliminado é rejeitado mesmo com um token válido.

Cada sessão de parceiro tem um identificador estável no servidor, que se mantém quando o token é renovado. O encerramento de sessão normal revoga toda a sessão atual, e não apenas uma emissão do token. Na secção «Sessões da conta» são visíveis o dispositivo, o endereço IP, a hora de início de sessão e a última atividade; qualquer sessão pode ser terminada individualmente. A ação «Encerrar sessão em todos os lugares» termina todas as sessões e desconecta as IAs conectadas.

O histórico de inícios de sessão é guardado durante 90 dias e mostra os inícios de sessão bem-sucedidos, os códigos errados e expirados, bem como o excesso de tentativas. Perante indícios de reutilização de uma emissão do token já trocada, o sistema considera a sessão copiada, termina todas as sessões e conexões de IA e envia uma notificação ao proprietário.

Não há tokens de sessão no armazenamento local do navegador, apenas definições de interface. O token no cookie HttpOnly é colocado pela camada de servidor do Next.js; o navegador não recebe o endereço interno do backend e acede a ele através de Server Actions. O CORS não permite que outras origens leiam respostas da API com dados autorizados.

Existem exceções intencionais, controladas pelo proprietário: a exportação da chave SSH privada após o código enviado por email (SR-4) e uma nova chave da API de parceiros, cujo segredo completo é mostrado no navegador uma única vez, no momento da criação. Depois disso, não é possível recuperá-lo a partir da base de dados — lá fica apenas o hash. O domínio público da API está acessível a partir da internet, como previsto, mas sem uma sessão válida, uma chave de API ou um token OAuth não devolve dados protegidos.

Os hosts públicos da CreateYourVPN são servidos por HTTPS com HSTS (max-age de dois anos, includeSubDomains). Todos os frontends web que hospedamos — o site da plataforma, o painel de parceiros e as lojas dos parceiros, seja nos nossos subdomínios, seja no domínio próprio do parceiro — e o domínio da API enviam o mesmo conjunto de cabeçalhos de segurança: uma Content-Security-Policy (default-src 'none' na API; nos frontends, proíbe a incorporação em iframe e fixa base-uri e form-action), X-Content-Type-Options: nosniff, X-Frame-Options e uma Referrer-Policy blindada (no-referrer na API; strict-origin-when-cross-origin nos frontends, que também enviam uma Permissions-Policy restritiva).

Isto está em produção em todos esses hosts e pode ser verificado de forma independente — com qualquer inspetor de cabeçalhos HTTP ou um serviço como o SSL Labs.

A aplicação de IA conecta-se através de OAuth e não recebe os cookies do seu painel. Na página de consentimento, escolhe um de três níveis: apenas visualização; visualização e configuração; eliminação e concessão de acesso. As permissões são verificadas pelo servidor em cada chamada. As eliminações críticas exigem um código adicional de uso único enviado por email, e toda a conexão pode ser revogada na secção «IAs conectadas».

Cada chamada de ferramenta entra num registo visível para o proprietário, com o resultado e uma cópia segura dos argumentos. Palavras-passe, tokens, chaves de API, chaves privadas e ligações de subscrição são removidos antes do registo; os emails dos utilizadores são mascarados. No entanto, a aplicação de IA escolhida continua a ser um serviço de terceiros: os dados que conscientemente lhe pediu para ler ou alterar são tratados também segundo as regras do respetivo fornecedor.