Odoo 19 saugumo architektūra: kaip tinkamai derinti užkardą, 2FA, leidimus ir Web RBL

Odoo mūsų penkiose svetainėse pasiekiamas iš atviro interneto, ir tai nėra išimtis, o įprasta padėtis: kas siūlo pasiūlymą, parduotuvę ar kliento prisijungimą, tas turi viešą serverį. Vieno pažeidžiamo slaptažodžio, pamirštos konfigūracijos failo ar pernelyg dosnaus leidimo pakanka, kad viešas serveris taptų atviru.

Šiame straipsnyje parodome, kaip tinkamai apsaugoti Odoo 19 — ne viena priemone, o keliais vienas kitą papildančiais sluoksniais: užkarda ir atvirkštinis tarpinis serveris (reverse proxy), mūsų atvirojo kodo modulis Web RBL, dviejų veiksnių autentifikavimas, slaptažodžių politika ir leidimai — ir kokius atakų bandymus kiekviena iš jų iš tikrųjų sustabdo. Pabaigoje pateikiama žingsnis po žingsnio instrukcija, pagal kurią galima sutvarkyti bet kurią savo Odoo diegtį.

Gynyba iš kelių sluoksnių: kodėl vienos priemonės niekada nepakanka

Kiekviena atskira saugumo priemonė turi spragą. Užkarda nemato, kas vyksta Odoo prisijungimo formoje. Stiprus slaptažodis neapsaugo, jei jis jau pavogtas kitur. Leidimų struktūra nepadeda prieš užpuoliką, kuris dar iš viso neprisijungė. Principas, uždarantis šias spragas, vadinasi gynyba iš kelių sluoksnių (defense in depth): keli nepriklausomi sluoksniai, iš kurių kiekvieną atskirai galima apeiti — bet visų kartu — ne.

Pas mus yra keturi sluoksniai, kiekvienas su kita užduotimi:

• Užkarda / atvirkštinis tarpinis serveris — atlaiko akivaizdžiai piktavališką srautą dar prieš jam pasiekiant serverį
• Web RBL — sujungia abi puses: Odoo iš savo programos žurnalo išmoksta tai, ko užkarda negali matyti, ir perduoda tai atgal jai
• Pats Odoo — dviejų veiksnių autentifikavimas, slaptažodžių politika, leidimai, sesijų valdymas
• Duomenų bazė & eksploatacija — atsarginės kopijos, valdymo apsauga nuo prieigos, paslaptys už bet kokio žurnalo ribų

Toliau kiekvienas sluoksnis aptariamas atskirai.

1 sluoksnis: užkarda ir atvirkštinis tarpinis serveris

Užkarda yra pirmoji instancija, kuri mato užklausą, ir vienintelė, galinti užpuoliką atriboti nuo kiekvienos serverio paslaugos — ne tik nuo svetainės, bet ir nuo pašto serverio, VPN prieigos bei savo valdymo sąsajos. Kas šioje vietoje prasminga aktyvuoti, priklauso nuo gamintojo, tačiau pagrindiniai dalykai OPNsense, pfSense, HAProxy, FortiGate, Sophos ar Check Point atveju yra tie patys:

RBL sąrašai: standartinis būdas, kuriuo pateikiama reputacija

RBL reiškia Real-time Blackhole List, terminas iš el. pašto pasaulio: vienas adresas eilutėje, prieinamas per HTTP, reguliariai įkeliamas iš naujo. Praktiškai kiekviena užkarda gali nuskaityti tokį sąrašą ir iš jo sudaryti taisykles — OPNsense ir pfSense kaip URL Table Alias, HAProxy kaip ACL failas, FortiGate kaip External Block List, Palo Alto kaip External Dynamic List, Cisco, Sophos, Juniper ir MikroTik su savais pavadinimais tam pačiam principui.

Būtent čia įsijungia mūsų pačių modulis — ir būtent čia prasideda antrasis sluoksnis.

2 sluoksnis: Web RBL — tiltas tarp programos ir užkardos

