Sari la conținut

Securitate și HTTPS

Această pagină reunește setările de securitate ale instanței: HTTPS și certificatele, protecția împotriva boților (Anubis) și cele mai sensibile variabile din fișierul .env.

Se adresează persoanei care administrează instanța (SuperAdmin sau un profil mai tehnic/operațional).

HTTPS și certificate

Farinha rulează în spatele Caddy, care gestionează HTTPS-ul automat:

  • Cu o adresă publică configurată (de exemplu, farinha.institutiaTa.org): Caddy obține și reînnoiește automat certificate gratuite.
  • Cu certificate proprii: plasează fișierele fullchain.pem și privkey.pem în folderul certs/, în rădăcina proiectului. Ele au prioritate față de certificatele automate.
  • Fără adresă publică și fără certificate proprii (de exemplu, localhost sau un IP): securitatea este dezactivată, deoarece certificatele automate ar necesita instalarea unei autorități de certificare pe clienți. În acest caz, este important să configurezi o adresă publică sau certificate proprii cât mai curând.

Dacă, dintr-un motiv oarecare, vrei să dezactivezi HTTPS-ul oricum, setează în .env:

DISABLE_HTTPS=True

Farinha în spatele unui alt proxy invers

Este obișnuit ca instituția să plaseze Farinha în spatele unui alt strat de proxy invers (de exemplu, un proxy de margine, un load balancer, un CDN sau un panou de proxy precum Nginx Proxy Manager). Topologia arată astfel:

Proxy/CDN extern
    ↓
Proxy invers intermediar
    ↓
Caddy (containerul Farinha)
    ↓
Gunicorn/Django

În acest scenariu, se întâmplă frecvent ca proxy-ul intermediar să nu transmită către Caddy informațiile necesare pentru finalizarea validării automate a certificatului (de exemplu, domeniul din handshake-ul TLS, numit și SNI). Neavând certificatul public, Caddy prezintă un certificat intern, emis de propria autoritate locală:

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

Acest certificat este valid pentru Caddy, dar nu este recunoscut de proxysurile din față sau de browsere. Rezultatul este de obicei unul dintre aceste simptome:

  • eroare de certificat invalid pe proxy-ul/CDN-ul extern (de exemplu, 526 Invalid SSL Certificate pe Cloudflare în modul strict);
  • 502 Bad Gateway pe proxy-ul intermediar, pentru că nu poate finaliza conexiunea HTTPS sigură cu Caddy;
  • buclă de redirecționare: proxy-ul trimite către portul 80, Caddy răspunde cu 308 Permanent Redirect către HTTPS, iar browserul alternează între cele două.

Problema este aceeași la orice proxy; cauza este de obicei una dintre acestea două:

  1. proxy-ul nu trimite domeniul în handshake-ul TLS (SNI), deci Caddy nu selectează certificatul corect;
  2. proxy-ul încearcă să valideze certificatul Caddy și îl respinge, pentru că este certificatul intern.

Soluție practică (exemplu cu Nginx Proxy Manager):

  1. În Proxy Host-ul domeniului, la Details, indică Farinha prin HTTPS pe portul Caddy:

  2. Scheme: https

  3. Forward Hostname/IP: IP-ul containerului Farinha (ex.: 10.0.0.14)
  4. Forward Port: 443

Astfel se evită bucla, pentru că proxy-ul nu mai lovește portul 80 (care redirecționează întotdeauna către HTTPS).

  1. În fila SSL, păstrează certificatul domeniului și Force SSL activat.

  2. În fila Advanced, trimite domeniul în handshake și acceptă certificatul intern al upstream-ului:

proxy_ssl_server_name on;
proxy_ssl_name farinha.exemplo.org;
proxy_ssl_verify off;
  • proxy_ssl_server_name on;: trimite SNI în handshake, permițând Caddy să selecteze certificatul corect pentru domeniu;
  • proxy_ssl_name farinha.exemplo.org;: definește ce domeniu este trimis ca SNI;
  • proxy_ssl_verify off;: acceptă certificatul intern al Caddy pe upstream.

La alte proxysuri, caută opțiunile echivalente: activarea SNI/păstrarea numelui de host pe upstream și dezactivarea verificării certificatului upstream.

Atenție: dezactivarea verificării menține conexiunea criptată, dar nu validează identitatea certificatului Caddy. Este acceptabilă ca soluție provizorie într-o rețea internă/controlată.

  1. Doar după ce accesul direct funcționează, revino la modul cel mai strict pe proxy-ul/CDN-ul extern (de exemplu, Full (strict) pe Cloudflare).

Soluții definitive (de preferat față de verify off):

  • Certificat public pe Caddy: configurează FARINHA_URL cu domeniul și lasă-l să finalizeze provocarea ACME, astfel încât Caddy să prezinte un certificat de încredere și verificarea să poată fi reactivată.
  • Certificate proprii de încredere: folosește certificate de la o autoritate recunoscută de proxysuri (opțiunea certs/).
  • Dezactivarea HTTPS pe Farinha cu DISABLE_HTTPS=True și indicarea proxy-ului către http pe portul 80 al containerului. Funcționează, dar segmentul dintre proxy și Farinha nu mai este criptat; evaluează riscul în mediul tău. În acest caz, păstrează HTTPS doar la margine (proxy/CDN).

Protecție împotriva boților (Anubis)

