Arkitektura e sigurisë së Odoo 19: si të kombinohen drejt firewall, 2FA, të drejtat dhe Web RBL

Odoo është i arritshëm nga interneti i hapur në pesë faqet tona, dhe kjo nuk është përjashtim, por rasti normal: kush operon një ofertë, një dyqan ose një hyrje klientësh, ka një server publik. Mjafton një fjalëkalim i vetëm i cenueshëm, një skedar konfigurimi i harruar ose një e drejtë shumë bujare, që një server publik të bëhet i hapur.

Ky artikull tregon se si mund ta siguroni Odoo 19 siç duhet — jo me një masë të vetme, por me disa shtresa që plotësojnë njëra-tjetrën: firewall dhe reverse proxy, moduli ynë me kod të hapur Web RBL, vërtetimi dyfaktorësh, politika e fjalëkalimeve dhe të drejtat — dhe cilat tentativa sulmi kap në fakt secila prej tyre. Në fund vjen një udhëzim hap pas hapi, me të cilin mund të përmirësohet çdo instalim i vetë i Odoo-s.

Mbrojtje në thellësi: pse një masë e vetme nuk mjafton kurrë

Çdo masë sigurie e vetme ka një boshllëk. Një firewall nuk sheh çfarë ndodh në një formular hyrjeje të Odoo-s. Një fjalëkalim i fortë nuk mbron nëse është vjedhur tashmë diku tjetër. Një strukturë të drejtash nuk ndihmon kundër një sulmuesi që ende nuk është identifikuar fare. Parimi që mbyll këto boshllëqe quhet mbrojtje në thellësi (defense in depth): disa shtresa të pavarura, secila prej të cilave veçmas do të ishte e anashkalueshme — por të gjitha së bashku jo.

Te ne janë katër shtresa, secila me një detyrë tjetër:

• Firewall / reverse proxy — mban larg çdo gjë të dukshme keqdashëse përpara se të arrijë fare te serveri
• Web RBL — lidh të dyja palët: Odoo mëson nga protokolli i vet i aplikacionit atë që firewall-i nuk mund ta shohë fare, dhe ia kthen atij
• Vetë Odoo — vërtetimi dyfaktorësh, politika e fjalëkalimeve, të drejtat, administrimi i sesioneve
• Baza e të dhënave & operimi — kopje rezervë, mbrojtja e qasjes në administrim, sekrete jashtë çdo protokolli

Seksionet në vijim i trajtojnë shtresat një nga një.

Shtresa 1: Firewall dhe reverse proxy

Firewall-i është instanca e parë që sheh një kërkesë, dhe e vetmja që mund ta mbajë një sulmues larg nga çdo shërbim në server — jo vetëm nga faqja, por edhe nga serveri i postës, nga qasja VPN dhe nga ndërfaqja e vet e administrimit. Çfarë aktivizohet me kuptim në këtë vend varet nga prodhuesi, por format e ndërtimit janë të njëjta te OPNsense, pfSense, HAProxy, FortiGate, Sophos ose Check Point:

Listat RBL: rruga standarde me të cilën shpërndahet reputacioni

RBL do të thotë Real-time Blackhole List, një term nga bota e postës: një adresë në çdo rresht, e marrshme nëpërmjet HTTP, e ringarkuar rregullisht. Praktikisht çdo firewall mund ta lexojë një listë të tillë dhe të ndërtojë rregulla prej saj — OPNsense dhe pfSense si URL Table Alias, HAProxy si skedar ACL, FortiGate si External Block List, Palo Alto si External Dynamic List, Cisco, Sophos, Juniper dhe MikroTik me emra të vetë për të njëjtin parim.

Pikërisht këtu fillon moduli ynë — dhe pikërisht këtu fillon shtresa e dytë.

Shtresa 2: Web RBL — ura midis aplikacionit dhe firewall-it

Një firewall sheh paketa, jo logjikë aplikacioni. Nuk di që një kërkesë për /xmlrpc/2/common është një tentativë hyrjeje, që njëzet shtigje të ndryshme brenda katërmbëdhjetë sekondave janë një skaner, ose që një adresë sapo ka hamendësuar me sukses një fjalëkalim. Gjithë këtë e di vetëm Odoo. Web RBL, moduli ynë me kod të hapur (AGPL-3), e bën këtë njohuri të përdorshme — për vetë Odoo-n dhe, i shpërndarë si listë RBL, edhe për firewall-in përpara tij.

