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.