Öryggisskipulag Odoo 19: eldveggur, 2FA, heimildir og Web RBL rétt sameinuð

Odoo er aðgengilegt frá opnu interneti á vefsíðunum okkar fimm, og það er ekki undantekning heldur venjan: Sá sem rekur tilboð, vefverslun eða viðskiptavinainnskráningu er með opinberan þjón. Eitt veikt lykilorð, gleymd stillingaskrá eða of rúm heimild nægir til þess að opinber þjónn verði opinn þjónn.

Þessi grein sýnir hvernig þið getið tryggt Odoo 19 rétt — ekki með einni einstakri aðgerð, heldur með mörgum lögum sem bæta hvert annað upp: eldvegg og öfugan milliþjón (reverse proxy), opinn hugbúnaðareininguna okkar Web RBL, tveggja þátta auðkenningu, lykilorðastefnu og heimildir — og hvaða árásartilraunir hvert þeirra stöðvar í raun. Í lokin eru leiðbeiningar skref fyrir skref sem hægt er að fylgja í hverri eigin Odoo-uppsetningu.

Vörn í dýpt: hvers vegna ein aðgerð dugar aldrei

Sérhver öryggisráðstöfun hefur glufu. Eldveggur sér ekki hvað gerist í innskráningarformi Odoo. Sterkt lykilorð verndar ekki ef því hefur þegar verið stolið annars staðar. Heimildaskipulag hjálpar ekki gegn árásaraðila sem hefur alls ekki skráð sig inn. Meginreglan sem lokar þessum glufum heitir vörn í dýpt (defense in depth): mörg óháð lög, þar sem hvert um sig væri hægt að sniðganga — en öll saman einmitt ekki.

Hjá okkur eru lögin fjögur, hvert með sitt hlutverk:

• Eldveggur / öfugur milliþjónn — heldur augljóslega illgjörnu frá áður en það nær yfirleitt til þjónsins
• Web RBL — tengir báðar hliðar: Odoo lærir af eigin forritaskrá það sem eldveggurinn getur alls ekki séð, og veitir því aftur til hans
• Odoo sjálft — tveggja þátta auðkenning, lykilorðastefna, heimildir, lotustjórnun
• Gagnagrunnur & rekstur — afritun, aðgangsvörn fyrir stjórnunina, leyndarmál utan allra skráa

Eftirfarandi kaflar fara yfir hvert lag fyrir sig.

Lag 1: eldveggur og öfugur milliþjónn

Eldveggurinn er fyrsta stigið sem sér beiðni, og eina stigið sem getur haldið árásaraðila frá allri þjónustu á þjóninum — ekki aðeins vefsíðunni, heldur líka póstþjóninum, VPN-aðganginum og stjórnunarviðmótinu sjálfu. Hvað er skynsamlegt að virkja hér fer eftir framleiðanda, en útfærslurnar eru þær sömu hjá OPNsense, pfSense, HAProxy, FortiGate, Sophos eða Check Point:

RBL-listar: staðlaða leiðin til að afhenda orðspor

RBL stendur fyrir Real-time Blackhole List, hugtak úr heimi tölvupósts: eitt vistfang í hverri línu, sótt með HTTP, endurhlaðið reglulega. Nánast hver einasti eldveggur getur lesið inn slíkan lista og búið til reglur úr honum — OPNsense og pfSense sem URL Table Alias, HAProxy sem ACL-skrá, FortiGate sem External Block List, Palo Alto sem External Dynamic List, Cisco, Sophos, Juniper og MikroTik með eigin heitum fyrir sömu meginreglu.

Einmitt hér tekur eigin eining okkar við — og einmitt hér hefst annað lagið.

Lag 2: Web RBL — brúin milli forrits og eldveggs

