Odoo 19 drošības arhitektūra: ugunsmūris, 2FA, atļaujas un Web RBL pareizā kombinācijā

Odoo mūsu piecās tīmekļa vietnēs ir pieejams no atvērtā interneta, un tas nav izņēmums, bet normāls gadījums: kas piedāvā pakalpojumu, veikalu vai klientu pieteikšanos, tam ir publisks serveris. Pietiek ar vienu neaizsargātu paroli, aizmirstu konfigurācijas failu vai pārlieku devīgu atļauju, lai no publiska servera kļūtu atvērts.

Šis raksts parāda, kā pareizi nodrošināt Odoo 19 — nevis ar vienu pasākumu, bet ar vairākiem slāņiem, kas viens otru papildina: ugunsmūris un reversais starpniekserveris, mūsu atvērtā koda modulis Web RBL, divfaktoru autentifikācija, paroļu politika un atļaujas — un kādus uzbrukuma mēģinājumus katrs no tiem patiešām aptur. Beigās ir soli pa solim instrukcija, pēc kuras var uzlabot jebkuru savu Odoo instalāciju.

Aizsardzība dziļumā: kāpēc viens pasākums nekad nepietiek

Katram atsevišķam drošības pasākumam ir sava robs. Ugunsmūris neredz, kas notiek Odoo pieteikšanās formā. Stipra parole neaizsargā, ja tā jau ir nozagta citur. Atļauju struktūra neko nelīdz pret uzbrucēju, kas vēl vispār nav pieteicies. Princips, kas šos robus aizver, saucas aizsardzība dziļumā (defense in depth): vairāki neatkarīgi slāņi, no kuriem katru atsevišķi varētu apiet — bet visus kopā tieši ne.

Pie mums ir četri slāņi, katram cits uzdevums:

• Ugunsmūris / reversais starpniekserveris — notur prom acīmredzami ļaunprātīgo, pirms tas vispār sasniedz serveri
• Web RBL — savieno abas puses: Odoo no sava lietojumprogrammas žurnāla uzzina to, ko ugunsmūris vispār nevar redzēt, un nodod to atpakaļ ugunsmūrim
• Pats Odoo — divfaktoru autentifikācija, paroļu politika, atļaujas, sesiju pārvaldība
• Datubāze & ekspluatācija — rezerves kopijas, pārvaldības piekļuves aizsardzība, noslēpumi ārpus jebkura žurnāla

Turpmākajās sadaļās katrs slānis tiek apskatīts atsevišķi.

1. slānis: ugunsmūris un reversais starpniekserveris

Ugunsmūris ir pirmā instance, kas redz pieprasījumu, un vienīgā, kas var noturēt uzbrucēju prom no jebkura servera pakalpojuma — ne tikai no tīmekļa vietnes, bet arī no pasta servera, VPN piekļuves un pašas pārvaldības saskarnes. Ko šajā vietā lietderīgi aktivizēt, atkarīgs no ražotāja, bet pamatveidi OPNsense, pfSense, HAProxy, FortiGate, Sophos vai Check Point gadījumā ir vieni un tie paši:

RBL saraksti: standarta ceļš, pa kuru tiek piegādāta reputācija

RBL nozīmē Real-time Blackhole List, jēdziens no e-pasta pasaules: viena adrese rindā, pieejama pa HTTP, regulāri ielādēta no jauna. Praktiski katrs ugunsmūris var nolasīt šādu sarakstu un izveidot no tā noteikumus — OPNsense un pfSense kā URL Table Alias, HAProxy kā ACL fails, FortiGate kā External Block List, Palo Alto kā External Dynamic List, Cisco, Sophos, Juniper un MikroTik ar saviem nosaukumiem tam pašam principam.

Tieši šeit iesaistās mūsu pašu modulis — un tieši šeit sākas otrais slānis.

2. slānis: Web RBL — tilts starp lietojumprogrammu un ugunsmūri

Ugunsmūris redz paketes, nevis lietojumprogrammas loģiku. Tas nezina, ka pieprasījums uz /xmlrpc/2/common ir pieteikšanās mēģinājums, ka divdesmit dažādi ceļi četrpadsmit sekundēs ir skeneris vai ka kāda adrese tikko veiksmīgi uzminēja paroli. To visu zina tikai pats Odoo. Web RBL, mūsu pašu atvērtā koda modulis (AGPL-3), padara šīs zināšanas izmantojamas — pašam Odoo un, kā RBL sarakstu piegādājot, arī ugunsmūrim tā priekšā.