Listat e kërcënimeve të krahasuara vazhdimisht, secila me nivel të vetin.

Shkurt përmbledhur, ajo që përshkruhet gjerësisht në artikullin e mëparshëm:

• Njohja e modeleve në shtigje: skedarë .env, drejtori .git, skedarë konfigurimi, sonda WordPress dhe PHP, path traversal, ekzekutim komandash nëpërmjet ndërfaqeve të reja të inteligjencës artificiale
• Mbrojtje nga hyrjet që numëron përtej rinisjeve — ndryshe nga numruesi i vetë Odoo-s që jeton në kujtesë
• Vlerësimi i çdo adrese nga 0 deri në 100, me arsyetim në tekst të qartë
• Konfigurime të gabuara (QNAP, Autodiscover, Synology) njihen dhe nuk bllokohen kurrë, sepse një bllokim nuk e zgjidh defektin, por vetëm e fsheh
• Lista të huaja kërcënimesh si Spamhaus, FireHOL dhe nyje dalëse të Tor, të krahasuara vazhdimisht
• Lista e lirë për adresa që nuk duhet të bllokohen kurrë

Për këtë artikull dy veti janë veçanërisht të rëndësishme, sepse lidhen drejtpërdrejt me firewall-in dhe me hyrjen.

Një listë e ngadaltë është një listë që mund t’i besohet

Lista e lirë — adresa që nuk bllokohen kurrë, për shembull lidhjet e vetë të lokacioneve — ndryshon zakonisht rrallë. Pikërisht kjo është vlera e saj, jo mangësia: kur një listë e qetë pothuajse nuk lëviz me ditë të tëra, çdo ndryshim i rrallë bie menjëherë në sy. Përditësimi automatik i përditshëm nuk ekziston sepse do të ndryshonte shumë, por që ndryshimi i rrallë të mos duhet të shtohet me dorë — dhe pikërisht kjo është pika ku e harron njeriu. Një nga konfigurimet tona të gabuara muajin e kaluar u vu re pikërisht kështu: jo nga shumë ngjarje, por nga ajo e vetme që askush nuk e njihte, deri sa API-ja e uebit QNAP e një klienti u bllokua gabimisht. Që atëherë QNAP është në listën e konfigurimeve të gabuara që nuk bllokohen kurrë, por vetëm raportohen.

Hyrja është vendi që një firewall nuk e sheh

Një firewall mund të bllokojë një adresë. Nuk mund të dijë nëse një hyrje ka ia dalë, e aq më pak nëse erdhi nga një adresë që pak më parë kërkonte ende të dhëna hyrjeje. Web RBL po: një vlerësim nga një prag i rregullueshëm e tutje e ndalon hyrjen plotësisht, dhe një hyrje e suksesshme nga një adresë e dyshimtë raportohet — ky është hallka lidhëse me shtresën tjetër.

Shtresa 3: Sigurimi i vetë Odoo-s

Vërtetimi dyfaktorësh: një sekret i dytë që nuk ripërdoret

Problemi më i madh i fjalëkalimeve nuk është cilësia e tyre, por ripërdorimi. Një fjalëkalim i vjedhur te një shërbim tjetër funksionon edhe te ne njësoj, për sa kohë është i njëjti. Vërtetimi dyfaktorësh (2FA, i quajtur edhe TOTP) i kundërvihet kësaj me një sekret të dytë: një kod gjashtëshifror që ndryshon çdo tridhjetë sekonda dhe llogaritet nga një sekret që e njeh vetëm smartfoni i vetë. Një fjalëkalim i vjedhur më nuk mjafton vetëm.

Odoo 19 Community e ka të integruar këtë — si modul të instalueshëm Two-Factor Authentication (TOTP), i plotësuar me një opsion rezervë me e-mail. Çdo përdorues e vendos vetë për vete, me kod QR, me çdo aplikacion të zakonshëm autentifikimi:

Vendosja: skanoni kodin QR, konfirmoni një herë kodin gjashtëshifror, gati.

