Arhitectura de securitate Odoo 19: combinarea corectă a firewall-ului, 2FA, permisiunilor și Web RBL

Odoo este accesibil de pe internetul deschis pe cele cinci site-uri ale noastre, și aceasta nu este o excepție, ci cazul normal: cine operează o ofertă, un magazin sau o autentificare a clienților are un server public. O singură parolă vulnerabilă, un fișier de configurare uitat sau o permisiune prea generoasă este suficientă pentru ca un server public să devină un server deschis.

Acest articol arată cum puteți securiza corect Odoo 19 — nu cu o singură măsură, ci cu mai multe straturi care se completează reciproc: firewall și reverse proxy, modulul nostru open source Web RBL, autentificarea în doi pași, politica de parole și permisiunile — și ce încercări de atac oprește de fapt fiecare dintre ele. La final urmează un ghid pas cu pas, cu ajutorul căruia orice instalare proprie de Odoo poate fi adusă la același nivel.

Apărare în profunzime: de ce o singură măsură nu este niciodată suficientă

Fiecare măsură de securitate în parte are o lacună. Un firewall nu vede ce se întâmplă într-un formular de autentificare Odoo. O parolă puternică nu protejează dacă a fost deja furată în altă parte. O structură de permisiuni nu ajută cu nimic împotriva unui atacator care nu s-a autentificat încă. Principiul care închide aceste lacune se numește apărare în profunzime (defense in depth): mai multe straturi independente, fiecare dintre ele putând fi ocolit în sine — dar toate împreună, nu.

La noi sunt patru straturi, fiecare cu o altă sarcină:

• Firewall / reverse proxy — ține departe ceea ce este evident rău intenționat, înainte ca acesta să ajungă măcar la server
• Web RBL — leagă ambele părți: Odoo învață din propriul jurnal de aplicație ceea ce firewall-ul nu poate vedea deloc și îl transmite înapoi acestuia
• Odoo însuși — autentificare în doi pași, politica de parole, permisiuni, gestionarea sesiunilor
• Baza de date & exploatarea — copii de siguranță, protecția accesului la administrare, secrete în afara oricărui jurnal

Secțiunile următoare parcurg fiecare strat în parte.

Stratul 1: firewall și reverse proxy

Firewall-ul este prima instanță care vede o cerere și singura care poate ține un atacator departe de orice serviciu de pe server — nu doar de site, ci și de serverul de e-mail, de accesul VPN și de propria interfață de administrare. Ce se activează aici în mod rezonabil depinde de producător, dar formele de bază sunt aceleași la OPNsense, pfSense, HAProxy, FortiGate, Sophos sau Check Point:

Liste RBL: calea standard prin care este livrată reputația

RBL înseamnă Real-time Blackhole List, un termen din lumea e-mailului: o adresă pe fiecare rând, accesibilă prin HTTP, reîncărcată periodic. Practic orice firewall poate citi o astfel de listă și construi reguli pe baza ei — OPNsense și pfSense ca URL Table Alias, HAProxy ca fișier ACL, FortiGate ca External Block List, Palo Alto ca External Dynamic List, Cisco, Sophos, Juniper și MikroTik cu denumiri proprii pentru același principiu.

Exact aici intervine modulul nostru — și exact aici începe al doilea strat.

Stratul 2: Web RBL — puntea dintre aplicație și firewall

Un firewall vede pachete, nu logica aplicației. Nu știe că o cerere către /xmlrpc/2/common este o încercare de autentificare, că douăzeci de căi diferite în paisprezece secunde înseamnă un scaner sau că o adresă tocmai a ghicit cu succes o parolă. Toate acestea le știe doar Odoo însuși. Web RBL, propriul nostru modul open source (AGPL-3), face această cunoaștere utilizabilă — pentru Odoo însuși și, livrat ca listă RBL, și pentru firewall-ul din fața lui.

Liste de amenințări comparate continuu, fiecare cu nivel propriu.

Pe scurt, ceea ce este descris în detaliu în articolul anterior:

• Recunoașterea modelelor în căi: fișiere .env, directoare .git, fișiere de configurare, sonde WordPress și PHP, path traversal, execuție de comenzi prin noile interfețe AI
• Apărare la autentificare care numără peste reporniri — spre deosebire de contorul propriu al Odoo, aflat în memoria de lucru
• Evaluarea fiecărei adrese de la 0 la 100, cu motivare în text clar
• Configurările greșite (QNAP, Autodiscover, Synology) sunt recunoscute și niciodată blocate, deoarece o blocare nu remediază defectul, ci doar îl ascunde
• Liste externe de amenințări precum Spamhaus, FireHOL și nodurile de ieșire Tor, comparate continuu
• Lista albă pentru adresele care nu trebuie blocate niciodată