Užkarda mato paketus, o ne programos logiką. Ji nežino, kad užklausa /xmlrpc/2/common yra bandymas prisijungti, kad dvidešimt skirtingų kelių per keturiolika sekundžių yra skeneris arba kad koks nors adresas ką tik sėkmingai atspėjo slaptažodį. Visa tai žino tik pats Odoo. Web RBL, mūsų atvirojo kodo modulis (AGPL-3), šias žinias paverčia naudingomis — pačiam Odoo ir, pateikiamas kaip RBL sąrašas, taip pat už jo esančiai užkardai.

Grėsmių sąrašai nuolat sulyginami, kiekvienas su sava pakopa.

Trumpai apie tai, kas išsamiai aprašyta ankstesniame straipsnyje:

• Šablonų atpažinimas keliuose: .env failai, .git katalogai, konfigūracijos failai, WordPress ir PHP zondai, kelio perėjimas (path traversal), komandų vykdymas per naujas DI sąsajas
• Prisijungimo apsauga, skaičiuojanti ir po perkrovimų — skirtingai nei paties Odoo, operatyviojoje atmintyje gyvenantis skaitiklis
• Vertinimas kiekvieno adreso nuo 0 iki 100, su pagrindimu aiškiu tekstu
• Klaidingos konfigūracijos (QNAP, Autodiscover, Synology) atpažįstamos ir niekada neblokuojamos, nes blokavimas defekto nepašalina, o tik jį paslepia
• Svetimi grėsmių sąrašai, tokie kaip Spamhaus, FireHOL ir Tor išėjimo mazgai, nuolat sulyginami
• Baltasis sąrašas adresams, kurie niekada neturi būti blokuojami

Šiam straipsniui ypač svarbios dvi savybės, nes jos tiesiogiai susijusios su užkarda ir su prisijungimu.

Retai kintančiu sąrašu galima pasitikėti

Baltasis sąrašas — adresai, kurie niekada neblokuojami, pavyzdžiui, savos vietovių jungtys — paprastai keičiasi retai. Būtent tai yra jo vertė, o ne trūkumas: jei rami sąrašas per kelias dienas vos pasikeičia, kiekvienas retas pakeitimas iškart krenta į akis. Kasdienis automatinis atnaujinimas egzistuoja ne todėl, kad daug kas keistųsi, o kad retas pakeitimas nebūtų pildomas rankomis — o kaip tik tada jį užmirštama. Viena iš mūsų pačių klaidingų konfigūracijų praėjusį mėnesį pasimatė būtent taip: ne dėl daugybės įvykių, o dėl vieno, kurio niekas nežinojo, kol klaidingai nebuvo užblokuota kliento QNAP žiniatinklio API. Nuo tada QNAP yra klaidingų konfigūracijų sąraše, kurios niekada neblokuojamos, o tik pranešamos.

Prisijungimas yra vieta, kurios užkarda nemato

Užkarda gali užblokuoti adresą. Ji negali žinoti, ar prisijungimas pavyko, o juo labiau — ar jis atėjo iš adreso, kuris prieš tai ieškojo prisijungimo duomenų. Web RBL žino: vertinimas nuo nustatomos ribos prisijungimą visiškai uždraudžia, o sėkmingas prisijungimas iš įtartino adreso pranešamas — tai jungiamoji grandis su kitu sluoksniu.

3 sluoksnis: paties Odoo apsauga

Dviejų veiksnių autentifikavimas: antroji paslaptis, kurios negalima pakartotinai panaudoti

Didžiausia slaptažodžių problema yra ne jų kokybė, o pakartotinis naudojimas. Kitoje paslaugoje pavogtas slaptažodis pas mus veikia lygiai taip pat, kol jis tas pats. Dviejų veiksnių autentifikavimas (2FA, dar vadinamas TOTP) tam priešpastato antrą paslaptį: šešiaženklį kodą, kuris keičiasi kas trisdešimt sekundžių ir yra skaičiuojamas iš paslapties, kurią žino tik paties išmanusis telefonas. Vien pavogto slaptažodžio tada nebepakanka.

Odoo 19 Community tai turi įmontuota — kaip įdiegiamą modulį Two-Factor Authentication (TOTP), papildytą atsarginiu el. pašto variantu. Kiekvienas naudotojas jį nusistato pats, per QR kodą, su bet kokia įprasta autentifikavimo programėle:

