Odoo 19 Community: Web RBL – чорний список для шкідливого трафіку на власних вебсайтах

Вихідний код: github.com/Alex0176/odoo-web-rbl — AGPL-3, вільне використання.

Хто експлуатує сервер Odoo в інтернеті, отримує відвідувачів. Не випадково, а безперервно. Упродовж сімнадцяти днів ми на наших п'яти вебсайтах зафіксували й проаналізували 731 297 запитів. 110 511 із них не були відвідувачами, а автоматизованим пошуком вразливостей, облікових даних і конфігураційних файлів.

Ця публікація описує Web RBL – модуль із відкритим кодом для Odoo 19 Community, який розпізнає цей трафік, оцінює, фіксує і відхиляє його – та публікує чорний список як RBL-список, тобто у форматі, який фаєрволи та зворотні проксі читають безпосередньо. Усі цифри походять із реальної експлуатації.

Що вміє модуль – огляд функцій

Функція	Що вона робить	Передача
Розпізнавання за шаблонами	Розпізнає зондування за шляхом і розширенням: .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 розпізнаються, ніколи не блокуються й потрапляють до робочого списку з висновком і відповідним доменом	повідомляти
Тікет на адресу	Із висновку за бажанням створюється тікет — рівно один на адресу, закритий тікет відкривається знову, а не дублюється	вимк.
Обов’язкові сторінки та збирачі	Канонічний шлях до вихідних даних (Impressum) завжди залишається доступним; машинний перебір чужих варіантів написання розпізнається та за бажанням блокується	повідомляти
Білий список	Адреси та мережі, які ніколи не блокуються; щодня наповнюється з міжмережевого екрана (віддалені кінці 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
Обхід шляху (path traversal) з вигідною метою	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 від сканера, який так себе називає. Пошукові системи ніколи не можна блокувати; хто їх блокує, той прибирає свій сайт з індексації без жодного шляху назад.

При цьому діє правило, важливіше за саме зіставлення: Порожня відповідь ніколи нічого не видаляє. Якщо джерело не відповідає, відповідає порожньо або незрозуміло, список залишається без змін. Білий список, який під час збою сам спорожнюється, у найгірший можливий момент забирає з собою всі тунелі.

Якщо запис білого списку має клієнта, кожен збіг із його мережі прив’язується до нього. Хибна конфігурація таким чином одразу має контактну особу, і ніхто не мусить шукати адреси вручну.

Обов’язкові відомості та автоматизовані збирачі даних

Impressum — не звичайна сторінка. Вона має залишатися доступною для людей, адже блокування на ній створює саме те порушення, якого шукає збирач. Водночас це сторінка, на якій указано ім’я та адресу, — а отже, мета машинного збору.

Під час австрійської хвилі претензій через підключені шрифти 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.