Farinha poate folosi Anubis, un firewall care le cere vizitatorilor o mică dovadă de muncă pentru a bloca accesul automatizat (boți), reducând încărcarea la vârfurile de trafic.

Protecția este controlată de două setări ale aplicației, în panoul intern de administrare (Django Admin):

  • Webapp -> Setări ale Aplicației -> „Anubis habilitado?”
  • Webapp -> Setări ale Aplicației -> „Dificuldade do Desafio Anubis” (Muito leve (1), Leve (3), Padrão (4) și Forte (10))

Lista setărilor aplicației cu hartă și Anubis

Setările aplicației includ harta portalului și protecția împotriva boților (Anubis).

Puncte importante:

  • Modificarea Anubis (activare/dezactivare sau dificultate) are efect după repornirea Farinha. La salvare, panoul te avertizează despre acest lucru.
  • run (scripturile run.sh/run.bat) citește aceste setări din baza de date și le aplică la pornirea instanței.
  • Dificultatea „Padrão (4)” este un început bun. Valorile mari fac provocarea mai grea și pot deranja utilizatorii; valorile prea mici reduc protecția.
  • Dacă provocarea nu apare pentru vizitatori, verifică dacă „Anubis habilitado?” este bifat și repornește Farinha.

Vezi și: Portal.

Variabile sensibile din .env

Fișierul .env (creat din .env-sample la prima execuție) concentrează setările instanței. Cele mai relevante pentru securitate:

  • FARINHA_URL: domeniu(i) sau IP-uri de acces, separate prin virgulă (fără https://). Cu un domeniu public, HTTPS este activat automat.
  • ADMIN_PATH: calea panoului intern de administrare. Implicit: admin/. Vezi Utilizator SuperAdmin.
  • SECRET_KEY: cheia care protejează datele sensibile. Este obligatorie: fără ea, Farinha nu pornește. Este generată automat de run.sh/run.bat; dacă o creezi manual, nu folosi caracterul $ (Docker Compose l-ar interpreta ca variabilă de mediu).
  • SECURE_HSTS_SECONDS: HSTS. Menține 0 (dezactivat) până ești sigur că HTTPS funcționează, pentru că HSTS poate face site-ul inaccesibil dacă certificatele nu sunt corecte. Activează-l doar dacă știi ce faci.
  • SECURE_HSTS_INCLUDE_SUBDOMAINS: include subdomeniile în HSTS.
  • SECURE_PROXY_SSL_HEADER și SECURE_PROXY_SSL_HEADER_VALUE: îi spun lui Django că cererea originală este sigură când există un proxy în față (deja configurate implicit pentru Caddy).
  • SECURE_CONTENT_TYPE_NOSNIFF: împiedică browserele să ghicească tipul fișierului.
  • DEBUG: în producție, menține False (valoarea implicită din .env-sample).
  • SQLITE_BUSY_TIMEOUT_MS: cât timp așteaptă baza de date când este ocupată.

Precauții:

  • Nu publica niciodată fișierul .env sau SECRET_KEY (nu le trimite prin e-mail, chat sau issues).
  • Când modifici variabile, oprește și pornește din nou instanța (./down.sh && ./run.sh pe Linux; .\down.bat și .\run.bat pe Windows).

Bune practici

  • Păstrează permisiuni restricționate pe .env; acesta conține SECRET_KEY.
  • Generează o SECRET_KEY proprie și exclusivă pentru fiecare instanță (scriptul run face deja asta automat). Nu refolosi niciodată cheia altei instalări.
  • Înainte de a activa HSTS (SECURE_HSTS_SECONDS), confirmă că HTTPS funcționează pe toate domeniile și subdomeniile folosite. HSTS este greu de anulat pe partea clientului.
  • În producție, menține DEBUG=False.
  • Dacă schimbi calea panoului cu ADMIN_PATH, împărtășește noua adresă echipei și evită căi evidente precum admin/ sau panou/.
  • Fă o copie de siguranță a bazei de date (db/) și a certificatelor proprii (certs/), dacă le folosești.
  • Dacă folosești un alt proxy invers în fața Farinha, preferă soluția definitivă (certificat public sau propriu de încredere) în loc să menții verificarea certificatului dezactivată pe upstream mult timp.

Probleme comune

  • Farinha nu pornește: verifică dacă SECRET_KEY există în .env și nu conține $. Eroarea apare în logurile containerului.
  • Avertisment de certificat invalid în browser: poate fi certificatul intern al Caddy, pentru că domeniul nu este configurat corect în FARINHA_URL, sau pentru că validarea automată nu a putut fi finalizată. Verifică și subsecțiunea despre proxy de mai sus.
  • Eroare de certificat (526) sau 502 pe proxy/CDN: vezi subsecțiunea Farinha în spatele unui alt proxy invers; de obicei este upstream-ul HTTPS fără SNI și cu verificarea certificatului activată.
  • Buclă de redirecționare: proxy-ul indică spre portul 80 al Caddy, care redirecționează întotdeauna către HTTPS. Folosește https pe portul 443 sau dezactivează HTTPS pe Farinha.
  • Provocarea Anubis nu apare: confirmă că „Anubis habilitado?” este bifat în Setările Aplicației și repornește Farinha.
  • Am modificat setarea Anubis și nimic nu s-a schimbat: modificările au efect doar după repornirea Farinha (avertismentul apare în panou la salvare).
  • Provocarea Anubis încurcă integrările interne: ia în calcul dezactivarea protecției sau reducerea dificultății, ținând cont de repornirea necesară.