Apdraudējumu saraksti tiek pastāvīgi salīdzināti, katram sava pakāpe.

Īsi apkopojot, kas iepriekšējā rakstā aprakstīts detalizēti:

• Šablonu atpazīšana ceļos: .env faili, .git direktorijas, konfigurācijas faili, WordPress un PHP zondes, ceļa traversēšana, komandu izpilde caur jaunām MI saskarnēm
• Pieteikšanās aizsardzība, kas skaita arī pāri restartēšanām — atšķirībā no paša Odoo skaitītāja, kas dzīvo operatīvajā atmiņā
• Katras adreses vērtējums no 0 līdz 100 ar pamatojumu vienkāršā tekstā
• Kļūdainas konfigurācijas (QNAP, Autodiscover, Synology) tiek atpazītas un nekad netiek bloķētas, jo bloķēšana defektu neizlabo, bet tikai slēpj
• Svešie apdraudējumu saraksti, piemēram, Spamhaus, FireHOL un Tor izejas mezgli, tiek pastāvīgi salīdzināti
• Baltais saraksts adresēm, kas nekad nav jābloķē

Šim rakstam divas īpašības ir īpaši svarīgas, jo tās tieši saistītas ar ugunsmūri un pieteikšanos.

Inerts saraksts ir saraksts, kuram var uzticēties

Baltais saraksts — adreses, kas nekad netiek bloķētas, piemēram, pašu filiāļu pieslēgumi — parasti mainās reti. Tieši tā ir tā vērtība, nevis trūkums: ja mierīgs saraksts dienām ilgi gandrīz nekustas, katra reta izmaiņa uzreiz krīt acīs. Ikdienas automātiskā atjaunināšana pastāv nevis tāpēc, ka daudz kas mainītos, bet lai reta izmaiņa nebūtu jāpievieno ar roku — un tieši tur to aizmirst. Viena no mūsu pašu kļūdainajām konfigurācijām pagājušajā mēnesī tika pamanīta tieši tā: ne caur daudziem notikumiem, bet caur to vienu, ko neviens nepazina, līdz kāda klienta QNAP tīmekļa API tika kļūdaini bloķēts. Kopš tā laika QNAP ir kļūdainu konfigurāciju sarakstā, kuras nekad netiek bloķētas, bet tikai paziņotas.

Pieteikšanās ir vieta, ko ugunsmūris neredz

Ugunsmūris var bloķēt adresi. Tas nevar zināt, vai pieteikšanās ir izdevusies, un jo vairāk ne to, vai tā nāca no adreses, kas īsi pirms tam vēl meklēja piekļuves datus. Web RBL to var: vērtējums no iestatāma sliekšņa pieteikšanos aizliedz pavisam, un veiksmīga pieteikšanās no aizdomīgas adreses tiek paziņota — tā ir saikne ar nākamo slāni.

3. slānis: paša Odoo nodrošināšana

Divfaktoru autentifikācija: otrs noslēpums, ko nevar izmantot atkārtoti

Lielākā paroļu problēma nav to kvalitāte, bet atkārtota izmantošana. Parole, kas nozagta citā pakalpojumā, pie mums darbojas tieši tāpat, kamēr tā ir tā pati. Divfaktoru autentifikācija (2FA, saukta arī par TOTP) tam pretī liek otru noslēpumu: sešciparu kodu, kas mainās ik pēc trīsdesmit sekundēm un tiek aprēķināts no noslēpuma, ko zina tikai paša viedtālrunis. Ar nozagtu paroli vien tad vairs nepietiek.

Odoo 19 Community to ietver jau iebūvēti — kā instalējamu moduli Two-Factor Authentication (TOTP), papildinātu ar e-pasta rezerves iespēju. Katrs lietotājs to iestata pats sev, ar QR kodu, ar jebkuru izplatītu Authenticator lietotni:

Iestatīšana: noskenēt QR kodu, vienreiz apstiprināt sešciparu kodu, gatavs.

