Saltar a contenido

Seguridad y HTTPS

Esta página reúne las configuraciones de seguridad de la instancia: HTTPS y certificados, protección contra bots (Anubis) y las variables más sensibles del archivo .env.

Está dirigida a quien administra la instancia (SuperAdmin o perfil más técnico-operativo).

HTTPS y certificados

Farinha se ejecuta detrás de Caddy, que gestiona el HTTPS automáticamente:

  • Con una dirección pública configurada (por ejemplo, farinha.suInstitucion.org): Caddy obtiene y renueva certificados gratuitos automáticamente.
  • Con certificados propios: coloca los archivos fullchain.pem y privkey.pem en la carpeta certs/, en la raíz del proyecto. Tendrán prioridad sobre los certificados automáticos.
  • Sin dirección pública y sin certificados propios (por ejemplo, localhost o una IP): la seguridad se deshabilita, porque los certificados automáticos exigirían instalar una autoridad certificadora en los clientes. En ese caso, es importante configurar una dirección pública o certificados propios cuanto antes.

Si, por algún motivo, quieres deshabilitar el HTTPS de todos modos, define en el .env:

DISABLE_HTTPS=True

Farinha detrás de otro proxy inverso

Es común que la institución coloque Farinha detrás de otra capa de proxy inverso (por ejemplo, un proxy en el borde, un balanceador, un CDN o un panel de proxy como Nginx Proxy Manager). La topología queda así:

Proxy/CDN externo
    ↓
Proxy inverso intermedio
    ↓
Caddy (contenedor de Farinha)
    ↓
Gunicorn/Django

En este escenario, es común que el proxy intermedio no reenvíe a Caddy la información necesaria para completar la validación automática del certificado (por ejemplo, el dominio en el handshake TLS, también llamado SNI). Al no poder obtener el certificado público, Caddy pasa a presentar un certificado interno, emitido por su propia autoridad local:

Issuer: Caddy Local Authority - ECC Intermediate
Subject Alternative Name: farinha.exemplo.org

Ese certificado es válido para Caddy, pero no es reconocido por los proxies delante ni por los navegadores. El resultado suele ser uno de estos síntomas:

  • error de certificado no válido en el proxy/CDN externo (por ejemplo, 526 Invalid SSL Certificate en Cloudflare en modo estricto);
  • 502 Bad Gateway en el proxy intermedio por no poder completar la conexión HTTPS segura con Caddy;
  • bucle de redirección: el proxy reenvía al puerto 80, Caddy responde 308 Permanent Redirect a HTTPS y el navegador queda alternando entre los dos.

El problema es el mismo con cualquier proxy; la causa normalmente es una de estas dos cosas:

  1. el proxy no envía el dominio en el handshake TLS (SNI), entonces Caddy no selecciona el certificado correcto;
  2. el proxy intenta validar el certificado de Caddy y lo rechaza, porque es el certificado interno.

Solución práctica (ejemplo con Nginx Proxy Manager):

  1. En el Proxy Host del dominio, en Details, apunta a Farinha por HTTPS en el puerto de Caddy:

  2. Scheme: https

  3. Forward Hostname/IP: IP del contenedor de Farinha (ej.: 10.0.0.14)
  4. Forward Port: 443

Esto evita el bucle, porque el proxy deja de apuntar al puerto 80 (que siempre redirige a HTTPS).

  1. En la pestaña SSL, mantén el certificado del dominio y Force SSL activado.

  2. En la pestaña Advanced, envía el dominio en el handshake y acepta el certificado interno del upstream:

proxy_ssl_server_name on;
proxy_ssl_name farinha.exemplo.org;
proxy_ssl_verify off;
  • proxy_ssl_server_name on;: envía el SNI en el handshake, permitiendo que Caddy seleccione el certificado correcto para el dominio;
  • proxy_ssl_name farinha.exemplo.org;: define qué dominio se envía como SNI;
  • proxy_ssl_verify off;: acepta el certificado interno de Caddy en el upstream.

En otros proxies, busca las opciones equivalentes: habilitar SNI/preservar el nombre del host en el upstream y deshabilitar la verificación del certificado del upstream.

Atención: desactivar la verificación mantiene la conexión cifrada, pero no valida la identidad del certificado de Caddy. Es aceptable como solución provisional en una red interna/controlada.

  1. Solo después de que el acceso directo funcione, vuelve al modo más estricto en el proxy/CDN externo (por ejemplo, Full (strict) en Cloudflare).

Soluciones definitivas (preferibles a verify off):

  • Certificado público en Caddy: configurar FARINHA_URL con el dominio y permitir que complete el desafío ACME, para que Caddy presente un certificado de confianza y se pueda reactivar la verificación.
  • Certificados propios de confianza: usar certificados de una autoridad reconocida por los proxies (opción certs/).
  • Deshabilitar el HTTPS en Farinha con DISABLE_HTTPS=True y apuntar el proxy a http en el puerto 80 del contenedor. Funciona, pero el tramo entre el proxy y Farinha deja de estar cifrado; evalúa el riesgo en tu entorno. En ese caso, mantén el HTTPS solo en el borde (proxy/CDN).

Protección contra bots (Anubis)

Farinha puede usar Anubis, un firewall que exige a los visitantes una pequeña prueba de trabajo para bloquear accesos automatizados (bots), reduciendo la carga en picos de tráfico.