Eldveggur sér pakka, ekki forritsrökfræði. Hann veit ekki að beiðni um /xmlrpc/2/common er innskráningartilraun, að tuttugu ólíkar slóðir á fjórtán sekúndum eru skanni, eða að vistfang hafi rétt í þessu giskað rétt á lykilorð. Allt þetta veit aðeins Odoo sjálft. Web RBL, okkar eigin opna hugbúnaðareining (AGPL-3), gerir þessa vitneskju nýtanlega — fyrir Odoo sjálft og, afhent sem RBL-listi, einnig fyrir eldvegginn fyrir framan.

Ógnalistar stöðugt bornir saman, hver með eigið stig.

Stutt samantekt á því sem er lýst ítarlega í fyrri grein:

• Mynstursgreining í slóðum: .env-skrár, .git-möppur, stillingaskrár, WordPress- og PHP-kannanir, path traversal, skipanakeyrsla um ný gervigreindarviðmót
• Innskráningarvörn sem telur yfir endurræsingar — ólíkt eigin teljara Odoo sem lifir í vinnsluminni
• Einkunn hvers vistfangs frá 0 til 100, með rökstuðningi á skýru máli
• Rangar stillingar (QNAP, Autodiscover, Synology) eru greindar og aldrei bannaðar, því bann lagar ekki bilunina heldur felur hana aðeins
• Framandi ógnalistar eins og Spamhaus, FireHOL og Tor-útgönguhnútar, stöðugt bornir saman
• Undanþágulisti fyrir vistföng sem aldrei á að banna

Í þessari grein eru tveir eiginleikar sérstaklega mikilvægir, því þeir tengjast beint eldveggnum og innskráningunni.

Hægur listi er listi sem hægt er að treysta

Undanþágulistinn — vistföng sem aldrei eru bönnuð, til dæmis eigin tengingar starfsstöðva — breytist yfirleitt sjaldan. Einmitt það er gildi hans, ekki galli: Þegar rólegur listi hreyfist varla dögum saman fellur hver sjaldgæf breyting strax í augu. Daglega sjálfvirka uppfærslan er ekki til vegna þess að mikið myndi breytast, heldur til þess að sjaldgæfa breytingin þurfi ekki að bæta við í höndunum — og einmitt þar gleymir fólk því. Ein af okkar eigin röngu stillingum í síðasta mánuði uppgötvaðist einmitt þannig: ekki vegna margra atburða, heldur vegna þess eina sem enginn þekkti, uns QNAP-vef-API viðskiptavinar var ranglega bannað. Síðan þá er QNAP á lista yfir rangar stillingar sem aldrei eru bannaðar, aðeins tilkynntar.

Innskráningin er staðurinn sem eldveggur sér ekki

Eldveggur getur bannað vistfang. Hann getur ekki vitað hvort innskráning heppnaðist, og allra síst hvort hún kom frá vistfangi sem stuttu áður var enn að leita að aðgangsgögnum. Web RBL getur það: Einkunn yfir stillanlegu þröskuldsgildi bannar innskráninguna alfarið, og vel heppnuð innskráning frá grunsamlegu vistfangi er tilkynnt — það er tengiliðurinn við næsta lag.

Lag 3: Að tryggja Odoo sjálft

Tveggja þátta auðkenning: annað leyndarmál sem ekki er hægt að endurnýta

Stærsta vandamál lykilorða er ekki gæði þeirra, heldur endurnotkun. Lykilorð sem var stolið hjá annarri þjónustu virkar hjá okkur alveg eins, svo lengi sem það er hið sama. Tveggja þátta auðkenning (2FA, einnig kölluð TOTP) setur annað leyndarmál gegn því: sex stafa kóða sem breytist á þrjátíu sekúndna fresti og er reiknaður út frá leyndarmáli sem aðeins eigin snjallsími þekkir. Stolið lykilorð eitt og sér dugar þá ekki lengur.

Odoo 19 Community hefur þetta innbyggt — sem uppsetjanlega einingu Two-Factor Authentication (TOTP), ásamt varavalkosti með tölvupósti. Hver notandi setur það upp fyrir sig, með QR-kóða, í hvaða algengu auðkenningarforriti (authenticator-appi) sem er:

Uppsetningin: skannið QR-kóðann, staðfestið sex stafa kóðann einu sinni, búið.