Taču tas palīdz tikai tiem, kas to iestata paši — un pieredze rāda, ka bez piespiešanas tie paliek mazākums. Tāpēc Odoo piedāvā piespiedu politiku: vai nu tikai darbiniekiem (iekšējiem lietotājiem), vai visiem, ieskaitot portāla lietotājus. Bez iestatīta otra noslēpuma neviens vairs netiek garām pieteikšanās formai, to vismaz neapstiprinot ar e-pasta kodu.

Paroļu politika: minimālais garums nav pašsaprotams

Bez papildu moduļa Odoo Community uz minimālo paroļu garumu nebalstās — lietotājs var iestatīt trīs rakstzīmju paroli, ja viņu neviens no tā neattur. Paša Password Policy modulis aizver tieši šo robu: minimālais garums, kas tiek nodrošināts servera pusē, nevis tikai ieteikts pārlūkā. Kas vēlas vairāk — piespiedu derīguma termiņu, vēsturi pret atkārtotu izmantošanu — tam vajadzīgs OCA vai trešās puses modulis; Community versijā tas ir apzināti turēts vienkāršs.

Atļaujas: piekļuvi saņem tikai tas, kam tā vajadzīga

Odoo no paša sākuma nodala trīs līmeņus: portāla lietotāji (tikai savs klientu vai piegādātāju portāls), iekšējie lietotāji (backend ar tiesībām katrai lietojumprogrammai) un administratori (neierobežota piekļuve, ieskaitot tehniskos iestatījumus). Biežākā kļūda nav pārāk vāja parole, bet pārāk devīgi piešķirta administratora loma: kam jāveido tikai rēķini, tam nevajag piekļuvi sistēmas iestatījumiem.

Lielāko slodzi nes divi principi:

Abus var pārbaudīt tajā pašā skatā, kurā tiek iestatīta arī divfaktoru autentifikācija:

Viens pārskats, četras sviras: parole, otrais faktors, API atslēgas, pieteiktās ierīces.

Sesijas un ierīces: kas šobrīd ir pieteicies

Tas pats skats parāda arī to, no kurām ierīcēm konts šobrīd ir pieteicies — un ļauj atteikties no vienas vai visām uzreiz. Pēc pazaudēta klēpjdatora vai aizdomām par kompromitētu paroli tas ir ātrākais efektīvais solis: sesija beidzas nekavējoties, neatkarīgi no tā, vai parole jau ir nomainīta.

4. slānis: datubāze un ekspluatācija

Ceturtais slānis ir vismazāk redzamais un reizē visneatlaidīgākais, jo kļūda šeit var iznīcināt visu iepriekš uzbūvēto.

• Regulāras, pārbaudītas rezerves kopijas, glabātas atsevišķi no paša servera. Rezerves kopija, kas nekad nav atjaunota, ir pieņēmums, nevis rezerves kopija.
• Noslēpumiem nav vietas nevienā žurnāla failā. Paroles, API atslēgas, licences dati — kas raksta savus paplašinājumus, tam tie jāapstrādā tāpat kā pati galvenā parole: nekur nereģistrēt, arī ne “tikai atkļūdošanai”.
• Turēt moduļus aktuālus, arī un tieši trešo pušu moduļus. Brīvie papildu moduļi (OCA un citi) dabiski atpaliek no jaunām Odoo versijām; pirms katras instalēšanas ir vērts paskatīties, kādas atkarības tiek ieliktas automātiski.

Pieteikšanās ceļš kopumā

Četri slāņi neiedarbojas pēc kārtas atsevišķās telpās, bet uz viena un tā paša pieprasījuma, posms pa posmam. Visskaidrāk to var redzēt uz pieteikšanās piemēra:

Piecas vietas, kurās ļaunprātīgs pieprasījums var beigties, pirms tas sasniedz īsto mērķi — un tikai viena, kurā likumīgs lietotājs tās visas iziziet.

Uzbrukumu scenāriji un to atvairīšana

Turpmākais pārskats sasaista reālus uzbrukumu šablonus ar slāņiem, kas tos patiešām aptur. Vairāki no tiem nav teorija, bet mūsu pašu novērojumi septiņpadsmit dienu reālās datplūsmas mūsu piecās tīmekļa vietnēs.