Kjo ndihmon vetëm ata që e vendosin vetë — dhe përvoja tregon se pa detyrim kjo mbetet pakicë. Prandaj Odoo ka një politikë detyrimi: ose vetëm për punonjësit (përdorues të brendshëm) ose për të gjithë, përfshirë përdoruesit e portalit. Pa një sekret të dytë të vendosur askush nuk e kalon më formularin e hyrjes pa e konfirmuar të paktën me një kod me e-mail.

Politika e fjalëkalimeve: një gjatësi minimale nuk është e vetëkuptueshme

Pa modul shtesë, Odoo Community nuk mbështetet në asnjë gjatësi minimale për fjalëkalimet — një përdorues mund të vendosë një fjalëkalim me tre karaktere, nëse askush nuk e pengon. Moduli Password Policy mbyll pikërisht këtë boshllëk: një gjatësi minimale që zbatohet nga ana e serverit, jo vetëm sugjerohet në shfletues. Kush dëshiron më shumë — një afat skadimi të detyruar, një histori kundër ripërdorimit — ka nevojë për një modul OCA ose të palës së tretë; kjo është mbajtur qëllimisht e thjeshtë në versionin Community.

Të drejtat: qasje merr vetëm kush e ka nevojë

Odoo ndan që në origjinë tri nivele: përdorues portali (vetëm portali i vet i klientit ose i furnizuesit), përdorues të brendshëm (backend-i, me të drejta për çdo aplikacion) dhe administratorë (qasje e pakufizuar përfshirë cilësimet teknike). Gabimi më i shpeshtë nuk është një fjalëkalim shumë i dobët, por një rol administratori i dhënë shumë bujarisht: kush duhet vetëm të krijojë fatura, nuk ka nevojë për qasje në cilësimet e sistemit.

Dy parime mbajnë pjesën më të madhe të ngarkesës:

Të dyja mund të kontrollohen në të njëjtën pamje ku vendoset edhe vërtetimi dyfaktorësh:

Një përmbledhje, katër levë: fjalëkalimi, faktori i dytë, çelësat API, pajisjet e identifikuara.

Sesionet dhe pajisjet: kush është i identifikuar tani

E njëjta pamje tregon edhe nga cilat pajisje është i identifikuar tani një llogari — dhe lejon të shkëputet një e vetme ose të gjitha njëherësh. Pas një laptopi të humbur ose dyshimit për një fjalëkalim të komprometuar, ky është hapi më i shpejtë efektiv: sesioni mbaron menjëherë, pavarësisht nëse fjalëkalimi është ndryshuar tashmë.

Shtresa 4: Baza e të dhënave dhe operimi

Shtresa e katërt është më pak e dukshmja dhe njëkohësisht më e pafalshmja, sepse një gabim këtu mund ta shkatërrojë gjithçka të ndërtuar më parë.

• Kopje rezervë të rregullta dhe të kontrolluara, të ruajtura veçmas nga vetë serveri. Një kopje rezervë që nuk është rikthyer kurrë është një supozim, jo një kopje rezervë.
• Sekretet nuk i përkasin asnjë skedari protokolli. Fjalëkalime, çelësa API, të dhëna licence — kush shkruan zgjerime të veta, duhet t’i trajtojë ashtu si vetë fjalëkalimin kryesor: të mos i regjistrojë askund, as „vetëm për debugging“.
• Modulet të mbahen të përditësuara, edhe e sidomos modulet e palëve të treta. Modulet e lira shtesë (OCA dhe të tjera) ngelen natyrshëm pas versioneve të reja të Odoo-s; para çdo instalimi ia vlen një vështrim se cilat varësi vijnë automatikisht.

Rruga e hyrjes në tërësi

Katër shtresat nuk veprojnë njëra pas tjetrës në dhoma të ndara, por mbi të njëjtën kërkesë, hap pas hapi. Në shembullin e një hyrjeje kjo duket më qartë:

Pesë vende ku një kërkesë keqdashëse mund të përfundojë para se të arrijë te objektivi i vërtetë — dhe vetëm një ku një përdorues i autorizuar i kalon të gjitha.

Skenarë sulmesh dhe mbrojtja ndaj tyre

Përmbledhja në vijim i përshtat modelet reale të sulmeve me shtresat që i ndalojnë në të vërtetë. Disa prej tyre nuk janë teori, por vëzhgime të veta nga shtatëmbëdhjetë ditë trafiku real në pesë faqet tona.