Nustatymas: nuskaityti QR kodą, vieną kartą patvirtinti šešiaženklį kodą, ir viskas.

Tačiau tai padeda tik tiems, kurie tai nusistato patys — o patirtis rodo, kad be prievartos tai lieka mažuma. Todėl Odoo turi privalomumo politiką: arba tik darbuotojams (vidiniams naudotojams), arba visiems, įskaitant portalo naudotojus. Be nustatytos antros paslapties niekas nebepereis prisijungimo formos, nepatvirtinęs bent el. pašto kodu.

Slaptažodžių politika: minimalus ilgis nėra savaime suprantamas dalykas

Be papildomo modulio Odoo Community nenustato minimalaus slaptažodžio ilgio — naudotojas gali nustatyti trijų simbolių slaptažodį, jei jam niekas netrukdo. Mūsų Password Policy modulis uždaro būtent šią spragą: minimalus ilgis, įgyvendinamas serverio pusėje, o ne tik siūlomas naršyklėje. Kas nori daugiau — priverstinio galiojimo laiko, istorijos nuo pakartotinio naudojimo — tam reikia OCA ar trečiosios šalies modulio; Community versijoje tai sąmoningai palikta lengva.

Leidimai: prieigą gauna tik tas, kam jos reikia

Odoo iš prigimties skiria tris lygius: portalo naudotojai (tik savas klientų ar tiekėjų portalas), vidiniai naudotojai (užpakalinė dalis, su teisėmis pagal programą) ir administratoriai (neribota prieiga kartu su techniniais nustatymais). Dažniausia klaida yra ne per silpnas slaptažodis, o per dosniai suteiktas administratoriaus vaidmuo: kas turi tik kurti sąskaitas, tam nereikia prieigos prie sistemos nustatymų.

Didžiausią naštą neša du principai:

Abu dalykus galima patikrinti tame pačiame rodinyje, kuriame nustatomas ir dviejų veiksnių autentifikavimas:

Viena apžvalga, keturi svertai: slaptažodis, antras veiksnys, API raktai, prisijungę įrenginiai.

Sesijos ir įrenginiai: kas šiuo metu prisijungęs

Tas pats rodinys parodo ir tai, iš kokių įrenginių paskyra šiuo metu prisijungusi — ir leidžia atjungti vieną ar visus iš karto. Pametus nešiojamąjį kompiuterį arba įtarus kompromituotą slaptažodį, tai yra greičiausias veiksmingas žingsnis: sesija baigiasi iškart, nepriklausomai nuo to, ar slaptažodis jau pakeistas.

4 sluoksnis: duomenų bazė ir eksploatacija

Ketvirtas sluoksnis yra mažiausiai matomas ir kartu pats neatleistiniausias, nes klaida čia gali sunaikinti viską, kas pastatyta anksčiau.

• Reguliarios, patikrintos atsarginės kopijos, saugomos atskirai nuo paties serverio. Atsarginė kopija, kuri niekada nebuvo atkurta, yra prielaida, o ne atsarginė kopija.
• Paslapčių ne vieta jokiame žurnalo faile. Slaptažodžiai, API raktai, licencijos duomenys — kas rašo savo plėtinius, turėtų su jais elgtis kaip su pačiu pagrindiniu slaptažodžiu: niekur jų neįrašinėti, net ir „tik derinimui“.
• Moduliai turi būti atnaujinti, ypač trečiųjų šalių. Laisvi papildomi moduliai (OCA ir kiti) natūraliai atsilieka nuo naujų Odoo versijų; prieš kiekvieną diegimą verta pažiūrėti, kokios priklausomybės ateina automatiškai.

Visas prisijungimo kelias

Keturi sluoksniai veikia ne paeiliui atskirose patalpose, o su ta pačia užklausa, pakopa po pakopos. Ryškiausiai tai matyti prisijungimo pavyzdyje:

Penkios vietos, kuriose piktavališka užklausa gali baigtis, nepasiekusi tikrojo tikslo — ir tik viena, kurioje teisėtas naudotojas visas jas įveikia.

Atakų scenarijai ir gynyba nuo jų

