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.

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.

As rotas de parceiro auditadas autorizam por partner_id, que o servidor deriva do token de início de sessão assinado — não do que o cliente enviou no caminho ou no corpo. 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 solicitado pertence à sua conta; as consultas correspondentes à base de dados são limitadas pelo seu partner_id, e o esquema (chaves únicas compostas mais chaves estrangeiras compostas) rejeita ligações inválidas entre parceiros. O isolamento é feito em camadas: aplicação, nova verificação na usecase, um filtro por partner_id e o esquema.

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.

Aqui está uma lista honesta de onde o e-mail de um utilizador final passa efetivamente pela nossa base de dados central: 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 (para qualquer início de sessão na loja, incluindo o gratuito); no pagamento, o e-mail do comprador chega no webhook de pagamento e entra no registo de pagamentos; ao associar o Telegram, o e-mail é guardado no perfil. Estes são os únicos pontos de contacto — funcionais e por necessidade; nenhum deles envolve tráfego ou comportamento do utilizador.

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 juntamente com os dados associados contactando o suporte (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). Não há outros rastreadores de terceiros: sem Sentry, PostHog, Mixpanel ou pixels publicitários (verificado através da pesquisa em ambos os frontends). O backend não tem qualquer telemetria de terceiros. A loja do utilizador final não é abrangida por qualquer análise — sem GA, sem rastreadores (verificável a partir do seu código-fonte).

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 (Tribute / Lemon Squeezy). Recebemos apenas um webhook assinado (HMAC-SHA256, comparação em tempo constante, verificado antes de o corpo ser analisado e antes de qualquer escrita na base de dados: sem conhecer o segredo, um evento falha a verificação). Não recebemos o número completo do cartão (PAN) nem o CVV. O reenvio do mesmo webhook (repetições do fornecedor) 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.

O email (necessário para o início de sessão), a hora do último início de sessão, o modo da interface; para a faturação — o saldo e o Telegram (para os carregamentos). O IP do parceiro não é armazenado na base de dados, e não guardamos qualquer histórico de cliques ou ações no painel (à parte um breve registo de acesso em caso de erro).

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 do Marzban gerada. 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. O código é de uso único: em caso de sucesso é eliminado imediatamente (sem repetição); após 5 tentativas erradas é anulado antecipadamente. O limite de taxa de emissão é contado por email, não por IP — não pode ser contornado alternando endereços.

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.

Ressalva: a revogação é implementada verificando que o parceiro existe em cada pedido, não invalidando o próprio token; o encerramento de sessão elimina o cookie, mas um token emitido permanece criptograficamente válido até expirar (até uma hora). Ainda não existe uma lista de revogação centralizada (uma simplificação consciente de MVP).

Não há tokens no armazenamento local do navegador (apenas definições de interface); nenhum segredo nem o endereço da API vão parar ao pacote do cliente. Apenas o servidor (Next.js) coloca o token num cookie HttpOnly. O navegador comunica com o núcleo apenas através do servidor (Server Actions): o frontend não chama a API diretamente a partir do navegador, e o CORS não permite leituras, pelo navegador, das respostas da API a partir de outras origens.

Esclarecimento em vez de um antigo absoluto: o próprio domínio da API é um anfitrião público — tecnicamente pode abri-lo a partir de um navegador, mas sem uma sessão não devolve quaisquer dados autorizados.

Os domínios públicos da CreateYourVPN são servidos por HTTPS com HSTS (max-age de dois anos, includeSubDomains). Tanto o frontend web como o domínio da API enviam um conjunto rigoroso de cabeçalhos de segurança: uma Content-Security-Policy restritiva, X-Content-Type-Options: nosniff, X-Frame-Options e uma Referrer-Policy blindada (no-referrer na API; strict-origin-when-cross-origin no frontend, que envia também uma Permissions-Policy restritiva).

Isto está em produção em ambos os domínios e é verificável de forma independente — com qualquer inspetor de cabeçalhos HTTP ou um serviço como o SSL Labs.