Odoo 19 Community: Web RBL — спіс блакіравання для трафіка атак на ўласныя вэб-сайты

Зыходны код: github.com/Alex0176/odoo-web-rbl — AGPL-3, свабодна выкарыстоўваецца.

Хто кіруе серверам Odoo ў інтэрнэце, той атрымлівае наведвальнікаў. Не час ад часу, а бесперапынна. На працягу сямнаццаці дзён мы на нашых пяці вэб-сайтах запісвалі і аналізавалі 731.297 запытаў. 110.511 з іх былі не наведвальнікамі, а аўтаматызаваным пошукам уразлівасцей, даных доступу і канфігурацыйных файлаў.

Гэты артыкул апісвае Web RBL, Open-Source-модуль для Odoo 19 Community, які распазнае, ацэньвае, рэгіструе і адхіляе гэты трафік — і які публікуе спіс блакіроўкі як RBL-спіс, а значыць, у фармаце, які брандмаўэры і reverse proxy чытаюць непасрэдна. Усе лічбы паходзяць з рэальнай эксплуатацыі.

Што ўмее модуль — функцыі ў агляд

Функцыя	Што робіць	Выдача
Распазнаванне шаблонаў	Распазнае зандаванне па шляху і пашырэнні: .env, .git, канфігурацыйныя файлы, ключы воблака, інструкцыі CI/CD, WordPress, PHP, Path Traversal, адміністратары баз даных, GraphQL, выкананне каманд праз /api/fs/exec і падобныя інтэрфейсы	блакаваць
Тры ўзроўні на шаблон	блакаваць, лічыць або паведамляць — пераключаецца для кожнага шаблону, без кода	для кожнага шаблону
Парогі	Столькі супадзенняў аднаго шаблону, перш чым будзе блакіроўка; для ўваходу дзесяць	10 пры ўваходзе
Абарона ўваходу	Няўдалыя ўваходы праз форму і XML-RPC/JSON-RPC, няўдалыя праверкі сесіі, звароты да адміністратара баз даных — у базе даных, а не ў аператыўнай памяці	укл.
Распазнаванне ботаў пры ўваходзе	Хто ігнаруе паведамленне пра чаканне пасля дзесяці няўдалых спроб і працягвае стукаць, блакуецца неадкладна	блакаваць
Распазнаванне паводзін	Адрасы, якія за пяць хвілін ствараюць дваццаць памылковых старонак і амаль ніводнай знойдзенай старонкі — гэта значыць здагадваюцца, а не чытаюць	паведамляць
Ацэнка 0–100	Наколькі верагодна, што за адрасам стаіць атакуючы? З сур’ёзнасці шаблону, колькасці розных шаблонаў, падазроных дзён, закранутых даменаў і колькасці супадзенняў — з тлумачэннем простым тэкстам	укл.
Блакіроўка ўваходу па ацэнцы	Пачынаючы з наладжвальнай ацэнкі ўваход забаронены, вэб-сайт застаецца чытэльным	ад 40
Падазрэнне ў крадзяжы даных доступу	Паспяховы ўваход з падазронага адрасу фіксуецца і, па жаданні, прызначаецца як задача — адзін раз на адрас у дзень	укл.
Спісы пагроз	Выхадныя вузлы Tor, Spamhaus DROP, FireHOL Level 1, blocklist.de наладжаны загадзя; любы іншы RBL-спіс можна дадаць па адрасе, штодзённая звярка, асобны ўзровень для кожнага спісу	паведамляць
Няма доступу да ўваходу	Чацвёрты ўзровень для спісаў і краін: вэб-сайт даступны для чытання, форма ўваходу і інтэрфейсы закрытыя — слушны адказ на Tor	Опцыя
Краіна паходжання	Краіна для кожнага супадзення і адраса праз GeoLite2; базу даных модуль абнаўляе сам з бясплатным ліцэнзійным ключом	паказваць
Правілы для краін	Блакаваць, закрыць доступ да ўваходу, паведамляць або свядома дазволіць — для кожнай краіны, наўмысна без прадусталёўкі	няма
Памылковыя канфігурацыі	QNAP, Synology, Exchange Autodiscover, ActiveSync, WebDAV/CalDAV/CardDAV распазнаюцца, ніколі не блакуюцца і трапляюць у спіс задач з высновай і назвай закранутага дамена	паведамляць
Тыкет на адрас	З выніку, па жаданні, ствараецца тыкет — роўна адзін на адрас, закрыты тыкет зноў адкрываецца замест таго, каб дубляваццца	выкл.
Абавязковыя старонкі і збіральнікі	Кананічны шлях да выходных звестак заўсёды застаецца даступным; машыннае перабіранне чужых варыянтаў напісання распазнаецца і, па жаданні, блакуецца	паведамляць
Белы спіс	Адрасы і сеткі, якія ніколі не блакуюцца; штодня запаўняецца з брандмаўэра (аддаленыя бакі VPN) і з апублікаваных дыяпазонаў адрасоў Googlebot і Bingbot	укл.
Прывязка да кліента	Супадзенне з сеткі кліента прыпісваецца яму — з белага спісу, ніколі не навобмацак	укл.
Дамен і ідэнтыфікатар для кожнага супадзення	Які вэб-сайт быў выкліканы і з якім User-Agent — і таго, і другога няма ў журнале доступу	укл.
Аналіз	Дыяграма і зводная табліца па ўсіх супадзеннях: па шаблоне, дні, дамене, краіне, адрасе	укл.
Прынада	Зонды атрымліваюць выдуманыя адказы з канарэечным значэннем; хто пазней запытае яго, той іх прачытаў	выкл.
Выдача RBL	Спіс блакіроўкі ў выглядзе простага спісу адрасоў або JSON па асобным адрасе, абароненым токенам — для HAProxy, OPNsense і любога брандмаўэра, які чытае спісы URL	укл.

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