Soli pa solim: pašu Odoo instalācijas nodrošināšana

Turpmākā secība ir tā, kādā mēs paši rīkotos — no lielākās ietekmes līdz smalkākajam iestatījumam.

1. Ieviest divfaktoru autentifikāciju kā obligātu

1. Ja vēl nav instalēts: atvērt Apps, meklēt “Two-Factor Authentication” un instalēt (vairāku tīmekļa vietņu gadījumā papildus ieteicams “Two-Factor Authentication by Mail” kā rezerves iespēja).
2. Atvērt Iestatījumi → Vispārīgie iestatījumi → Atļaujas.
3. Aktivizēt “Obligāta divfaktoru autentifikācija”.
4. Izvēlēties politiku: “Tikai darbinieki” iekšējiem lietotājiem, “Visi lietotāji”, ja jāiekļauj arī portāla lietotāji (klienti ar piekļuvi).
5. Saglabāt. No nākamā pieteikšanās mēģinājuma Odoo no katra lietotāja bez iestatīta otra noslēpuma prasīs vismaz e-pasta kodu, līdz viņš ir iestatījis Authenticator lietotni.

2. Noteikt minimālo paroļu garumu

1. Atvērt Apps, meklēt “Password Policy” un instalēt.
2. Atvērt Iestatījumi → Vispārīgie iestatījumi → Atļaujas.
3. Iestatīt “Minimālais paroles garums” — divpadsmit rakstzīmes ir saprātīga sākumvērtība.
4. Saglabāt. Noteikums ir spēkā no šī brīža katrai jaunai vai mainītai paroles piešķiršanai, ar atpakaļejošu spēku neattiecas uz esošajām parolēm.

3. Pārskatīt atļaujas

1. Atvērt Iestatījumi → Lietotāji & uzņēmumi → Lietotāji.
2. Atvērt katru lietotāju atsevišķi un pārbaudīt cilni ar piekļuves tiesībām katrai lietojumprogrammai: vai šai personai patiešām vajag “Pārvaldnieku” vai “Administratoru”, vai pietiek ar “Lietotājs”?
3. Īpaši pārbaudīt: kam ir piekļuve pašiem “Iestatījumiem”? Tai jābūt ļoti mazai grupai.
4. Katram ārējam pieslēgumam (grāmatvedība, pašu skripti, laika uzskaite) attiecīgā tehniskā lietotāja cilnē “Konta drošība” izveidot savu API atslēgu, nevis nodot tālāk lietotāja paroli.

4. Instalēt Web RBL un novērot, pirms ieslēgt aktīvi

1. Moduli no github.com/Alex0176/odoo-web-rbl ievietot addon ceļā un instalēt.
2. Dažas dienas novērot: izvēlne Web RBL → Izvērtējums parāda, kuri šabloni patiešām tiek aktivizēti.
3. Tikai pēc tam ieslēgt web_rbl.sperren_aktiv (Iestatījumi → Tehniskie → Sistēmas parametri) — no šī brīža atpazītās zondes tiešām tiek noraidītas.
4. Bloķēšanas sarakstu pa modulī norādīto, ar token aizsargāto adresi iekļaut ugunsmūrī kā RBL sarakstu (OPNsense/pfSense gadījumā kā URL Table Alias, HAProxy gadījumā kā ACL failu).

5. Nodrošināt pašu ugunsmūri

1. Ugunsmūra pārvaldības saskarni padarīt pieejamu tikai no iekšējā tīkla, nekad ne pa to pašu publisko adresi kā tīmekļa vietni.
2. Aktivizēt automātiskos drošības atjauninājumus ugunsmūra programmatūrai, ja ražotājs tos piedāvā.
3. Pārbaudīt TLS konfigurāciju: tikai aktuālās protokola versijas, novecojušos šifrēšanas algoritmus deaktivizēt.
4. Ja ir pieejams: zināmu reputācijas sarakstu (piemēram, Spamhaus DROP) iekļaut tieši ugunsmūrī — neatkarīgi no Web RBL, jo tā ugunsmūris redz arī datplūsmu uz pakalpojumiem, ko Odoo nekad nesasniedz.

6. Aizvērt datubāzu pārvaldību