Þetta eitt og sér hjálpar þó aðeins þeim sem setja það upp sjálfir — og reynslan sýnir að án þvingunar verða það áfram fáir. Odoo þekkir því þvingunarstefnu: annaðhvort aðeins fyrir starfsmenn (innri notendur) eða fyrir alla, þar með talda gáttarnotendur. Án uppsetts annars leyndarmáls kemst enginn lengur framhjá innskráningarforminu án þess að staðfesta að minnsta kosti með tölvupóstskóða.

Lykilorðastefna: lágmarkslengd er ekki sjálfsögð

Án viðbótareiningar treystir Odoo Community ekki á neina lágmarkslengd lykilorða — notandi getur sett lykilorð úr þremur stöfum ef enginn kemur í veg fyrir það. Eigin Password Policy-eining lokar einmitt þessari glufu: lágmarkslengd sem er framfylgt á þjónshliðinni, ekki aðeins stungið upp á í vafranum. Sá sem vill meira — þvingaðan gildistíma, sögu gegn endurnotkun — þarf til þess OCA-einingu eða einingu frá þriðja aðila; það er viljandi haft grannt í Community-útgáfunni.

Heimildir: aðeins sá sem þarf fær aðgang

Odoo aðgreinir sjálfkrafa þrjú stig: gáttarnotendur (aðeins eigin viðskiptavina- eða birgjagátt), innri notendur (bakendinn, með réttindum fyrir hvert forrit) og stjórnendur (ótakmarkaður aðgangur ásamt tæknilegum stillingum). Algengasta mistökin eru ekki of veikt lykilorð, heldur of rausnarlega úthlutað stjórnendahlutverk: Sá sem á aðeins að búa til reikninga þarf ekki aðgang að kerfisstillingunum.

Tvær meginreglur bera mestan þungann:

Hvort tveggja er hægt að athuga í sama yfirliti og tveggja þátta auðkenningin er sett upp í:

Eitt yfirlit, fjórir stjórnbúnaðir: lykilorð, annar þáttur, API-lyklar, innskráð tæki.

Lotur og tæki: hver er innskráður núna

Sama yfirlit sýnir einnig frá hvaða tækjum reikningur er innskráður núna — og gerir kleift að útskrá eitt eða öll í einu. Eftir týnda fartölvu eða grun um skert lykilorð er það fljótlegasta áhrifaríka skrefið: Lotan endar strax, óháð því hvort lykilorðinu hefur þegar verið breytt.

Lag 4: Gagnagrunnur og rekstur

Fjórða lagið er það sem minnst sést og um leið það sem er ófyrirgefanlegast, því mistök hér geta gert allt það sem áður var byggt að engu.

• Reglulegar, prófaðar afritanir, geymdar aðskildar frá þjóninum sjálfum. Afrit sem aldrei hefur verið endurheimt er getgáta, ekki afrit.
• Leyndarmál eiga ekki heima í neinni skráarskrá. Lykilorð, API-lyklar, leyfisgögn — sá sem skrifar eigin viðbætur ætti að meðhöndla þau eins og aðallykilorðið sjálft: skrá þau hvergi, ekki heldur „bara til villuleitar“.
• Halda einingum uppfærðum, líka og sérstaklega einingum þriðja aðila. Frjálsar viðbótareiningar (OCA og aðrar) dragast eðli málsins samkvæmt aftur úr nýjum Odoo-útgáfum; fyrir hverja uppsetningu borgar sig að skoða hvaða háðir fylgja sjálfkrafa með.

Innskráningarferlið í heild

Lögin fjögur verka ekki hvert á eftir öðru í aðskildum herbergjum, heldur á sömu beiðni, stig fyrir stig. Á dæmi um innskráningu sést það skýrast:

Fimm staðir þar sem illgjörn beiðni getur endað áður en hún kemst á raunverulegan áfangastað — og aðeins einn þar sem réttmætur notandi stenst þá alla.

Árásarsviðsmyndir og varnir gegn þeim