Аналіз: супадзенні па шаблонах за сем дзён. Найвышэйшы слупок — пошук файлаў .env.

RBL-спісы: стандартны спосаб дастаўкі блакіровак

RBL расшыфроўваецца як Real-time Blackhole List. Тэрмін паходзіць з поштавага свету, дзе Spamhaus і іншыя з дзевяностых гадоў публікуюць спісы злаўмысных адрасоў адпраўнікоў. Прынцып вельмі просты, і менавіта таму такі пашыраны: адзін адрас у радку, даступна праз HTTP, рэгулярна перазагружаецца. Ніякага фармату, які трэба спачатку разбіраць, ніякага інтэрфейсу, для якога патрэбна асобная прылада.

Практычна кожны брандмаўэр і кожны зваротны проксі можа прачытаць такі спіс і пабудаваць на яго аснове правілы. Вытворцы называюць гэта па-рознаму, але механізм усюды той самы:

• OPNsense і pfSense — URL Table Alias: загрузка спісу адрасоў праз HTTP, выкарыстанне як аліаса ў правілах брандмаўэра, абнаўленне штогадзінна або штодня
• HAProxy — ACL-файлы і Maps: src -f sperrliste.txt у правіле http-request deny, перазагрузка падчас працы праз API часу выканання без перазапуску
• nginx — модуль geo з падключаным файлам адрасоў або інструкцыі deny з генерыраванага файла include
• Fortinet FortiGate — External Block List або Threat Feed: URL, з якога брандмаўэр атрымлівае спіс IP і выкарыстоўвае яго ў палітыках
• Palo Alto Networks — External Dynamic List (EDL): той самы прынцып, як асобны тып аб'екта ў палітыках бяспекі
• Check Point — Custom Intelligence Feeds і IP Block Lists праз URL
• Cisco Secure Firewall (Firepower) — Security Intelligence Feeds з уласнымі крыніцамі спісаў
• Sophos Firewall — Third-Party Threat Feeds: спісы адрасоў з URL як крыніца для правіл блакіроўкі
• Juniper SRX — Dynamic Address Entries з фідаў
• MikroTik RouterOS — Address Lists, якія запаўняюцца скрыптам і fetch з URL
• CrowdSec — уласныя спісы як крыніца для bouncer-ў на кожнай падтрымліваемай сістэме

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

