Безбедносна архитектура на Odoo 19: правилно комбинирање на заштитен ѕид, 2FA, овластувања и Web RBL

Odoo на нашите пет веб-страници е достапен од отворениот интернет, и тоа не е исклучок, туку нормален случај: Кој нуди понуда, продавница или најава за клиенти, има јавен сервер. Една единствена ранлива лозинка, една заборавена конфигурациска датотека или премногу широко овластување е доволно јавниот сервер да стане отворен.

Овој напис покажува како да го обезбедите Odoo 19 правилно — не со една единствена мерка, туку со повеќе слоеви што се надополнуваат меѓусебно: заштитен ѕид и reverse proxy, нашиот модул со отворен код Web RBL, двофакторна автентикација, политика за лозинки и овластувања — и кои обиди за напад секој од нив навистина ги фаќа. На крајот следува упатство чекор по чекор со кое може да се надгради секоја сопствена Odoo-инсталација.

Одбрана во длабочина: зошто една мерка никогаш не е доволна

Секоја поединечна безбедносна мерка има пропуст. Заштитниот ѕид не гледа што се случува во формуларот за најава на Odoo. Силната лозинка не штити ако веќе е украдена некаде другаде. Структурата на овластувања не помага против напаѓач што сè уште воопшто не се најавил. Принципот што ги затвора овие пропусти се вика одбрана во длабочина (defense in depth): повеќе независни слоеви, од кои секој поединечно би можел да се заобиколи — но сите заедно не.

Кај нас има четири слоја, секој со различна задача:

• Заштитен ѕид / reverse proxy — го држи настрана очигледно злонамерното пред воопшто да стигне до серверот
• Web RBL — ги поврзува двете страни: Odoo учи од сопствениот апликациски дневник она што заштитниот ѕид воопшто не може да го види, и му го враќа на ѕидот
• Самиот Odoo — двофакторна автентикација, политика за лозинки, овластувања, управување со сесии
• База на податоци & работење — бекап, заштита на пристапот до управувањето, тајни надвор од секој дневник

Следните делови го разгледуваат секој слој поединечно.

Слој 1: заштитен ѕид и reverse proxy

Заштитниот ѕид е првата инстанца што го гледа барањето и единствената што може да го држи напаѓачот настрана од секоја услуга на серверот — не само од веб-страницата, туку и од серверот за пошта, од VPN-пристапот и од сопствениот интерфејс за управување. Што на ова место е разумно да се активира, зависи од производителот, но основните форми кај OPNsense, pfSense, HAProxy, FortiGate, Sophos или Check Point се исти:

RBL-листи: стандардниот начин на кој се испорачува репутацијата

RBL значи Real-time Blackhole List, поим од светот на е-поштата: една адреса во секој ред, достапна преку HTTP, редовно повторно вчитувана. Практично секој заштитен ѕид може да прочита таква листа и од неа да изгради правила — OPNsense и pfSense како URL Table Alias, HAProxy како ACL-датотека, FortiGate како External Block List, Palo Alto како External Dynamic List, Cisco, Sophos, Juniper и MikroTik со свои имиња за истиот принцип.

Токму тука почнува нашиот сопствен модул — и токму тука започнува вториот слој.

Слој 2: Web RBL — мостот меѓу апликацијата и заштитниот ѕид

Заштитниот ѕид гледа пакети, не апликациска логика. Не знае дека барање за /xmlrpc/2/common е обид за најава, дека дваесет различни патеки за четиринаесет секунди се скенер, или дека една адреса токму успешно погодила лозинка. Сето тоа го знае само самиот Odoo. Web RBL, нашиот сопствен модул со отворен код (AGPL-3), го прави ова знаење употребливо — за самиот Odoo и, испорачан како RBL-листа, и за заштитниот ѕид пред него.

Листите на закани се континуирано усогласуваат, секоја со свое ниво.

Накратко, она што е опширно опишано во претходниот напис:

• Препознавање шеми во патеки: .env-датотеки, .git-директориуми, конфигурациски датотеки, WordPress- и PHP-сонди, path traversal, извршување наредби преку нови АИ-интерфејси
• Одбрана на најавата што брои и преку рестартирања — за разлика од сопствениот бројач на Odoo, кој живее во работната меморија
• Оценка на секоја адреса од 0 до 100, со образложение на јасен јазик
• Погрешните конфигурации (QNAP, Autodiscover, Synology) се препознаваат и никогаш не се блокираат, бидејќи блокадата не го отстранува дефектот, туку само го крие
• Туѓи листи на закани како Spamhaus, FireHOL и излезни Tor-јазли, континуирано усогласувани
• Бела листа за адреси што никогаш не треба да се блокираат