Pentru acest articol, două proprietăți sunt deosebit de importante, deoarece sunt direct legate de firewall și de autentificare.

O listă inertă este o listă în care poți avea încredere

Lista albă — adrese care nu sunt niciodată blocate, de exemplu conexiunile proprii ale locațiilor — se schimbă de regulă rar. Exact asta este valoarea ei, nu defectul ei: Dacă o listă liniștită abia se mișcă în decurs de zile, orice schimbare rară se observă imediat. Actualizarea automată zilnică nu există pentru că s-ar schimba multe, ci pentru ca schimbarea rară să nu trebuiască adăugată manual — și exact aceasta este situația în care se uită. Una dintre propriile noastre configurări greșite din luna trecută a fost observată exact așa: nu prin multe evenimente, ci prin cel unul pe care nu-l cunoștea nimeni, până când API-ul web QNAP al unui client a fost blocat din greșeală. De atunci, QNAP se află pe lista configurărilor greșite care nu sunt niciodată blocate, ci doar raportate.

Autentificarea este locul pe care un firewall nu îl vede

Un firewall poate bloca o adresă. Nu poate ști dacă o autentificare a reușit, și cu atât mai puțin dacă a venit de la o adresă care cu puțin timp înainte căuta încă date de acces. Web RBL poate: O evaluare peste un prag reglabil interzice complet autentificarea, iar o autentificare reușită de la o adresă suspectă este raportată — aceasta este veriga către stratul următor.

Stratul 3: securizarea Odoo însuși

Autentificarea în doi pași: un al doilea secret care nu poate fi refolosit

Cea mai mare problemă a parolelor nu este calitatea lor, ci refolosirea lor. O parolă furată de la un alt serviciu funcționează la noi la fel, atâta timp cât este aceeași. Autentificarea în doi pași (2FA, numită și TOTP) îi opune un al doilea secret: un cod de șase cifre care se schimbă la fiecare treizeci de secunde și este calculat dintr-un secret pe care îl cunoaște doar propriul smartphone. O parolă furată nu mai este astfel suficientă de una singură.

Odoo 19 Community aduce asta încorporat — ca modul instalabil Two-Factor Authentication (TOTP), completat cu o opțiune de rezervă prin e-mail. Fiecare utilizator o configurează singur, prin cod QR, cu orice aplicație de autentificare uzuală:

Configurarea: scanați codul QR, confirmați o dată codul de șase cifre, gata.

Dar asta ajută doar pe cei care și-o configurează singuri — iar experiența arată că, fără obligativitate, aceștia rămân minoritatea. De aceea Odoo are o politică de impunere: fie doar pentru angajați (utilizatori interni), fie pentru toți, inclusiv utilizatorii de portal. Fără un al doilea secret configurat, nimeni nu mai trece de formularul de autentificare fără a confirma cel puțin printr-un cod trimis prin e-mail.

Politica de parole: o lungime minimă nu este de la sine înțeleasă

Fără un modul suplimentar, Odoo Community nu impune nicio lungime minimă pentru parole — un utilizator poate seta o parolă de trei caractere dacă nu îl împiedică nimeni. Modulul propriu Password Policy închide exact această lacună: o lungime minimă impusă pe partea serverului, nu doar sugerată în browser. Cine vrea mai mult — un termen de expirare impus, un istoric împotriva refolosirii — are nevoie pentru asta de un modul OCA sau terț; versiunea Community este ținută deliberat suplă.

Permisiuni: acces doar pentru cine are nevoie

Odoo separă din oficiu trei niveluri: utilizatori de portal (doar propriul portal de client sau de furnizor), utilizatori interni (backend-ul, cu drepturi pe aplicație) și administratori (acces nelimitat, inclusiv setări tehnice). Cea mai frecventă greșeală nu este o parolă prea slabă, ci un rol de administrator acordat prea generos: Cine trebuie doar să creeze facturi nu are nevoie de acces la setările sistemului.

Două principii poartă cea mai mare parte a greutății:

Ambele pot fi verificate în aceeași vizualizare în care se configurează și autentificarea în doi pași:

O privire de ansamblu, patru pârghii: parola, al doilea factor, cheile API, dispozitivele conectate.