Eftirfarandi yfirlit raðar raunverulegum árásarmynstrum á þau lög sem í raun stöðva þau. Mörg þeirra eru ekki kenning, heldur eigin athuganir úr sautján dögum af raunumferð á vefsíðunum okkar fimm.

Skref fyrir skref: að tryggja eigin Odoo-uppsetningu

Eftirfarandi röð er sú sem við myndum sjálf fylgja — frá mestu áhrifum til fínustu stillingar.

1. Þvinga fram tveggja þátta auðkenningu

1. Sé það ekki þegar uppsett: opnið Apps, leitið að „Two-Factor Authentication“ og setjið upp (ef vefsíður eru fleiri en ein er auk þess mælt með „Two-Factor Authentication by Mail“ sem varavalkosti).
2. Opnið Stillingar → Almennar stillingar → Heimildir.
3. Virkjið „Þvinga fram tveggja þátta auðkenningu“.
4. Veljið stefnu: „Aðeins starfsmenn“ fyrir innri notendur, „Allir notendur“ ef gáttarnotendur (viðskiptavinir með aðgang) eiga einnig að vera með.
5. Vistið. Frá næstu innskráningartilraun krefst Odoo af hverjum notanda án uppsetts annars leyndarmáls að minnsta kosti tölvupóstskóða, þar til hann hefur sett upp auðkenningarforritið.

2. Setja lágmarkslengd fyrir lykilorð

1. Opnið Apps, leitið að „Password Policy“ og setjið upp.
2. Opnið Stillingar → Almennar stillingar → Heimildir.
3. Stillið „Lágmarkslengd lykilorðs“ — tólf stafir eru skynsamlegt upphafsgildi.
4. Vistið. Reglan gildir héðan í frá um hverja nýja eða breytta lykilorðsúthlutun, ekki afturvirkt um núverandi lykilorð.

3. Fara yfir heimildir

1. Opnið Stillingar → Notendur & fyrirtæki → Notendur.
2. Opnið hvern notanda fyrir sig og athugið flipann með aðgangsréttindum fyrir hvert forrit: Þarf þessi einstaklingur í raun „Stjórnandi“ eða „Kerfisstjóri“, eða nægir „Notandi“?
3. Athugið sérstaklega: Hver hefur aðgang að „Stillingum“ sjálfum? Það ætti að vera mjög fámennur hópur.
4. Fyrir hverja ytri tengingu (bókhald, eigin skriftur, tímaskráning) í flipanum „Reikningsöryggi“ hjá viðkomandi tæknilega notanda búið til sinn eigin API-lykil, í stað þess að gefa lykilorð notandans.

4. Setja upp Web RBL og fylgjast með áður en það er gert virkt

1. Setjið eininguna frá github.com/Alex0176/odoo-web-rbl í addon-slóðina og setjið upp.
2. Fylgist með í nokkra daga: valmyndin Web RBL → Greining sýnir hvaða mynstur taka í raun gildi.
3. Kveikið ekki fyrr en þá á web_rbl.sperren_aktiv (Stillingar → Tæknilegt → Kerfisfæribreytur) — héðan í frá er greindum könnunum í raun hafnað.
4. Tengið bannlistann í eldvegginn sem RBL-lista, af vistfanginu sem tilgreint er í einingunni og varið er með tákni (token) (hjá OPNsense/pfSense sem URL Table Alias, hjá HAProxy sem ACL-skrá).

5. Tryggja eldvegginn sjálfan

1. Gerið stjórnunarviðmót eldveggsins aðeins aðgengilegt úr innra netinu, aldrei um sama opinbera vistfang og vefsíðan.
2. Virkjið sjálfvirkar öryggisuppfærslur fyrir eldveggshugbúnaðinn, ef framleiðandinn býður upp á það.
3. Athugið TLS-stillingar: aðeins núverandi samskiptareglur, slökkvið á úreltum dulkóðunaraðferðum.
4. Ef í boði: tengið þekktan orðsporslista (til dæmis Spamhaus DROP) beint í eldvegginn — óháð Web RBL, því eldveggurinn sér þannig einnig umferð til þjónustu sem Odoo nær aldrei til.