Hap pas hapi: sigurimi i instalimit tuaj të Odoo-s

Radha në vijim është ajo me të cilën do të vepronim vetë — nga efekti më i madh te cilësimi më i imët.

1. Detyrimi i vërtetimit dyfaktorësh

1. Nëse nuk është instaluar ende: hapni Apps, kërkoni „Two-Factor Authentication“ dhe instalojeni (me disa faqe rekomandohet përveç kësaj „Two-Factor Authentication by Mail“ si opsion rezervë).
2. Hapni Cilësimet → Cilësimet e përgjithshme → Të drejtat.
3. Aktivizoni „Detyro vërtetimin dyfaktorësh“.
4. Zgjidhni politikën: „Vetëm punonjësit“ për përdorues të brendshëm, „Të gjithë përdoruesit“ nëse duhen përfshirë edhe përdoruesit e portalit (klientë me qasje).
5. Ruani. Që nga tentativa e radhës e hyrjes, Odoo kërkon nga çdo përdorues pa sekret të dytë të vendosur të paktën kodin me e-mail, derisa të ketë vendosur aplikacionin e autentifikimit.

2. Caktimi i një gjatësie minimale për fjalëkalimet

1. Hapni Apps, kërkoni „Password Policy“ dhe instalojeni.
2. Hapni Cilësimet → Cilësimet e përgjithshme → Të drejtat.
3. Vendosni „Gjatësia minimale e fjalëkalimit“ — dymbëdhjetë karaktere janë një vlerë fillestare e arsyeshme.
4. Ruani. Rregulli vlen që tani për çdo caktim ose ndryshim të ri fjalëkalimi, jo me efekt prapaveprues për fjalëkalimet ekzistuese.

3. Shqyrtimi i të drejtave

1. Hapni Cilësimet → Përdoruesit & kompanitë → Përdoruesit.
2. Hapni çdo përdorues veçmas dhe kontrolloni skedën me të drejtat e qasjes për çdo aplikacion: A ka vërtet nevojë ky person për „Menaxher“ ose „Administrator“, apo mjafton „Përdorues“?
3. Kontrolloni veçanërisht: Kush ka qasje në „Cilësimet“ vetë? Kjo duhet të jetë një grup shumë i vogël.
4. Për çdo lidhje të jashtme (kontabilitet, skripte të veta, regjistrim kohe) krijoni në skedën „Siguria e llogarisë“ të përdoruesit përkatës teknik një çelës API të veçantë, në vend që të jepet fjalëkalimi i përdoruesit.

4. Instalimi i Web RBL dhe vëzhgimi para se të vihet në veprim

1. Moduli nga github.com/Alex0176/odoo-web-rbl vendoset në shtegun e addon-eve dhe instalohet.
2. Vëzhgoni disa ditë: menyja Web RBL → Analiza tregon cilat modele veprojnë në të vërtetë.
3. Vetëm pas kësaj aktivizoni web_rbl.sperren_aktiv (Cilësimet → Teknik → Parametrat e sistemit) — nga këtu sondat e njohura refuzohen vërtet.
4. Lista e bllokimit lidhet me firewall-in si listë RBL, në adresën e dhënë në modul dhe të mbrojtur me token (te OPNsense/pfSense si URL Table Alias, te HAProxy si skedar ACL).

5. Sigurimi i vetë firewall-it

1. Ndërfaqja e administrimit të firewall-it të bëhet e arritshme vetëm nga rrjeti i brendshëm, kurrë nga e njëjta adresë publike si faqja.
2. Aktivizoni përditësimet automatike të sigurisë për softuerin e firewall-it, nëse prodhuesi e ofron.
3. Kontrolloni konfigurimin TLS: vetëm versione aktuale protokollesh, çaktivizoni procedurat e vjetruara të enkriptimit.
4. Nëse disponohet: lidhni një listë të njohur reputacioni (p.sh. Spamhaus DROP) drejtpërdrejt në firewall — pavarësisht nga Web RBL, sepse firewall-i sheh kështu edhe trafikun drejt shërbimeve që Odoo nuk i arrin kurrë.

6. Mbyllja e administrimit të bazës së të dhënave