Абодва напрамкі, але ў правільным месцы

Гэты шлях працуе і ў адваротным кірунку: у Web RBL можна ўнесці любы RBL-спіс — URL, узровень, гатова. Выхадныя вузлы Tor, Spamhaus DROP, FireHOL і blocklist.de наладжаны загадзя, іншыя дадаюцца трыма клікамі. Модуль раскладае кожны спіс на дыяпазоны адрасоў і правярае кожны запыт па іх за некалькі мікрасекунд.

І ўсё ж: разумней карыстацца чужымі спісамі на брандмаўэры, які стаіць перад сервісам. Па трох прычынах. Брандмаўэр бачыць усе сэрвісы, а не толькі HTTP — адрас са спісу Spamhaus павінен упірацца ў перашкоду і на паштовым серверы, і на VPN. Ён адкідвае на ўзроўні пакетаў, яшчэ да ўсталявання злучэння, і таму нічога не каштуе серверу прыкладання. І менавіта там такія спісы і так вядуцца; другая копія ў прыкладанні — гэта другое месца, якое можа састарэць.

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

Ацэнка замест інтуіцыі

Адрас, які адзін раз запытаў /wp-login.php, зусім не тое, што адрас, які ў два дні перабраў пяць розных шаблонаў на трох даменах. Web RBL пераводзіць гэта ў ацэнку ад 0 да 100 — з таго, што ён бачыў сам, без старонняга сэрвісу і без запытаў вонкі.

Адзін запіс: 99 супадзенняў, ацэнка 84 і абгрунтаванне простым тэкстам — найцяжэйшы шаблон, пяць розных сур'ёзных шаблонаў, два падазроныя дні, больш за дваццаць супадзенняў.

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

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

Што абараняе Web RBL — абарона па пунктах

1. Уліковыя дадзеныя застаюцца незаўважанымі

Найбольшы з выяўленых класаў атак шукае не ўразлівасці ў Odoo, а забытыя сакрэты. За сямнаццаць дзён:

• 57.721 запыт на файлы .env — там захоўваюцца паролі да баз даных, ключы API і сакрэты сеансаў
• 5.535 запытаў на файлы канфігурацыі
• 4.388 запытаў на воблачныя уліковыя дадзеныя: credentials.json, service-account.json, firebase-adminsdk.json, rclone.conf, .git-credentials
• 2.811 запытаў на каталогі .git — хто знойдзе такі, той сцягвае поўны зыходны код разам з гісторыяй
• 1.907 запытаў на інструкцыі зборкі, напрыклад .github/workflows/deploy.yml або .gitlab-ci.yml, дзе пазначаны рэестры і назвы ключоў

Вырашальная тут не колькасць запытаў, а колькасць розных адрасоў: /credentials.json прыйшоў з 98 адрасоў, /.git-credentials — з 92. Гэта не асобны сканер, а стандартны набор, які працуе ва ўсім свеце адначасова.

2. Спробы ўваходу бескарысныя — назаўсёды

Odoo мае ўласны тормаз супраць перабірання пароляў. У яго тры межы, якія задакументаваны ў самім зыходным коде Odoo: лічыльнік знаходзіцца ў аператыўнай памяці працоўнага працэсу і абнуляецца пры кожным перазапуску, ён толькі запавольвае, а не блакуе, і ён улічвае толькі спробы, якія даходзяць да праверкі пароля.

Web RBL падключаецца ў тых самых месцах, але піша ў базу даных. Таму:

• Стан перажывае кожны перазапуск і дзейнічае для ўсіх працоўных працэсаў
• Улічваюцца абодва шляхі: форма ўваходу /web/login і інтэрфейсы /xmlrpc/2/common і /jsonrpc
• Улічваюцца таксама спробы, якія ніколі не даходзяць да праверкі пароля — напрыклад, уваходы без сапраўднай прыметы сеанса
• Няўдалы доступ да кіраўніка баз даных улічваецца таксама; гэта найсур'ёзнейшая спроба ўваходу наогул

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