Toliau pateiktoje apžvalgoje realūs atakų šablonai priskiriami sluoksniams, kurie juos iš tikrųjų sustabdo. Keli iš jų yra ne teorija, o mūsų pačių stebėjimai per septyniolika dienų realaus srauto mūsų penkiose svetainėse.

Žingsnis po žingsnio: savo Odoo diegties apsauga

Toliau pateikta tvarka yra ta, kuria patys elgtumėmės — nuo didžiausio poveikio iki smulkiausio nustatymo.

1. Priverstinai įjungti dviejų veiksnių autentifikavimą

1. Jei dar neįdiegta: atidarykite Programos (Apps), ieškokite „Two-Factor Authentication“ ir įdiekite (esant kelioms svetainėms papildomai rekomenduojama „Two-Factor Authentication by Mail“ kaip atsarginis variantas).
2. Atidarykite Nustatymai → Bendrieji nustatymai → Leidimai.
3. Aktyvuokite „Priverstinis dviejų veiksnių autentifikavimas“.
4. Pasirinkite politiką: „Tik darbuotojai“ vidiniams naudotojams, „Visi naudotojai“, jei norima įtraukti ir portalo naudotojus (klientus su prieiga).
5. Išsaugokite. Nuo kito bandymo prisijungti Odoo iš kiekvieno naudotojo be nustatytos antros paslapties reikalaus bent el. pašto kodo, kol jis nenustatys autentifikavimo programėlės.

2. Nustatyti minimalų slaptažodžių ilgį

1. Atidarykite Programos (Apps), ieškokite „Password Policy“ ir įdiekite.
2. Atidarykite Nustatymai → Bendrieji nustatymai → Leidimai.
3. Nustatykite „Minimalus slaptažodžio ilgis“ — dvylika simbolių yra protinga pradinė reikšmė.
4. Išsaugokite. Taisyklė galioja nuo šiol kiekvienam naujam ar pakeistam slaptažodžiui, atgaline data esamiems slaptažodžiams — ne.

3. Peržiūrėti leidimus

1. Atidarykite Nustatymai → Naudotojai & įmonės → Naudotojai.
2. Atidarykite kiekvieną naudotoją atskirai ir patikrinkite skirtuką su prieigos teisėmis pagal programą: ar šiam asmeniui tikrai reikia „Vadybininko“ ar „Administratoriaus“, ar pakanka „Naudotojo“?
3. Ypač patikrinkite: kas turi prieigą prie pačių „Nustatymų“? Tai turėtų būti labai maža grupė.
4. Kiekvienai išorinei integracijai (apskaita, nuosavi skriptai, laiko apskaita) atitinkamo techninio naudotojo skirtuke „Paskyros saugumas“ sukurkite atskirą API raktą, užuot perdavus naudotojo slaptažodį.

4. Įdiegti Web RBL ir stebėti, prieš įjungiant aktyviai

1. Modulį iš github.com/Alex0176/odoo-web-rbl įdėkite į Addon kelią ir įdiekite.
2. Kelias dienas stebėkite: meniu Web RBL → Analizė rodo, kurie šablonai iš tikrųjų veikia.
3. Tik po to įjunkite web_rbl.sperren_aktiv (Nustatymai → Techniniai → Sistemos parametrai) — nuo čia atpažinti zondai tikrai atmetami.
4. Blokavimo sąrašą modulyje nurodytu, žetonu apsaugotu adresu įtraukite į užkardą kaip RBL sąrašą (OPNsense/pfSense atveju kaip URL Table Alias, HAProxy atveju kaip ACL failą).

5. Apsaugoti pačią užkardą

1. Užkardos valdymo sąsają padaryti pasiekiamą tik iš vidinio tinklo, niekada tuo pačiu viešu adresu kaip svetainė.
2. Aktyvuoti automatinius saugumo atnaujinimus užkardos programinei įrangai, jei gamintojas tai siūlo.
3. Patikrinti TLS konfigūraciją: tik naujausios protokolų versijos, pasenusius šifravimo metodus išjungti.
4. Jei yra galimybė: žinomą reputacijos sąrašą (pavyzdžiui, Spamhaus DROP) įtraukti tiesiai užkardoje — nepriklausomai nuo Web RBL, nes taip užkarda mato ir srautą į paslaugas, kurių Odoo niekada nepasiekia.