1. Kontrolloni nëse /web/database/manager është i arritshëm nga jashtë — nëse po, në konfigurimin e Odoo-s vendosni list_db = False ose bllokoni shtegun në nivel firewall-i.
2. Fjalëkalimin kryesor të administrimit të bazës së të dhënave vendoseni të gjatë dhe të rastësishëm dhe mos e shënoni në asnjë vend që mund ta lexojë dikush tjetër.

7. Kontrolloni kopjen rezervë, mos e vendosni vetëm

1. Vendosni një kopje rezervë automatike dhe të rregullt, të ruajtur veçmas nga serveri i Odoo-s.
2. Rikthejeni realisht të paktën një herë dhe kontrolloni nëse rikthimi funksionon — një kopje rezervë e pakontrolluar është një supozim.

Asnjë nga këto hapa nuk zëvendëson tjetrin. Kush zbaton vetëm një prej tyre, ka përforcuar një derë dhe ka lënë të hapura të gjitha të tjerat — kush i zbaton të shtatë, ka një mbrojtje që qëndron edhe kur një shtresë e vetme dështon.

Çfarë nuk zëvendëson kjo arkitekturë

Asnjë nga masat e përshkruara nuk e bën kujdesin të tepërt. Një modul që refuzon sondat .env nuk e bën të padëmshëm një skedar .env të publikuar gabimisht. Vërtetimi dyfaktorësh nuk mbron nga një përdorues që ia lexon kodin e vet një telefonuesi. Dhe një firewall nuk zëvendëson vendimin se kush ka vërtet nevojë për cilën të drejtë. Arkitektura e sigurisë krijon kushtet nën të cilat një gabim i vetëm nuk bëhet menjëherë incident — por nuk ia heq askujt kujdesin.

Pyetje të shpeshta

A mjafton një fjalëkalim i fortë për të siguruar Odoo 19?

Jo. Një fjalëkalim mund të vidhet diku tjetër, krejtësisht pavarësisht cilësisë së tij, dhe pastaj funksionon te çdo shërbim që pranon të njëjtin fjalëkalim. Vetëm kombinimi me vërtetim dyfaktorësh, një firewall përpara dhe një strukturë të arsyeshme të drejtash jep një mbrojtje që qëndron edhe pas një fjalëkalimi të vjedhur.

Si e aktivizoj vërtetimin dyfaktorësh në Odoo 19?

Instaloni modulin „Two-Factor Authentication (TOTP)“ nga administrimi i Apps, pastaj te Cilësimet → Cilësimet e përgjithshme → Të drejtat aktivizoni detyrimin dhe zgjidhni mes „Vetëm punonjësit“ dhe „Të gjithë përdoruesit“. Çdo përdorues vendos më pas faktorin e vet të dytë me kod QR.

Çfarë është një listë RBL dhe pse e ka nevojë Odoo?

RBL (Real-time Blackhole List) është një listë adresash e marrshme nëpërmjet HTTP që praktikisht çdo firewall mund ta lexojë. Vetë Odoo nuk ofron një listë të tillë — moduli ynë Web RBL e mbyll këtë boshllëk, duke njohur trafikun sulmues nga protokolli i vet i aplikacionit dhe duke ia kthyer si listë RBL firewall-it para tij.

A është i siguruar mjaftueshëm Odoo 19 Community pa module shtesë?

Jo plotësisht. Pa modulin Password Policy nuk ka gjatësi minimale për fjalëkalimet, pa Two-Factor Authentication nuk ka faktor të dytë, dhe pa një modul si Web RBL Odoo nuk njeh as tentativat e sondimit as tentativat e përsëritura të hyrjes përtej një rinisjeje. Të katër mund të shtohen falas.

Disponueshmëria

Web RBL është i disponueshëm publikisht nën AGPL-3 dhe funksionon te ne në prodhim në pesë faqe:

github.com/Alex0176/odoo-web-rbl

Përshkrimi i plotë i funksioneve me të gjitha modelet, vlerësimin dhe listat e kërcënimeve gjendet në artikullin e mëparshëm: Web RBL – lista e bllokimit për trafikun sulmues në faqet e veta.

Pyetjet, vërejtjet dhe raportet e gabimeve i pranojmë me kënaqësi — mundësisht si Issue në GitHub.