А вось хто працягвае стукацца, хоць сервер ужо адказаў «калі ласка, хвілінку пачакайце», таго блакуюць адразу. Гэтае паведамленне чытае чалавек і чакае; хто яго ігнаруе — той праграма. Асобны шаблон з парогам нуль лавіць менавіта гэты выпадак, і ён не можа закрануць калегу: туды трапляе толькі той, хто ўжо зрабіў дзесяць няўдалых спроб і пасля гэтага працягвае.

3. Атака больш нічога не каштуе серверу

Зонд на шлях кшталту /@fs/../../.env да модуля быў дарагім: Odoo шукае старонку памылкі, рэндэрыць яе, спатыкаецца пры пабудове адраса на сегментах з кропак і тады церпіць няўдачу таксама на старонцы памылкі старонкі памылкі. Два стэк-журналы на кожны зонд. Было зафіксавана 28.401 такіх памылак за сямнаццаць дзён, да таго ж 9.467 наступных памылак.

Web RBL падключаецца да ir.http._match, значыць, да вызначэння маршруту. Адказ фарміруецца без шаблона, без доступу да базы даных за межамі праверкі блакіроўкі і без радка ў журнале. Праверка па белым спісе, спісах пагроз і правілах для краін працуе з кэшу па адсартаваных дыяпазонах адрасоў — некалькі мікрасекунд, нават пры больш чым трыццаці тысячах дыяпазонаў.

4. Брандмаўэр выкідвае зламысніка яшчэ да таго, як той прыйдзе

Спіс блакіроўкі публікуецца як RBL-спіс, які HAProxy і OPNsense чытаюць наўпрост. Зламыснік таму наогул не дасягае вэб-сервера — і ніводнага іншага сэрвісу на тым жа хосце. Аднойчы распазнаны зламысны доступ такім чынам заднім лікам абараняе ўсю машыну.

Тры ўзроўні: блакаваць, лічыць, паведамляць

Не кожны пустой запыт — атака. Таму Web RBL адрознівае тры ўзроўні, і ўзровень можна змяняць для кожнага шаблона без умяшання ў код.

Узровень	Запыт, які выклікаў спрацоўванне	Наступства для адраса
блакаваць	адхіляецца	заблакаваны на 24 гадзіны, пасля трох падазроных дзён — назаўсёды
лічыць	праходзіць	толькі фіксуецца, без блакіроўкі
паведамляць	праходзіць	фіксуецца з тэкстам выніку, ніколі не блакуецца

Для спісаў пагроз і краін ёсць чацвёрты: няма доступу да ўваходу. Вэб-сайт застаецца чытальным, форма ўваходу і інтэрфейсы закрытыя. Гэта сярэдні шлях для ўсяго, што падазрона, але не абавязкова зламысна — Tor, дыяпазон дата-цэнтра, краіна без кліентаў.

Якія атакі распазнаюцца

Усе шаблоны правераныя на рэальным трафіку. Колькасць розных адрасоў пазначана побач наўмысна — яна паказвае, ці шаблон задзейнічае на асобны сканер, ці на шырока распаўсюджаны спосаб дзеяння.

Клас атакі	Запыты	Адрасы
Сцягванне .env	57.721	223
PHP-зонды	12.237	256
Абыход шляхоў з прывабнай мэтай	10.046	64
Файлы канфігурацыі	5.535	114
Воблачныя ключы доступу	4.388	152
WordPress-зонды	3.366	385
Сцягванне .git	2.811	255
Разведка Odoo (кіраўнік баз даных, запыт версіі)	2.500	213
Ланцужкі прылад ШІ і выкананне каманд (/mcp, /api/fs/exec)	2.450	74
Інструкцыі зборкі (CI/CD)	1.907	88
Канчатковыя кропкі GraphQL	1.878	71