6. Loka gagnagrunnsstjórnuninni

1. Athugið hvort /web/database/manager er aðgengilegt utan frá — ef svo er, stillið list_db = False í Odoo-stillingunum eða lokið slóðinni á eldveggsstigi.
2. Setjið aðallykilorð gagnagrunnsstjórnunarinnar langt og slembið og skráið það hvergi þar sem nokkur annar getur lesið það.

7. Prófa afritun, ekki aðeins setja hana upp

1. Setjið upp sjálfvirka, reglulega afritun, geymda aðskilda frá Odoo-þjóninum.
2. Endurheimtið að minnsta kosti einu sinni í raun og athugið hvort endurheimtin virkar — óprófað afrit er getgáta.

Ekkert þessara skrefa kemur í stað annars. Sá sem framkvæmir aðeins eitt þeirra hefur styrkt eina hurð og skilið allar aðrar eftir opnar — sá sem framkvæmir öll sjö hefur vörn sem heldur líka þegar eitt einstakt lag bregst.

Hvað þetta skipulag kemur ekki í stað

Engin af lýstu aðgerðunum gerir vandvirkni óþarfa. Eining sem hafnar .env-könnunum gerir .env-skrá sem óvart var birt ekki hættulausa. Tveggja þátta auðkenning ver ekki gegn notanda sem les kóðann sinn upp fyrir þann sem hringir í hann. Og eldveggur kemur ekki í stað ákvörðunar um hver þarf í raun hvaða heimild. Öryggisskipulag býr til skilyrði þar sem ein mistök verða ekki strax að atviki — það tekur vandvirkni ekki af neinum.

Algengar spurningar

Dugar sterkt lykilorð til að tryggja Odoo 19?

Nei. Lykilorði er hægt að stela annars staðar, algjörlega óháð gæðum þess, og það virkar þá hjá hverri þjónustu sem tekur við sama lykilorði. Aðeins samsetning með tveggja þátta auðkenningu, eldvegg fyrir framan og skynsamlegu heimildaskipulagi gefur vörn sem heldur líka eftir stolið lykilorð.

Hvernig virkja ég tveggja þátta auðkenningu í Odoo 19?

Setjið eininguna „Two-Factor Authentication (TOTP)“ upp í gegnum Apps-stjórnunina, virkjið síðan þvingunina undir Stillingar → Almennar stillingar → Heimildir og veljið á milli „Aðeins starfsmenn“ og „Allir notendur“. Hver notandi setur eftir það upp sinn eigin annan þátt með QR-kóða.

Hvað er RBL-listi, og hvers vegna þarf Odoo einn slíkan?

RBL (Real-time Blackhole List) er vistfangalisti sóttur með HTTP sem nánast hver eldveggur getur lesið inn. Odoo sjálft fylgir ekki slíkur listi — eining okkar Web RBL lokar þeirri glufu með því að greina árásarumferð úr eigin forritaskrá og skila henni sem RBL-lista til eldveggsins fyrir framan.

Er Odoo 19 Community nægilega tryggt án viðbótareininga?

Ekki að fullu. Án einingarinnar Password Policy er engin lágmarkslengd lykilorða, án Two-Factor Authentication enginn annar þáttur, og án einingar á borð við Web RBL greinir Odoo hvorki könnunartilraunir né endurteknar innskráningartilraunir yfir endurræsingu. Öll fjögur má bæta við ókeypis.

Framboð

Web RBL er aðgengilegt almenningi undir AGPL-3 og keyrir hjá okkur í framleiðslu á fimm vefsíðum:

github.com/Alex0176/odoo-web-rbl

Full lýsing á virkni með öllum mynstrum, einkunnagjöfinni og ógnalistunum er í fyrri grein: Web RBL – bannlisti fyrir árásarumferð á eigin vefsíðum.

Spurningum, athugasemdum og villuskýrslum tökum við fegins hendi — helst sem Issue á GitHub.