Архітэктура бяспекі 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 змясціць у каталог дапаўненняў і ўсталяваць.
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.