6. Uždaryti duomenų bazių valdymą

1. Patikrinti, ar /web/database/manager pasiekiamas iš išorės — jei taip, Odoo konfigūracijoje nustatyti list_db = False arba užblokuoti kelią užkardos lygmeniu.
2. Duomenų bazių valdymo pagrindinį slaptažodį nustatyti ilgą ir atsitiktinį ir niekur neužrašyti vietoje, kurią galėtų perskaityti kas nors kitas.

7. Patikrinti atsarginę kopiją, o ne tik ją nustatyti

1. Nustatyti automatinę, reguliarią atsarginę kopiją, saugomą atskirai nuo Odoo serverio.
2. Bent kartą ją tikrai atkurti ir patikrinti, ar atkūrimas veikia — nepatikrinta atsarginė kopija yra prielaida.

Nė vienas iš šių žingsnių nepakeičia kito. Kas įgyvendina tik vieną, sustiprino vienas duris, o visas kitas paliko atviras — kas įgyvendina visus septynis, turi gynybą, kuri išlieka net tada, kai atskiras sluoksnis nepavyksta.

Ko ši architektūra nepakeičia

Nė viena aprašyta priemonė nepadaro kruopštumo nereikalingo. Modulis, kuris atmeta .env zondus, neapsaugo nuo per klaidą paskelbto .env failo. Dviejų veiksnių autentifikavimas neapsaugo nuo naudotojo, kuris savo kodą perskaito skambinančiajam telefonu. Ir užkarda nepakeičia sprendimo, kam kokios teisės iš tikrųjų reikalingos. Saugumo architektūra sukuria sąlygas, kuriomis viena klaida dar netampa incidentu — ji nieko neatleidžia nuo kruopštumo.

Dažniausiai užduodami klausimai

Ar pakanka stipraus slaptažodžio Odoo 19 apsaugoti?

Ne. Slaptažodį galima pavogti kitur, visiškai nepriklausomai nuo jo kokybės, ir tada jis veikia kiekvienoje paslaugoje, kuri priima tą patį slaptažodį. Tik derinys su dviejų veiksnių autentifikavimu, užkarda prieš tai ir prasminga leidimų struktūra sukuria apsaugą, kuri išlaiko ir po pavogto slaptažodžio.

Kaip aktyvuoti dviejų veiksnių autentifikavimą Odoo 19?

Modulį „Two-Factor Authentication (TOTP)“ įdiegti per programų valdymą, po to skiltyje Nustatymai → Bendrieji nustatymai → Leidimai aktyvuoti privalomumą ir pasirinkti tarp „Tik darbuotojai“ ir „Visi naudotojai“. Kiekvienas naudotojas po to per QR kodą nusistato savo antrąjį veiksnį.

Kas yra RBL sąrašas ir kodėl jo reikia Odoo?

RBL (Real-time Blackhole List) yra per HTTP prieinamas adresų sąrašas, kurį gali nuskaityti praktiškai kiekviena užkarda. Pats Odoo tokio sąrašo neturi — mūsų modulis Web RBL uždaro šią spragą, atpažindamas atakų srautą iš savo programos žurnalo ir grąžindamas jį kaip RBL sąrašą prieš tai esančiai užkardai.

Ar Odoo 19 Community be papildomų modulių yra pakankamai apsaugotas?

Ne visiškai. Be modulio Password Policy nėra minimalaus slaptažodžio ilgio, be Two-Factor Authentication nėra antro veiksnio, o be tokio modulio kaip Web RBL Odoo neatpažįsta nei žvalgymo bandymų, nei pakartotinių prisijungimo bandymų per perkrovimą. Visus keturis galima nemokamai papildomai įdiegti.

Prieinamumas

Web RBL viešai prieinamas pagal AGPL-3 ir mūsų aplinkoje produkciškai veikia penkiose svetainėse:

github.com/Alex0176/odoo-web-rbl

Visas funkcijų aprašymas su visais šablonais, vertinimu ir grėsmių sąrašais pateiktas ankstesniame straipsnyje: Web RBL – blokavimo sąrašas atakų srautui savose svetainėse.

Klausimus, pastabas ir klaidų ataskaitas mielai priimame — mieliausia kaip Issue GitHub.