Sesiuni și dispozitive: cine este conectat acum

Aceeași vizualizare arată și de pe ce dispozitive este conectat un cont în acest moment — și permite deconectarea unuia singur sau a tuturor deodată. După un laptop pierdut sau la suspiciunea unei parole compromise, acesta este cel mai rapid pas eficient: Sesiunea se încheie imediat, indiferent dacă parola a fost deja schimbată.

Stratul 4: baza de date și exploatarea

Al patrulea strat este cel mai puțin vizibil și totodată cel mai nepermis de greșit, deoarece o eroare aici poate anula tot ce s-a construit înainte.

• Copii de siguranță regulate, verificate, stocate separat de serverul însuși. O copie de siguranță care nu a fost niciodată restaurată este o presupunere, nu o copie de siguranță.
• Secretele nu au ce căuta în niciun fișier de jurnal. Parole, chei API, date de licență — cine scrie extensii proprii ar trebui să le trateze ca pe parola principală însăși: să nu le înregistreze nicăieri, nici „doar pentru depanare”.
• Păstrați modulele actualizate, inclusiv și mai ales modulele terțe. Modulele suplimentare libere (OCA și altele) rămân, în mod firesc, în urma noilor versiuni Odoo; înainte de fiecare instalare merită verificat ce dependențe vin automat odată cu ele.

Calea de autentificare în ansamblu

Cele patru straturi nu acționează unul după altul în încăperi separate, ci asupra aceleiași cereri, treaptă cu treaptă. Cel mai clar se vede pe exemplul unei autentificări:

Cinci locuri în care o cerere rău intenționată poate ajunge la capăt înainte de a ajunge la adevărata țintă — și un singur loc în care un utilizator îndreptățit le trece pe toate.

Scenarii de atac și apărarea împotriva lor

Prezentarea următoare asociază modele reale de atac cu straturile care le opresc efectiv. Mai multe dintre ele nu sunt teorie, ci observații proprii din șaptesprezece zile de trafic real pe cele cinci site-uri ale noastre.

Pas cu pas: securizarea propriei instalări Odoo

Ordinea următoare este cea în care am proceda noi înșine — de la efectul cel mai mare la setarea cea mai fină.

1. Impuneți autentificarea în doi pași

1. Dacă nu este încă instalat: deschideți Aplicații, căutați „Two-Factor Authentication” și instalați (la mai multe site-uri se recomandă suplimentar „Two-Factor Authentication by Mail” ca opțiune de rezervă).
2. Deschideți Setări → Setări generale → Permisiuni.
3. Activați „Impune autentificarea în doi pași”.
4. Alegeți politica: „Doar angajați” pentru utilizatori interni, „Toți utilizatorii” dacă trebuie incluși și utilizatorii de portal (clienți cu acces).
5. Salvați. De la următoarea încercare de autentificare, Odoo cere fiecărui utilizator fără un al doilea secret configurat cel puțin codul prin e-mail, până când acesta configurează aplicația de autentificare.

2. Stabiliți o lungime minimă pentru parole

1. Deschideți Aplicații, căutați „Password Policy” și instalați.
2. Deschideți Setări → Setări generale → Permisiuni.
3. Setați „Lungimea minimă a parolei” — douăsprezece caractere sunt o valoare de pornire rezonabilă.
4. Salvați. Regula se aplică de acum înainte pentru fiecare parolă nouă sau modificată, nu retroactiv pentru parolele existente.

3. Revizuiți permisiunile

1. Deschideți Setări → Utilizatori & companii → Utilizatori.
2. Deschideți fiecare utilizator în parte și verificați fila cu drepturile de acces pe aplicație: Are această persoană într-adevăr nevoie de „Manager” sau „Administrator”, sau este suficient „Utilizator”?
3. De verificat în mod special: Cine are acces chiar la „Setări”? Ar trebui să fie un grup foarte mic.
4. Pentru fiecare conexiune externă (contabilitate, scripturi proprii, pontaj), creați în fila „Securitatea contului” a utilizatorului tehnic respectiv o cheie API proprie, în loc să transmiteți parola utilizatorului.

4. Instalați Web RBL și observați înainte de a-l activa efectiv

1. Puneți modulul de la github.com/Alex0176/odoo-web-rbl în calea addon și instalați-l.
2. Observați câteva zile: meniul Web RBL → Analiză arată ce modele se declanșează efectiv.
3. Abia după aceea activați web_rbl.sperren_aktiv (Setări → Tehnic → Parametri de sistem) — de aici înainte, sondele recunoscute sunt respinse efectiv.
4. Integrați lista de blocare în firewall ca listă RBL, la adresa indicată în modul și protejată cu token (la OPNsense/pfSense ca URL Table Alias, la HAProxy ca fișier ACL).

