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
Обход путей с ценной целью	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.