Segurança & Transparência — SuperDMZ

O caminho do tráfego é:

Cada node público é uma máquina dedicada em uma região (atualmente São Paulo, Virgínia, Frankfurt e Tóquio). Toda comunicação cliente-node viaja por TLS 1.2/1.3.

• O conteúdo do request (URL, headers, body) existe em memória RAM no node pelo tempo necessário para ser encaminhado ao seu client (tipicamente milissegundos).
• Esse conteúdo não é gravado em disco, não é indexado, não é logado em texto claro. Os logs de acesso (nginx) registram apenas metadata operacional: timestamp, método HTTP, path, status, bytes de entrada e saída, tempo de resposta, IP de origem.
• Cookies, headers de autenticação (Authorization, Cookie) e body do POST nunca aparecem nos logs.
• Tokens internos do SuperDMZ (que o client usa pra autenticar no node) são mascarados automaticamente antes de qualquer log.

Implicação honesta: tecnicamente, um operador malicioso com root no node poderia interceptar o conteúdo em RAM enquanto ele está sendo encaminhado. Isso vale para qualquer serviço de túnel reverso com TLS terminado no edge (ngrok, Cloudflare Tunnel, localtunnel). Para cenários onde isso é inaceitável (PCI-DSS, dados médicos, segredos corporativos sensíveis), recomendamos o modo TCP descrito abaixo.

• SSH, RDP, MySQL e qualquer protocolo TCP que já carregue sua própria criptografia (incluindo TLS feito pelo seu próprio serviço) chega ao destino cifrado de ponta a ponta.
• O SuperDMZ vê apenas: porta de origem/destino, contagem de bytes, timestamp de início/fim da conexão.
• É o modo recomendado para qualquer carga regulada (saúde, financeiro, segredos industriais) e para administradores de TI que precisam acessar máquinas internas sem entregar a chave em nenhum ponto da cadeia.

• Body de request ou response.
• Headers Authorization, Cookie, Set-Cookie, X-Auth-Token e variantes conhecidas.
• Query strings sensíveis (chaves de API passadas via URL — embora desencorajado, são mascaradas antes de log).
• Tokens internos do SuperDMZ trocados entre client e node (mascarados via filtro de log antes de chegarem a qualquer arquivo).
• Conteúdo de túneis TCP de qualquer natureza.

Logs de nginx têm retenção de 14 dias. Logs de auditoria do painel (login, criar/editar/deletar túnel) têm retenção de 90 dias. Detalhes na Política de Privacidade.

• SSH com autenticação por senha apenas para usuário não-privilegiado. Login root via SSH desabilitado em todos os nodes.
• Firewall (UFW) com whitelist mínima: 22/tcp (SSH), 80/tcp (HTTP→HTTPS redirect + Let's Encrypt), 443/tcp (HTTPS público + WebSocket de clients).
• fail2ban com banimento progressivo para tentativas de força bruta em SSH e no painel admin.
• Atualizações de segurança automáticas (unattended-upgrades).
• Resolver DNS travado em 1.1.1.1 / 1.0.0.1 (Cloudflare) + 9.9.9.9 (Quad9). /etc/resolv.conf com flag chattr +i para resistir a sobrescrita por cloud-init.
• Painel administrativo em path não-óbvio e protegido por rate-limit, 2FA, CSRF token em todos os POSTs e IP-ban automático em sequência de tentativas falhas.
• Segredos sensíveis (chave Stripe, senha SMTP, token GoDaddy) cifrados em repouso no banco com chave fora do versionamento.

Failover hoje é manual. Se um node ficar offline, o procedimento é repointar o A record do node na Cloudflare para outro IP saudável (alteração de DNS com TTL 60s) — os clients reconectam automaticamente quando o DNS atualiza. Tempo típico de detecção + ação: 5 a 30 minutos, dependendo do horário.

Não vendemos SLA contratual. O plano Business inclui suporte prioritário (resposta inicial em até 4h em dia útil) — não inclui crédito de downtime garantido. Promessa de SLA exige histórico medido, e estamos coletando esses dados antes de publicar um número que possamos defender. Falamos sobre isso na seção de auditorias externas: preferimos transparência radical a vender promessa que não temos como cumprir.

Status público em tempo real: superdmz.com/status — mostra o estado de cada node (online/offline) e incidentes recentes, com auto-refresh a cada minuto.

No roadmap de disponibilidade: failover automático via health-check + reescrita de DNS pela API da Cloudflare; histórico de uptime mês a mês na página de status; publicação do SLA assim que tivermos 6 meses de dados consistentes.

• Senhas armazenadas como hash bcrypt com cost factor recomendado pela indústria. Nunca em texto claro, nem mesmo em log de erro.
• 2FA atualmente disponível: código de 6 dígitos por e-mail (opcional, por usuário).
• Roadmap próximo: 2FA via TOTP (Google Authenticator, Authy, Aegis) e Passkeys/WebAuthn — vide seção "Roadmap de segurança" abaixo.
• Alteração do e-mail principal exige código no novo e-mail + alerta no e-mail antigo com link de "bloquear conta agora" (janela de 7 dias).
• Exclusão de conta com janela de recuperação de 48h por link de e-mail antes da purga definitiva.

• 2FA por TOTP (RFC 6238): setup com QR code, backup codes, e-mail como fallback de recovery.
• Passkeys / WebAuthn: autenticação sem senha resistente a phishing, alinhada com FIDO2.
• HTTPS passthrough (SNI routing): permite TLS sem terminação no edge SuperDMZ (BYO certificate).
• Cliente open-source: código do client Go publicado para auditoria por quem rodar o binário dentro da própria rede.
• Changelog público de segurança: CVEs internos e fixes documentados em /changelog.
• Self-host completo de assets: remover dependências CDN remanescentes (fontes, ícones, Tailwind) servindo tudo do nosso domínio — alinhado com a política de zero rastreamento de terceiros.

Sem SLA público por enquanto. Esta seção será atualizada conforme cada item entrar em produção.

• Canal preferido: [email protected]
• Contato técnico equivalente: [email protected]
• Contato operacional: [email protected]
• Arquivo padronizado RFC 9116: /.well-known/security.txt

O que pedimos: não explore além do necessário para confirmar a vulnerabilidade, não acesse dados de outros usuários, e nos dê uma janela razoável para corrigir antes de divulgação pública. Em troca: resposta inicial em até 5 dias úteis, crédito público (se desejado) e meses gratuitos de plano pago como agradecimento — proporcional à severidade.