Архітэктура бяспекі Odoo 19: правільнае спалучэнне брандмаўэра, 2FA, правоў доступу і Web RBL

Odoo на нашых пяці вэб-сайтах даступны з адкрытага інтэрнэту, і гэта не выключэнне, а норма: хто прапануе паслугу, вядзе краму або кліенцкі ўваход, той мае публічны сервер. Аднаго ўразлівага пароля, забытага файла канфігурацыі або занадта шчодрага права дастаткова, каб публічны сервер стаў адкрытым.

Гэты артыкул паказвае, як правільна абараніць Odoo 19 — не адной мерай, а некалькімі пластамі, якія дапаўняюць адзін аднаго: брандмаўэр і зваротны проксі, наш модуль з адкрытым кодам Web RBL, двухфактарная аўтэнтыфікацыя, парольная палітыка і правы доступу — і якія спробы атак кожны з іх рэальна перахопліваюць. У канцы ідзе пакрокавая інструкцыя, па якой можна паўтарыць усё гэта ў любой уласнай устаноўцы Odoo.

Абарона ў глыбіню: чаму адной меры ніколі не хапае

У кожнай асобнай меры бяспекі ёсць шчыліна. Брандмаўэр не бачыць, што адбываецца ў форме ўваходу Odoo. Моцны пароль не абараняе, калі яго ўжо ўкралі дзе-небудзь у іншым месцы. Структура правоў доступу не дапамагае супраць зламысніка, які яшчэ нават не ўвайшоў у сістэму. Прынцып, які закрывае гэтыя шчыліны, называецца абарона ў глыбіню (defense in depth): некалькі незалежных пластоў, кожны з якіх паасобку можна было б абысці — але ўсе разам усё ж не.

У нас чатыры пласты, і кожны выконвае сваю задачу:

• Брандмаўэр / зваротны проксі — адсякае відавочна зламыснае, перш чым яно наогул дасягне сервера
• Web RBL — злучае абодва бакі: Odoo вучыцца на ўласным журнале прыкладання таму, чаго брандмаўэр бачыць не можа, і вяртае гэта яму
• Сам Odoo — двухфактарная аўтэнтыфікацыя, парольная палітыка, правы доступу, кіраванне сеансамі
• База даных & эксплуатацыя — рэзервовае капіраванне, абарона доступу да адміністравання, сакрэты па-за межамі любога журнала

У наступных раздзелах разглядаецца кожны пласт паасобку.

Пласт 1: брандмаўэр і зваротны проксі

Брандмаўэр — гэта першая інстанцыя, якая бачыць запыт, і адзіная, якая можа адгарадзіць зламысніка ад кожнага сэрвісу на серверы — не толькі ад вэб-сайта, але і ад паштовага сервера, доступу праз 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, абыход шляхоў, выкананне каманд праз новыя інтэрфейсы ШІ
• Абарона ўваходу, якая лічыць праз перазапускі — у адрозненне ад уласнага лічыльніка Odoo, што жыве ў аператыўнай памяці
• Ацэнка кожнага адраса ад 0 да 100, з абгрунтаваннем простым тэкстам
• Памылковыя канфігурацыі (QNAP, Autodiscover, Synology) распазнаюцца і ніколі не блакуюцца, бо блакіроўка не ліквідуе няспраўнасць, а толькі хавае яе
• Чужыя спісы пагроз, такія як Spamhaus, FireHOL і выхадныя вузлы Tor, пастаянна звяраюцца
• Белы спіс для адрасоў, якія ніколі не павінны блакавацца

Для гэтага артыкула асабліва важныя дзве ўласцівасці, бо яны непасрэдна звязаныя з брандмаўэрам і з уваходам.

Інертны спіс — гэта спіс, якому можна давяраць

Белы спіс — адрасы, якія ніколі не блакуюцца, напрыклад, уласныя падключэнні філіялаў — як правіла, змяняецца рэдка. Менавіта ў гэтым яго каштоўнасць, а не недахоп: калі спакойны спіс за дні амаль не рухаецца, любая рэдкая змена адразу кідаецца ў вочы. Штодзённае аўтаматычнае абнаўленне існуе не таму, што шмат чаго мяняецца, а для таго, каб рэдкую змену не даводзілася дапісваць уручную — а менавіта ў гэтым месцы пра яе і забываюць. Адна з нашых уласных памылковых канфігурацый у мінулым месяцы выявілася менавіта так: не праз мноства падзей, а праз адну, пра якую ніхто не ведаў, пакуль вэб-API QNAP кліента не заблакавалі памылкова. З тых часоў QNAP стаіць у спісе памылковых канфігурацый, пра якія толькі паведамляюць, але якія ніколі не блакуюцца.