За овој напис две својства се особено важни, бидејќи се непосредно поврзани со заштитниот ѕид и со најавата.

Мирна листа е листа на која може да ѝ се верува

Белата листа — адреси што никогаш не се блокираат, на пример сопствени врски на локации — по правило се менува ретко. Токму тоа е нејзината вредност, не недостаток: Кога мирна листа речиси не се движи со денови, секоја ретка промена веднаш се забележува. Дневното автоматско ажурирање не постои затоа што би се менувало многу, туку за ретката промена да не мора да се дополнува рачно — а токму тоа е точката на која се заборава. Една од нашите сопствени погрешни конфигурации минатиот месец се забележа токму така: не по многу настани, туку по оној еден што никој не го знаеше, додека QNAP веб-API на еден клиент не беше погрешно блокиран. Оттогаш QNAP стои на листата на погрешни конфигурации што никогаш не се блокираат, туку само се пријавуваат.

Најавата е местото што заштитниот ѕид не го гледа

Заштитниот ѕид може да блокира адреса. Не може да знае дали една најава е успешна, а уште помалку дали дошла од адреса што малку претходно барала пристапни податоци. Web RBL може: Оценка од подесив праг нагоре целосно ја забранува најавата, а една успешна најава од сомнителна адреса се пријавува — тоа е врската кон следниот слој.

Слој 3: обезбедување на самиот Odoo

Двофакторна автентикација: втора тајна што не може повторно да се користи

Најголемиот проблем на лозинките не е нивниот квалитет, туку нивното повторно користење. Лозинка украдена кај друга услуга функционира и кај нас исто, сè додека е иста. Двофакторната автентикација (2FA, наречена и TOTP) му се спротивставува со втора тајна: шестцифрен код што се менува на секои триесет секунди и се пресметува од тајна што ја знае само сопствениот паметен телефон. Украдената лозинка сама повеќе не е доволна.

Odoo 19 Community го носи тоа вградено — како модул што се инсталира, Two-Factor Authentication (TOTP), дополнет со резервна опција преку е-пошта. Секој корисник го поставува сам за себе, преку QR-код, со секоја вообичаена апликација за автентикација:

Поставувањето: скенирајте го QR-кодот, потврдете го шестцифрениот код еднаш, готово.

Тоа само по себе, сепак, помага само на оние што сами го поставуваат — а искуството покажува дека без принуда тоа останува малцинство. Затоа Odoo познава политика на принудно спроведување: или само за вработени (внатрешни корисници) или за сите, вклучително и корисници на порталот. Без поставена втора тајна никој повеќе не поминува покрај формуларот за најава, а да не потврди барем со код по е-пошта.

Политика за лозинки: минималната должина не е самопонятна

Без дополнителен модул Odoo Community не се потпира на минимална должина за лозинките — корисникот може да зададе лозинка од три знаци ако никој не го спречи. Сопствениот модул Password Policy ја затвора токму таа празнина: минимална должина што се спроведува на страна на серверот, не само што се предлага во прелистувачот. Кој сака повеќе — наметнат рок на важност, историја против повторно користење — за тоа му треба OCA- или модул од трета страна; во Community-верзијата тоа е намерно сведено на минимум.

Овластувања: пристап добива само кој го треба

Odoo од основа одвојува три нивоа: корисници на порталот (само сопствениот портал за клиенти или добавувачи), внатрешни корисници (backend-от, со права по апликација) и администратори (неограничен пристап заедно со техничките поставки). Најчестата грешка не е преслаба лозинка, туку премногу широко доделена улога на администратор: Кој треба само да креира фактури, не му треба пристап до системските поставки.

Два принципа го носат најголемиот товар:

И двете може да се проверат во истиот приказ во кој се поставува и двофакторната автентикација:

Еден преглед, четири рачки: лозинка, втор фактор, API-клучеви, најавени уреди.

Сесии и уреди: кој е моментално најавен