1. Pārbaudīt, vai /web/database/manager ir sasniedzams no ārpuses — ja jā, Odoo konfigurācijā iestatīt list_db = False vai bloķēt ceļu ugunsmūra līmenī.
2. Datubāzu pārvaldības galveno paroli iestatīt garu un nejaušu un nekur nepierakstīt vietā, ko varētu izlasīt kāds cits.

7. Pārbaudīt rezerves kopiju, ne tikai to iestatīt

1. Iestatīt automātisku, regulāru rezerves kopiju, glabātu atsevišķi no Odoo servera.
2. Vismaz vienu reizi to patiešām atjaunot un pārbaudīt, vai atjaunošana darbojas — nepārbaudīta rezerves kopija ir pieņēmums.

Neviens no šiem soļiem neaizstāj nevienu citu. Kas īsteno tikai vienu no tiem, ir nostiprinājis vienas durvis un atstājis visas pārējās atvērtas — kas īsteno visus septiņus, tam ir aizsardzība, kas turas pat tad, ja viens slānis atsakās.

Ko šī arhitektūra neaizstāj

Neviens no aprakstītajiem pasākumiem nepadara rūpību lieku. Modulis, kas noraida .env zondes, nepadara nekaitīgu kļūdaini publicētu .env failu. Divfaktoru autentifikācija neaizsargā pret lietotāju, kas savu kodu nolasa zvanītājam pa tālruni. Un ugunsmūris neaizstāj lēmumu par to, kam kāda atļauja patiešām vajadzīga. Drošības arhitektūra rada apstākļus, kuros atsevišķa kļūda uzreiz nekļūst par incidentu — tā nevienu neatbrīvo no rūpības.

Biežāk uzdotie jautājumi

Vai ar stipru paroli pietiek, lai nodrošinātu Odoo 19?

Nē. Paroli var nozagt citur, pilnīgi neatkarīgi no tās kvalitātes, un tad tā darbojas katrā pakalpojumā, kas pieņem to pašu paroli. Tikai kombinācija ar divfaktoru autentifikāciju, ugunsmūri tās priekšā un saprātīgu atļauju struktūru dod aizsardzību, kas turas arī pēc nozagtas paroles.

Kā aktivizēt divfaktoru autentifikāciju Odoo 19?

Moduli “Two-Factor Authentication (TOTP)” instalēt ar Apps pārvaldību, pēc tam sadaļā Iestatījumi → Vispārīgie iestatījumi → Atļaujas aktivizēt obligātumu un izvēlēties starp “Tikai darbinieki” un “Visi lietotāji”. Katrs lietotājs pēc tam iestata savu otro faktoru ar QR kodu.

Kas ir RBL saraksts un kāpēc tas vajadzīgs Odoo?

RBL (Real-time Blackhole List) ir pa HTTP pieejams adrešu saraksts, ko var nolasīt praktiski katrs ugunsmūris. Pats Odoo tādu sarakstu nepiegādā — mūsu modulis Web RBL šo robu aizver, atpazīstot uzbrukumu datplūsmu no paša lietojumprogrammas žurnāla un nododot to kā RBL sarakstu atpakaļ priekšā esošajam ugunsmūrim.

Vai Odoo 19 Community bez papildu moduļiem ir pietiekami nodrošināts?

Ne pilnībā. Bez moduļa Password Policy nav minimālā paroļu garuma, bez Two-Factor Authentication nav otrā faktora, un bez tāda moduļa kā Web RBL Odoo neatpazīst ne zondēšanas mēģinājumus, ne atkārtotus pieteikšanās mēģinājumus pāri restartēšanai. Visus četrus var bez maksas pieslēgt papildus.

Pieejamība

Web RBL ir publiski pieejams ar AGPL-3 licenci un mums darbojas produktīvi piecās tīmekļa vietnēs:

github.com/Alex0176/odoo-web-rbl

Pilns funkciju apraksts ar visiem šabloniem, vērtējumu un apdraudējumu sarakstiem ir iepriekšējā rakstā: Web RBL – bloķēšanas saraksts uzbrukumu datplūsmai uz pašu tīmekļa vietnēm.

Jautājumus, piezīmes un kļūdu ziņojumus mēs labprāt pieņemam — vislabāk kā issue GitHub.