Уваход — месца, якога брандмаўэр не бачыць

Брандмаўэр можа заблакаваць адрас. Ён не можа ведаць, ці быў уваход паспяховым, і тым больш — ці прыйшоў ён з адраса, які незадоўга да гэтага яшчэ шукаў уліковыя дадзеныя. Web RBL — можа: ацэнка, пачынаючы з наладжвальнага парога, цалкам забараняе ўваход, а паспяховы ўваход з падазронага адраса фіксуецца — гэта звяно да наступнага пласта.

Пласт 3: абарона самога Odoo

Двухфактарная аўтэнтыфікацыя: другі сакрэт, які нельга выкарыстаць паўторна

Найбольшая праблема пароляў — не іх якасць, а паўторнае выкарыстанне. Пароль, украдзены ў іншым сэрвісе, працуе і ў нас гэтак жа, пакуль ён той самы. Двухфактарная аўтэнтыфікацыя (2FA, яе таксама называюць TOTP) супрацьпастаўляе гэтаму другі сакрэт: шасцізначны код, які змяняецца кожныя трыццаць секунд і вылічваецца з сакрэту, вядомага толькі ўласнаму смартфону. Аднаго ўкрадзенага пароля тады ўжо недастаткова.

Odoo 19 Community мае гэта ўбудаваным — як модуль для ўстаноўкі Two-Factor Authentication (TOTP), з дадатковым запасным варыянтам праз электронную пошту. Кожны карыстальнік наладжвае гэта сам для сябе, праз QR-код, з любым распаўсюджаным дадаткам-аўтэнтыфікатарам:

Наладжванне: адсканіраваць QR-код, адзін раз пацвердзіць шасцізначны код — гатова.

Але гэта дапамагае толькі тым, хто наладжвае яе сам, а досвед паказвае, што без прымусу гэта застаецца меншасцю. Таму Odoo мае палітыку прымусовага ўключэння: або толькі для супрацоўнікаў (унутраныя карыстальнікі), або для ўсіх, уключна з карыстальнікамі партала. Без наладжанага другога сакрэту ніхто больш не пройдзе форму ўваходу, не пацвердзіўшы сябе хаця б кодам па электроннай пошце.

Парольная палітыка: мінімальная даўжыня — не самазразумелая рэч

Без дадатковага модуля Odoo Community не мае ніякай мінімальнай даўжыні пароляў — карыстальнік можа задаць пароль з трох знакаў, калі яму ніхто не перашкодзіць. Уласны модуль Password Policy закрывае менавіта гэтую шчыліну: мінімальная даўжыня, якая забяспечваецца на баку сервера, а не толькі прапануецца ў браўзеры. Хто хоча большага — прымусовы тэрмін дзеяння, гісторыю супраць паўторнага выкарыстання — таму патрэбны модуль OCA або модуль іншага распрацоўшчыка; у версіі Community гэта наўмысна трымаюць лаканічным.

Правы доступу: доступ атрымлівае толькі той, каму ён патрэбны

Odoo ад пачатку раздзяляе тры ўзроўні: карыстальнікі партала (толькі ўласны партал кліента або пастаўшчыка), унутраныя карыстальнікі (бэкэнд, з правамі па кожным прыкладанні) і адміністратары (неабмежаваны доступ разам з тэхнічнымі наладамі). Найчасцейшая памылка — не занадта слабы пароль, а занадта шчодра выдадзеная роля адміністратара: той, хто павінен толькі выстаўляць рахункі, не мае патрэбы ў доступе да сістэмных налад.

Асноўную нагрузку нясуць два прынцыпы:

Абодва пункты можна праверыць у тым самым выглядзе, у якім наладжваецца і двухфактарная аўтэнтыфікацыя:

Адзін агляд, чатыры рычагі: пароль, другі фактар, ключы 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.