La protección se controla con dos configuraciones de la aplicación, en el panel interno de administración (Django Admin):

  • Webapp -> Configurações do Aplicativo -> “Anubis habilitado?”
  • Webapp -> Configurações do Aplicativo -> “Dificuldade do Desafio Anubis” (Muito leve (1), Leve (3), Padrão (4) y Forte (10))

Lista de configuraciones de la aplicación con mapa y Anubis

Las configuraciones de la aplicación incluyen el mapa del portal y la protección contra bots (Anubis).

Puntos importantes:

  • El cambio de Anubis (activar/desactivar o dificultad) surte efecto después de reiniciar Farinha. Al guardar, el panel avisa sobre esto.
  • El run (scripts run.sh/run.bat) lee estas configuraciones de la base de datos y las aplica al iniciar la instancia.
  • La dificultad “Padrão (4)” es un buen comienzo. Valores altos hacen el desafío más pesado y pueden molestar a los usuarios; valores muy bajos reducen la protección.
  • Si el desafío no aparece para los visitantes, verifica que “Anubis habilitado?” esté marcado y reinicia Farinha.

Ver también: Portal.

Variables sensibles del .env

El archivo .env (creado a partir del .env-sample en la primera ejecución) concentra las configuraciones de la instancia. Las más relevantes para la seguridad:

  • FARINHA_URL: dominio(s) o IP(s) de acceso, separados por comas (sin https://). Con un dominio público, el HTTPS se activa automáticamente.
  • ADMIN_PATH: ruta del panel interno de administración. Predeterminada: admin/. Ver Usuario SuperAdmin.
  • SECRET_KEY: clave que protege datos sensibles. Es obligatoria: sin ella Farinha no arranca. La generan automáticamente run.sh/run.bat; si la creas manualmente, no uses el carácter $ (Docker Compose lo interpretaría como variable de entorno).
  • SECURE_HSTS_SECONDS: HSTS. Mantén 0 (deshabilitado) hasta estar seguro de que el HTTPS funciona, porque el HSTS puede dejar el sitio inaccesible si los certificados no son correctos. Habilítalo solo si sabes lo que haces.
  • SECURE_HSTS_INCLUDE_SUBDOMAINS: incluye subdominios en el HSTS.
  • SECURE_PROXY_SSL_HEADER y SECURE_PROXY_SSL_HEADER_VALUE: informan a Django que la solicitud original es segura cuando hay un proxy delante (ya configurado por defecto para Caddy).
  • SECURE_CONTENT_TYPE_NOSNIFF: impide que los navegadores intenten adivinar el tipo de archivo.
  • DEBUG: en producción, mantén False (es el valor predeterminado del .env-sample).
  • SQLITE_BUSY_TIMEOUT_MS: tiempo de espera de la base de datos cuando está ocupada.

Cuidados:

  • Nunca publiques el archivo .env ni la SECRET_KEY (no los envíes por correo, chat o issues).
  • Al cambiar variables, detén e inicia la instancia nuevamente (./down.sh && ./run.sh en Linux; .\down.bat y .\run.bat en Windows).

Buenas prácticas

  • Mantén permisos restringidos en el .env; contiene la SECRET_KEY.
  • Genera una SECRET_KEY propia y exclusiva por instancia (el run ya lo hace automáticamente). Nunca reutilices la clave de otra instalación.
  • Antes de activar el HSTS (SECURE_HSTS_SECONDS), confirma que el HTTPS funciona en todos los dominios y subdominios usados. El HSTS es difícil de revertir del lado del cliente.
  • En producción, mantén DEBUG=False.
  • Si cambias la ruta del panel con ADMIN_PATH, comparte la nueva dirección con el equipo y evita rutas obvias como admin/ o panel/.
  • Ten una copia de seguridad de la base de datos (db/) y de los certificados propios (certs/), si los usas.
  • Si usas otro proxy inverso delante de Farinha, prefiere la solución definitiva (certificado público o propio de confianza) en lugar de mantener la verificación de certificado desactivada en el upstream por mucho tiempo.

Problemas comunes

  • Farinha no arranca: verifica que la SECRET_KEY exista en el .env y no contenga $. El error aparece en los registros del contenedor.
  • Aviso de certificado no válido en el navegador: puede ser el certificado interno de Caddy apareciendo porque el dominio no está configurado correctamente en FARINHA_URL, o porque la validación automática no pudo completarse. Revisa también la subsección de proxy anterior.
  • Error de certificado (526) o 502 en el proxy/CDN: consulta la subsección Farinha detrás de otro proxy inverso; normalmente es el upstream HTTPS sin SNI y con la verificación de certificado activada.
  • Bucle de redirección: el proxy apunta al puerto 80 de Caddy, que siempre redirige a HTTPS. Usa https en el puerto 443 o deshabilita el HTTPS en Farinha.
  • El desafío de Anubis no aparece: confirma que “Anubis habilitado?” esté marcado en las Configuraciones de la Aplicación y reinicia Farinha.
  • Cambié la configuración de Anubis y nada cambió: los cambios solo surten efecto después de reiniciar Farinha (el aviso aparece en el panel al guardar).
  • El desafío de Anubis interfiere con integraciones internas: evalúa deshabilitar la protección o reducir la dificultad, recordando el reinicio necesario.