Seguridad & Transparencia técnica — SuperDMZ

Flujo del tráfico:

Cada nodo público es una máquina dedicada en una región (actualmente São Paulo, Virginia, Frankfurt y Tokio). Toda la comunicación cliente-nodo viaja por TLS 1.2/1.3.

• El contenido del request (URL, headers, body) existe en memoria RAM del nodo el tiempo necesario para reenviarlo a tu cliente (típicamente milisegundos).
• Ese contenido no se graba en disco, no se indexa, no se loguea en texto claro. Los logs de acceso (nginx) registran solo metadata operacional: timestamp, método HTTP, path, status, bytes de entrada/salida, tiempo de respuesta, IP de origen.
• Cookies, headers de autenticación (Authorization, Cookie) y body de POST nunca aparecen en logs.
• Tokens internos de SuperDMZ (que el cliente usa para autenticarse en el nodo) son enmascarados automáticamente antes de cualquier log.

Implicación honesta: técnicamente, un operador malicioso con root en el nodo podría interceptar el contenido en RAM mientras se reenvía. Esto aplica a cualquier servicio de túnel reverso con TLS terminado en el edge (ngrok, Cloudflare Tunnel, localtunnel). Para escenarios donde esto es inaceptable (PCI-DSS, datos médicos, secretos corporativos), recomendamos el modo TCP descrito abajo.

• SSH, RDP, MySQL y cualquier protocolo TCP que ya cargue su propia criptografía (incluyendo TLS hecho por tu propio servicio) llega al destino cifrado de punta a punta.
• SuperDMZ solo ve: puerto origen/destino, conteo de bytes, timestamps de inicio/fin de conexión.
• Es el modo recomendado para cualquier carga regulada (salud, financiero, secretos industriales) y para administradores de TI que necesitan acceso a máquinas internas sin entregar la llave en ningún punto.

• Body de request o response.
• Headers Authorization, Cookie, Set-Cookie, X-Auth-Token y variantes conocidas.
• Query strings sensibles (claves de API pasadas vía URL — desaconsejado, pero enmascaradas antes de log si están).
• Tokens internos de SuperDMZ intercambiados entre cliente y nodo (enmascarados vía filtro de log antes de llegar a cualquier archivo).
• Contenido de túneles TCP de cualquier tipo.

Logs de nginx con retención de 14 días. Logs de auditoría del panel (login, CRUD de túneles) con retención de 90 días. Detalles en la Política de Privacidad.

• SSH con autenticación por contraseña solo para usuario no privilegiado. Login root vía SSH deshabilitado en todos los nodos.
• Firewall (UFW) con whitelist mínima: 22/tcp (SSH), 80/tcp (redirect HTTP→HTTPS + Let's Encrypt), 443/tcp (HTTPS público + WebSocket de clientes).
• fail2ban con bans progresivos para intentos de fuerza bruta en SSH y panel admin.
• Actualizaciones de seguridad automáticas (unattended-upgrades).
• Resolver DNS fijado en 1.1.1.1 / 1.0.0.1 (Cloudflare) + 9.9.9.9 (Quad9). /etc/resolv.conf con flag chattr +i.
• Panel administrativo en path no obvio y protegido por rate-limit, 2FA, CSRF en cada POST e IP-ban automático.
• Secretos sensibles (clave Stripe, contraseña SMTP, token GoDaddy) cifrados en reposo en la BD con clave fuera del versionado.

El failover hoy es manual. Si un nodo queda offline, el procedimiento es reapuntar el registro A del nodo en Cloudflare a otra IP saludable (cambio de DNS con TTL 60s) — los clients reconectan automáticamente cuando el DNS se actualiza. Tiempo típico de detección + acción: 5 a 30 minutos, según el horario.

No vendemos SLA contractual. El plan Business incluye soporte prioritario (respuesta inicial en hasta 4h hábiles) — no incluye crédito garantizado por downtime. Prometer un SLA exige historial medido, y aún estamos recolectando esos datos antes de publicar un número que podamos defender. Misma postura que tomamos en auditorías externas: transparencia radical en lugar de vender promesas que no podemos cumplir.

Status público en tiempo real: superdmz.com/status — muestra el estado de cada nodo (online/offline) e incidentes recientes, con auto-actualización cada minuto.

En el roadmap de disponibilidad: failover automático vía health-check + reescritura de DNS por la API de Cloudflare; historial de uptime mes a mes en la página de status; publicación del SLA cuando tengamos 6 meses de datos consistentes.

• Contraseñas almacenadas como hash bcrypt con cost factor recomendado por la industria. Nunca en texto claro, ni siquiera en log de error.
• 2FA disponible hoy: código de 6 dígitos por email (opcional, por usuario).
• Roadmap cercano: 2FA via TOTP (Google Authenticator, Authy, Aegis) y Passkeys/WebAuthn — ver sección "Roadmap de seguridad" abajo.
• Cambio de email principal exige código en el nuevo + alerta en el antiguo con link de "bloquear cuenta ahora" (ventana de 7 días).
• Eliminación de cuenta con ventana de recuperación de 48h por link de email antes de la purga final.

• 2FA por TOTP (RFC 6238): setup con QR code, backup codes, email como fallback de recovery.
• Passkeys / WebAuthn: autenticación sin contraseña resistente a phishing, alineada con FIDO2.
• HTTPS passthrough (SNI routing): TLS sin terminación en el edge SuperDMZ (BYO certificate).
• Cliente open-source: código del cliente Go publicado para auditoría.
• Changelog público de seguridad: CVEs internos y fixes documentados en /changelog.
• Self-host completo de assets: eliminar dependencias CDN remanentes (fuentes, íconos, Tailwind) sirviendo todo desde nuestro dominio.

Sin SLA público por ahora. Esta sección se actualizará a medida que cada ítem entre en producción.

• Canal preferido: [email protected]
• Contacto técnico equivalente: [email protected]
• Contacto operacional: [email protected]
• Archivo estandarizado RFC 9116: /.well-known/security.txt

Lo que pedimos: no explotes más allá de lo necesario para confirmar la vulnerabilidad, no accedas a datos de otros usuarios, y danos una ventana razonable para corregir antes de divulgación pública. A cambio: respuesta inicial en hasta 5 días hábiles, crédito público (si lo deseas) y meses gratis de plan pago como agradecimiento — proporcional a la severidad.