Увагі заслугоўвае самы малады клас. /api/fs/exec быў запытаны 369 разоў з 54 розных адрасоў — гэта не доступ для чытання, а спроба выканаць каманды. Такіх мэт два гады таму не было; яны паходзяць з інтэрфейсаў новых прылад ШІ і чэргаў заданняў. Хто арыентуе абарону толькі на WordPress і PHP, нічога з гэтага не бачыць. Таму ў ацэнцы гэты клас важыць вельмі шмат.

Спісы пагроз і краіна паходжання

Чатыры спісы, 32.851 дыяпазон адрасоў, усе ў рэжыме «толькі паведамляць». Кожны наступны спіс — гэта адрас і ўзровень.

Чужы спіс — гэта сцвярджэнне, якое выстаўляе хтосьці іншы, па прычынах, якіх мы не ведаем, адносна трафіку, якога мы ніколі не бачылі. Яно можа быць памылковым, састарэлым або прызначаным для іншай мэты: blocklist.de збірае ў асноўным адрасы, якія дзе-небудзь у іншым месцы перабіралі ўваходы па SSH, а гэта пра вэб-сервер кажа мала. Таму Web RBL вядзе чужыя спісы асобна ад уласнага спісу блакіроўкі, і таму прадусталёўка — паведамляць. А ўласны белы спіс заўсёды мае перавагу: кліент, якога мы ведаем, важыць больш, чым меркаванне трэцяга боку.

Краіна паходжання пазначана пры кожным супадзенні і кожным адрасе. Для ацэнкі яна незаменная — спроба ўваходу з сваёй краіны ў дзесяць гадзін раніцы — гэта не тое самае, што спроба з краіны, дзе няма ніводнага кліента. Для суцэльнай блакіроўкі яна малапрыдатная, і гэта кажуць нашы ўласныя лічбы: зламысднікі у нашым спісе паходзілі пераважна з воблачных дыяпазонаў у Бельгіі, Фінляндыі і Нідэрландах. Блакіроўка ўсяго, што знаходзіцца па-за межамі нямецкамоўнай прасторы, іх бы не закранула — затое закранула б сваіх супрацоўнікаў у адпачынку і кліентаў у камандзіроўцы.

Правілы для краін пастаўляюцца пустымі, і прадстаўленне тлумачыць, чаму.

Памылковыя канфігурацыі: паведамляць, а не блакаваць

Найчасцейшы выпадак у рэальным трафіку — гэта не атака і не наведвальнік, а няспраўнае праграмнае забеспячэнне, якое прымае вэб-сервер за нешта іншае:

• 1.367 зваротаў да вэб-інтэрфейсу NAS QNAP — кліент сінхранізацыі, чыя мэта больш не адпавядае рэчаіснасці. Адно адзінае злучэнне стукалася 962 разы.
• 65 запытаў Autodiscover — гэта Outlook, які лічыць вэб-дамен сваім серверам Exchange

Такія адрасы ніколі не блакіруюцца. Блакіраванне не ліквідуе праблему, яно толькі хавае яе — і б'е па тым, чыя прылада і без таго наладжана няправільна. Замест гэтага ствараецца запіс з апісаннем праблемы і закранутымі даменамі, на аснове якога пры жаданні можа аўтаматычна стварацца тыкет: роўна адзін на кожны адрас. Калі тыкет закрыты, а адрас зноў прыцягвае ўвагу, паўторна адкрываецца той самы тыкет замест стварэння новага.

Распазнаюцца кліенты QNAP, Synology, Exchange-Autodiscover, ActiveSync, а таксама WebDAV, CalDAV і CardDAV. Пры гэтым шаблоны вызначаюць дакладныя імёны файлаў і каталогаў, а не проста пашырэнні: у адным і тым жа каталогу /cgi-bin/ бяскрыўдныя запыты сінхранізацыі знаходзяцца побач з класічнымі зондамі, такімі як printenv.pl.

Спіс дазволеных адрасоў: адрасы, якія ніколі не блакіруюцца

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

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

