Dominios y Seguridad — Cloudflare
Dominios y Seguridad — Cloudflare
En una frase: Edu tiene 3 dominios en Cloudflare. Esta página explica para qué sirve cada uno y qué medidas de seguridad están activas. Si trabajas con la web del cliente o ves algo raro, mira aquí primero.
Última actualización: 12-05-2026 (sesión 57, tras hardening completo de los 3 dominios) Versión técnica: [[workspace-tech—tecnico—cloudflare-security]] (con detalles y comandos para Edu/Dani)
Los 3 dominios
| Dominio | Para qué sirve | Estado |
|---|---|---|
| crearack.com | La app principal CreaRack Pro que ven los clientes (dashboard, biblioteca, etc.). Está hospedada en Hetzner. | Producción activa |
| channelassistance.com | App secundaria de Edu hospedada en PythonAnywhere. Tiene sus propios usuarios. | Producción activa |
| esfericlabs.com | El nuevo dominio que usaremos como landing page comercial del SaaS CreaRack. Ahora mismo está aparcado — sin contenido — pero ya protegido para cuando se despliegue. | Parked (futura landing) |
Todos están en Cloudflare Registrar (mismo proveedor de DNS y dominio), así que cualquier cambio de seguridad se aplica de forma inmediata sin tener que ir a otra empresa.
Qué medidas de seguridad están activas
No hace falta entender el detalle técnico, pero sí saber que los 3 dominios están protegidos con un nivel comparable a cualquier banco o servicio profesional. Lo importante:
Todo navega cifrado siempre
- HTTPS obligatorio en los 3 dominios. Si alguien intenta entrar por HTTP (sin cifrado), Cloudflare le redirige automáticamente a HTTPS.
- HSTS activado — el navegador del visitante recuerda que la web es HTTPS-only durante 1 año. Imposible que un atacante “engañe” al navegador para forzar HTTP.
- Cifrado moderno — los protocolos antiguos (TLS 1.0/1.1, vulnerables) están bloqueados. Solo TLS 1.2 y 1.3.
Bots maliciosos bloqueados
- Block AI bots: los scrapers de OpenAI, Anthropic, Perplexity y otros buscadores IA están bloqueados en los 3 dominios. No queremos que entrenen modelos con nuestro contenido sin permiso.
- DNSSEC habilitado en los 3 — esto protege contra ataques que “envenenan” el DNS para redirigir a los visitantes a webs falsas.
Quién puede entrar a las zonas privadas
Algunas partes del workspace (la Biblioteca, las APIs internas) ya no son accesibles libremente desde internet. Para entrar hay que:
- Estar autenticado como Edu, Dani o Txell (login con email validado), o
- Ser un sistema autorizado (los crones de Claude, los workflows de GitHub) que llevan una “llave maestra” compartida (Service Token).
Esto es lo que cerramos en la sesión 57 — antes era posible que cualquier máquina pudiera contactar con esos endpoints; ahora solo entran los que tienen permiso explícito.
Decisiones que conviene conocer
“Bot Fight Mode” está desactivado en crearack.com (intencional)
Cloudflare ofrece una protección anti-bots agresiva llamada Bot Fight Mode. Lo intentamos activar en s57 y rompió un sistema interno: el Bibliotecario (sistema que mantiene actualizada la wiki) hace llamadas automáticas a la web cada hora, y Cloudflare las tomaba por bots maliciosos y las bloqueaba.
Decisión: lo desactivamos en crearack.com y channelassistance.com. En esfericlabs.com (la futura landing) sí está activado, porque allí no hay crones automáticos. Cuando la landing tenga formularios de contacto, hay que revisar esto.
channelassistance.com tenía “Security Level Off”
En la auditoría posterior a s57 descubrimos que channelassistance.com tenía la protección contra ataques en “Essentially Off” (prácticamente desactivada). Lo corregimos a “Medium” — el valor recomendado por Cloudflare. Ahora Cloudflare desafía automáticamente a IPs con mala reputación antes de dejarlas entrar a la app.
esfericlabs.com endurecido aunque esté parked
Aunque el dominio aún no tiene contenido, lo dejamos blindado:
- HTTPS obligatorio, HSTS, cifrado moderno
- Block AI bots y Bot Fight Mode activos
- SSL “Full Strict” (el nivel más seguro)
¿Por qué? Para que cuando despleguemos la landing comercial, todas las medidas ya estén en su sitio y no tengamos que recordar configurarlas en el último momento.
Si te encuentras algo raro
“La web no carga / da error de seguridad”
- Mira primero en otra red (datos móviles) por si es un problema de tu conexión.
- Si sigue sin cargar para todo el mundo, mira el dashboard del workspace:
https://workspace.crearack.com/biblioteca/pulse— la sección “Salud del sistema” muestra si Cloudflare ha detectado caída. - Avisa a Edu o Dani.
“Un cliente me dice que recibe challenge / captcha al entrar”
Puede pasar si su IP tiene mala reputación (VPN, red corporativa con histórico). El captcha desaparece tras 1-2 segundos. Si insiste, pasarle la consulta a Edu — él puede whitelistear su IP en Cloudflare.
“He recibido un correo extraño de Cloudflare”
Cloudflare manda emails legítimos al edudomo2@gmail.com de Edu cuando hay alertas. Si te llega a ti, es phishing — no clicar nada, reenviar a Edu. Cloudflare no manda emails al equipo, solo al titular de la cuenta.
Para profundizar (técnico)
Si necesitas el detalle exacto de qué settings están activos, comandos para verificar, IDs de zona, o el procedimiento para replicar la seguridad a un dominio nuevo:
→ [[workspace-tech—tecnico—cloudflare-security]] (referencia técnica completa para Edu y Dani)
Véase también
- [[workspace-tech—tecnico—cloudflare-security]] — referencia técnica
- [[workspace—guias—team-processes]] — procesos del equipo
- [[workspace—guias—workspace-user-guide]] — guía de uso del workspace
- [[crearack-tech—guides—secret-rotation-playbook]] — rotación de secrets y credenciales