Истиот приказ покажува и од кои уреди сметката е моментално најавена — и дозволува да се одјави еден или сите одеднаш. По изгубен лаптоп или при сомнеж за компромитирана лозинка тоа е најбрзиот ефикасен чекор: Сесијата завршува веднаш, независно од тоа дали лозинката веќе е сменета.

Слој 4: база на податоци и работење

Четвртиот слој е најмалку видлив и истовремено најнепростлив, бидејќи грешка тука може да го уништи сето претходно изградено.

• Редовни, проверени бекапи, чувани одвоено од самиот сервер. Бекап што никогаш не бил вратен е претпоставка, не бекап.
• Тајните не припаѓаат во ниту една дневничка датотека. Лозинки, API-клучеви, лиценцни податоци — кој пишува сопствени проширувања, треба да ги третира како самата главна лозинка: никаде да не ги запишува, ни „само за дебагирање“.
• Одржувајте ги модулите актуелни, и особено модулите од трети страни. Слободните дополнителни модули (OCA и други) природно заостануваат зад новите верзии на Odoo; пред секоја инсталација вреди да се погледне кои зависности автоматски доаѓаат со нив.

Патот на најавата во целина

Четирите слоја не делуваат еден по друг во одвоени простории, туку врз истото барање, ниво по ниво. Најјасно се гледа на примерот на една најава:

Пет места на кои едно злонамерно барање може да заврши пред да стигне до вистинската цел — и само едно на кое овластен корисник ги поминува сите.

Сценарија на напади и нивна одбрана

Следниот преглед ги распоредува реалните шеми на напади според слоевите што навистина ги запираат. Повеќе од нив не се теорија, туку сопствени набљудувања од седумнаесет дена вистински сообраќај на нашите пет веб-страници.

Чекор по чекор: обезбедување на сопствената Odoo-инсталација

Следниот редослед е оној по кој и ние самите би постапувале — од најголемото дејство до најфината поставка.

1. Принудно спроведување на двофакторна автентикација

1. Ако сè уште не е инсталиран: отворете Apps, побарајте „Two-Factor Authentication“ и инсталирајте го (при повеќе веб-страници дополнително се препорачува „Two-Factor Authentication by Mail“ како резервна опција).
2. Отворете Поставки → Општи поставки → Овластувања.
3. Активирајте „Принудно спроведување на двофакторна автентикација“.
4. Изберете политика: „Само вработени“ за внатрешни корисници, „Сите корисници“ ако треба да се опфатат и корисниците на порталот (клиенти со пристап).
5. Зачувајте. Од следниот обид за најава Odoo бара од секој корисник без поставена втора тајна најмалку код по е-пошта, додека не ја постави апликацијата за автентикација.

2. Определување минимална должина за лозинките

1. Отворете Apps, побарајте „Password Policy“ и инсталирајте го.
2. Отворете Поставки → Општи поставки → Овластувања.
3. Поставете „Минимална должина на лозинката“ — дванаесет знаци се разумна почетна вредност.
4. Зачувајте. Правилото важи од сега за секое ново или изменето доделување лозинка, не и ретроактивно за постојните лозинки.

3. Преглед на овластувањата

1. Отворете Поставки → Корисници & компании → Корисници.
2. Отворете го секој корисник поединечно и проверете го табот со правата за пристап по апликација: Дали на ова лице навистина му треба „Менаџер“ или „Администратор“, или е доволно „Корисник“?
3. Особено проверете: Кој има пристап до самите „Поставки“? Тоа треба да биде многу мала група.
4. За секое надворешно поврзување (сметководство, сопствени скрипти, евиденција на време) во табот „Безбедност на сметката“ на соодветниот технички корисник креирајте свој API-клуч, наместо да ја предавате корисничката лозинка.

4. Инсталирајте го Web RBL и набљудувајте пред да го пуштите во остра работа

1. Ставете го модулот од github.com/Alex0176/odoo-web-rbl во addon-патеката и инсталирајте го.
2. Набљудувајте неколку дена: менито Web RBL → Анализа покажува кои шеми навистина делуваат.
3. Дури потоа вклучете го web_rbl.sperren_aktiv (Поставки → Технички → Системски параметри) — од тука препознаените сонди навистина се одбиваат.
4. Листата за блокирање на адресата заштитена со токен, наведена во модулот, вклучете ја во заштитниот ѕид како RBL-листа (кај OPNsense/pfSense како URL Table Alias, кај HAProxy како ACL-датотека).