Ён напаўняецца штодня з дзвюх крыніц: непасрэдна з фаервола з усімі аддаленымі кропкамі VPN, каб праца новастворанага тунэля не залежала ад таго, ці ўспомніць нехта пра спіс блакіравання, і з апублікаваных дыяпазонаў адрасоў Google і Microsoft для іх пошукавых робатаў. Толькі так можна адрозніць сапраўднага Googlebot ад сканера, які толькі выдае сябе за яго. Пошукавыя сістэмы ні ў якім разе нельга блакіраваць; той, хто іх блакіруе, безнадзейна выключае свой сайт з індэксацыі.

Пры гэтым дзейнічае правіла, якое важнейшае за саму сінхранізацыю: пусты адказ ніколі нічога не выдаляе. Калі крыніца не адказвае, вяртае пусты або незразумелы адказ, спіс застаецца без змен. Спіс дазволеных адрасоў, які ачышчаецца пры збоі, у найгоршы магчымы момант абарве ўсе тунэлі.

Калі запіс у спісе дазволеных адрасоў замацаваны за кліентам, кожнае спрацоўванне з яго сеткі прыпісваецца яму. Дзякуючы гэтаму пры памылцы канфігурацыі адразу вядома, да каго звяртацца, і нікому не даводзіцца шукаць адрасы ўручную.

Абавязковыя звесткі і аўтаматызаваныя зборшчыкі даных

Старонка з абавязковымі звесткамі — не звычайная старонка. Яна павінна заставацца даступнай для людзей, бо блакіраванне доступу да яе стварае менавіта тое парушэнне, якога шукае зборшчык. У той жа час гэта старонка, дзе пазначаны імя і адрас, а значыць — мэта для аўтаматычнага збору даных.

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

Web RBL вырашае гэта праз паніжэнне ўзроўню пагрозы замест выключэння. Кананічны шлях /impressum не супадае ні з адным шаблонам і заўсёды застаецца даступным. Іншыя варыянты напісання, такія як /impressum.php, якіх на сайце Odoo быць не можа, фіксуюцца, і той, хто не хоча цярпець аўтаматычны збор даных, можа проста змяніць параметр. sitemap і robots з'яўляюцца выключэннем і ўвогуле не падлягаюць блакіраванню: яны не ўтрымліваюць персанальных даных, а іх загрузка з'яўляецца задачай любога пошукавага робата.

Дамен і ідэнтыфікатар: чаго не хапае ў журнале доступу

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

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

Наколькі важны ідэнтыфікатар, паказаў аналіз на адным з нашых вэб-сайтаў: больш за сямдзесят працэнтаў усяго трафіка там прыпадала на аднаго кліента, размеркаванага больш чым па ста адрасах. Без ідэнтыфікатара гэта выглядала б як размеркаваны скрапер. Гэта быў GPTBot, пошукавы робат ад OpenAI: ён увесь час запытваў robots.txt і паводзіў сябе цалкам карэктна.

Аспекты бяспекі падрабязна

1. Вызначэнне проксі — самае небяспечнае месца

Калі Odoo працуе за зваротным проксі-серверам і параметр proxy_mode зададзены няправільна, модуль пры кожным запыце бачыць адзін і той жа адрас: адрас проксі. У такім выпадку блакіраванне прывядзе да таго, што ўсе наведвальнікі будуць заблакіраваны адначасова.

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

2. Уласныя сеткі — ніколі

Прыватныя дыяпазоны адрасоў, Loopback, Link-Local і CGNAT строга выключаны. Яны ні пры якіх абставінах не могуць трапіць у спіс, нават уручную. Тое ж тычыцца і знешніх спісаў: прыватныя і зарэзерваваныя дыяпазоны, а таксама празмерна вялікія сеткі адхіляюцца пры чытанні.

3. Уласная памылка не павінна выводзіць з ладу вэб-сайт

Уся праверка выконваецца з ахоўным механізмам, які перахоплівае любую памылку. Калі тут узнікае збой, ён заносіцца ў журнал, а запыт працягвае апрацоўвацца без змен. Модуль абароны, які пры ўласнай памылцы кладзе сайт, горшы за яго поўную адсутнасць. Акрамя таго, усе запыты на этапе апрацоўкі працуюць без уліку мовы браўзера наведвальніка і без сартавання па перакладзеных палях — наведвальнік з неўсталяванай мовай не павінен выклікаць збой праверкі.