5. Securizați firewall-ul însuși

1. Faceți interfața de administrare a firewall-ului accesibilă exclusiv din rețeaua internă, niciodată prin aceeași adresă publică ca site-ul.
2. Activați actualizările automate de securitate pentru software-ul firewall-ului, dacă producătorul le oferă.
3. Verificați configurarea TLS: doar versiuni actuale de protocol, dezactivați metodele de criptare depășite.
4. Dacă este disponibilă: integrați direct pe firewall o listă de reputație cunoscută (de exemplu Spamhaus DROP) — independent de Web RBL, deoarece astfel firewall-ul vede și traficul către servicii pe care Odoo nu le atinge niciodată.

6. Închideți administrarea bazei de date

1. Verificați dacă /web/database/manager este accesibil din exterior — dacă da, setați în configurația Odoo list_db = False sau blocați calea la nivel de firewall.
2. Setați parola principală a administrării bazei de date lungă și aleatorie și nu o notați în niciun loc pe care îl poate citi altcineva.

7. Verificați copia de siguranță, nu doar configurați-o

1. Configurați o copie de siguranță automată, regulată, stocată separat de serverul Odoo.
2. Restaurați-o efectiv cel puțin o dată și verificați dacă restaurarea funcționează — o copie de siguranță neverificată este o presupunere.

Niciunul dintre acești pași nu îl înlocuiește pe celălalt. Cine implementează doar unul a întărit o ușă și le-a lăsat pe toate celelalte deschise — cine le implementează pe toate șapte are o apărare care rezistă chiar și atunci când un singur strat cedează.

Ce nu înlocuiește această arhitectură

Niciuna dintre măsurile descrise nu face grija inutilă. Un modul care respinge sondele .env nu face inofensiv un fișier .env publicat din greșeală. Autentificarea în doi pași nu protejează împotriva unui utilizator care își citește codul unui apelant la telefon. Iar un firewall nu înlocuiește o decizie despre cine are de fapt nevoie de ce permisiune. Arhitectura de securitate creează condițiile în care o singură greșeală nu devine imediat un incident — ea nu scutește pe nimeni de grijă.

Întrebări frecvente

Este suficientă o parolă puternică pentru a securiza Odoo 19?

Nu. O parolă poate fi furată în altă parte, indiferent de calitatea ei, și funcționează apoi la orice serviciu care acceptă aceeași parolă. Abia combinația cu autentificarea în doi pași, cu un firewall în față și cu o structură rezonabilă de permisiuni oferă o securizare care rezistă și după o parolă furată.

Cum activez autentificarea în doi pași în Odoo 19?

Instalați modulul „Two-Factor Authentication (TOTP)” din administrarea aplicațiilor, apoi activați impunerea la Setări → Setări generale → Permisiuni și alegeți între „Doar angajați” și „Toți utilizatorii”. Fiecare utilizator își configurează apoi propriul al doilea factor prin cod QR.

Ce este o listă RBL și de ce are Odoo nevoie de una?

RBL (Real-time Blackhole List) este o listă de adrese accesibilă prin HTTP, pe care practic orice firewall o poate citi. Odoo însuși nu livrează o astfel de listă — modulul nostru Web RBL închide această lacună, recunoscând traficul de atac din propriul jurnal de aplicație și returnându-l ca listă RBL către firewall-ul din față.

Este Odoo 19 Community suficient securizat fără module suplimentare?

Nu complet. Fără modulul Password Policy nu există nicio lungime minimă pentru parole, fără Two-Factor Authentication nu există al doilea factor, iar fără un modul precum Web RBL, Odoo nu recunoaște nici încercările de sondare, nici încercările repetate de autentificare peste o repornire. Toate patru pot fi adăugate ulterior gratuit.

Disponibilitate

Web RBL este disponibil public sub AGPL-3 și rulează la noi în producție pe cinci site-uri:

github.com/Alex0176/odoo-web-rbl

Descrierea completă a funcțiilor, cu toate modelele, evaluarea și listele de amenințări, se găsește în articolul anterior: Web RBL – listă de blocare pentru traficul de atac pe propriile site-uri.

Primim cu plăcere întrebări, observații și rapoarte de erori — cel mai bine ca issue pe GitHub.