5. Обезбедување на самиот заштитен ѕид

1. Направете го интерфејсот за управување на заштитниот ѕид достапен исклучиво од внатрешната мрежа, никогаш преку истата јавна адреса како веб-страницата.
2. Активирајте автоматски безбедносни ажурирања за софтверот на заштитниот ѕид, доколку производителот го нуди тоа.
3. Проверете ја TLS-конфигурацијата: само актуелни верзии на протоколи, деактивирајте ги застарените методи на шифрирање.
4. Ако е достапно: вклучете позната листа на репутација (на пример Spamhaus DROP) директно на заштитниот ѕид — независно од Web RBL, бидејќи заштитниот ѕид така гледа и сообраќај кон услуги до кои Odoo никогаш не стигнува.

6. Затворање на управувањето со базата на податоци

1. Проверете дали /web/database/manager е достапен однадвор — ако да, во конфигурацијата на Odoo поставете list_db = False или блокирајте ја патеката на ниво на заштитен ѕид.
2. Поставете ја главната лозинка на управувањето со базата на податоци долга и случајна и не ја запишувајте на ниедно место што некој друг може да го прочита.

7. Проверка на бекапот, не само поставување

1. Поставете автоматски, редовен бекап, чуван одвоено од Odoo-серверот.
2. Барем еднаш навистина вратете го и проверете дали обновувањето функционира — непроверен бекап е претпоставка.

Ниеден од овие чекори не заменува некој од другите. Кој спроведува само еден од нив, зајакнал една врата, а сите други оставил отворени — кој ги спроведува сите седум, има одбрана што држи и тогаш кога еден слој ќе откаже.

Што оваа архитектура не заменува

Ниту една од опишаните мерки не ја прави грижливоста непотребна. Модул што одбива .env-сонди не прави случајно објавена .env-датотека безопасна. Двофакторната автентикација не штити од корисник што го чита својот код на некој што го повикал по телефон. А заштитниот ѕид не заменува одлука за тоа кој навистина какво овластување му треба. Безбедносната архитектура создава услови под кои една единствена грешка не станува веднаш инцидент — не му ја одзема грижливоста на никого.

Често поставувани прашања

Дали силна лозинка е доволна за обезбедување на Odoo 19?

Не. Лозинка може да се украде некаде другаде, сосема независно од нејзиниот квалитет, и тогаш функционира кај секоја услуга што ја прифаќа истата лозинка. Дури комбинацијата со двофакторна автентикација, заштитен ѕид пред неа и разумна структура на овластувања дава обезбедување што држи и по украдена лозинка.

Како да ја активирам двофакторната автентикација во Odoo 19?

Инсталирајте го модулот „Two-Factor Authentication (TOTP)“ преку управувањето со Apps, потоа под Поставки → Општи поставки → Овластувања активирајте го принудното спроведување и изберете помеѓу „Само вработени“ и „Сите корисници“. Секој корисник потоа го поставува својот втор фактор преку QR-код.

Што е RBL-листа и зошто му е потребна на Odoo?

RBL (Real-time Blackhole List) е листа на адреси достапна преку HTTP што може да ја прочита практично секој заштитен ѕид. Самиот Odoo не доаѓа со таква листа — нашиот модул Web RBL ја затвора оваа празнина така што го препознава сообраќајот на напад од сопствениот апликациски дневник и му го враќа како RBL-листа на претходно поставениот заштитен ѕид.

Дали Odoo 19 Community без дополнителни модули е доволно обезбеден?

Не целосно. Без модулот Password Policy нема минимална должина за лозинките, без Two-Factor Authentication нема втор фактор, а без модул како Web RBL Odoo не препознава ниту обиди за сондирање ниту повторени обиди за најава преку рестартирање. Сите четири може бесплатно да се дограт.

Достапност

Web RBL е јавно достапен под AGPL-3 и кај нас работи продукциски на пет веб-страници:

github.com/Alex0176/odoo-web-rbl

Целосниот опис на функциите со сите шеми, оценката и листите на закани е во претходниот напис: Web RBL – листа за блокирање на сообраќај на напад врз сопствените веб-страници.

Прашања, забелешки и извештаи за грешки со задоволство ги примаме — најсакано како Issue на GitHub.