4. Назіранне перад блакіраваннем

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

5. Дакладныя шаблоны замест шырокіх сетак

Памылкова распазнаны наведвальнік каштуе даражэй за прапушчаны зонд. Кожны шаблон таму мае свой узровень, і яго можна змяняць для кожнага шаблона. Аднаго пашырэння файла рэдка бывае дастаткова: для .php налічваецца 14.012 сапраўдных зондаў супраць жменькі старых спасылак, для .asp суадносіны адваротныя. Такія рашэнні трэба вымяраць, а не ацэньваць на вока.

6. Дазвол, дадзены ўручную, захоўваецца

Хто дазваляе адрас, меў на гэта прычыну. Чарговае супадзенне негалосна не скасоўвае гэтае рашэнне.

7. Спіс абаронены, але гэта не сакрэт

Канчатковая кропка патрабуе токен і без сапраўднага токена адказвае кодам 404, а не 403 — такім чынам існаванне адраса нават не пацвярджаецца. Параўнанне адбываецца за пастаянны час. Сам спіс не змяшчае нічога канфідэнцыйнага: ён складаецца з адрасоў, якія самі спрабавалі да нас пастукацца.

8. Ніякіх сакрэтаў у журнале ўліку

Пры няўдалых спробах уваходу фіксуецца спроба ўводу імя карыстальніка, але ніколі пароль. У дыспетчары баз даных з перададзеных значэнняў увогуле нічога не чытаецца: там на першым месцы знаходзіцца галоўны пароль, а запіс у спісе блакіроўкі трапляе ў кожную рэзервовую копію базы даных. Ліцэнзійны ключ для GeoLite2 захоўваецца толькі ў сістэмным параметры і ніколі не трапляе ў радкі логаў.

9. Прынада не выдае нічога каштоўнага

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

Чаго модуль не ўмее

Ён не замяняе фаервол і Web Application Firewall. Ён распазнае вядомыя шаблоны сканавання ў шляхах, няўдалыя спробы ўваходу і падазроныя паводзіны, але не атакі на формы ці спробы ўкаранення кода праз параметры.

Акрамя таго, ён бачыць толькі тое, што вяртаецца праз HTTP. Тое, што зламыснік робіць са скрадзенымі данымі доступу да базы даных або паштовай скрыні, застаецца нябачным — і менавіта таму маркеры з'яўляюцца шляхамі, а не ўліковымі данымі.

І ён не адмяняе неабходнасці быць уважлівым: модуль, які адхіляе зонды да .env, не робіць выпадкова апублікаваны файл .env бяспечным.

Даступнасць

Web RBL адкрыта даступны пад ліцэнзіяй AGPL-3 і працуе ў нас у прадукцыйным рэжыме на пяці вэб-сайтах:

github.com/Alex0176/odoo-web-rbl

Для працы модуля патрабуецца Odoo 19 Community, і ён не мае ніякіх залежнасцей, акрамя base і web. Інтэграцыя з тыкетамі з'яўляецца неабавязковай і не патрабуе канкрэтнай сістэмы тыкетаў; пры яе адсутнасці проста нічога не адбываецца. Для вызначэння краіны паходжання патрабуецца бясплатная база даных GeoLite2 ад MaxMind; калі яна адсутнічае, поле застаецца пустым, а ўсё астатняе працуе без змен.

Дадаткова: як Web RBL упісваецца ў поўную архітэктуру бяспекі — разам з фаерволам, двухфактарнай аўтэнтыфікацыяй і правамі доступу, уключаючы пакрокавае кіраўніцтва: Правільнае спалучэнне кампанентаў архітэктуры бяспекі Odoo 19.

Мы з задавальненнем прымаем пытанні, каментарыі і справаздачы пра памылкі — лепш за ўсё праз Issue на GitHub.