Изходен код: 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, обхождане на директории, инструменти за управление на бази данни, 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, попълвани от URL адрес чрез скрипт и
fetch - 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 извиквания на уеб интерфейса на QNAP NAS — клиент за синхронизация, чиято цел вече не е вярна. Един единствен адрес е чукал 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 отговаря на заявките за сондиране с измислено съдържание, което включва уникална маркерна стойност. Който по-късно отправи заявка към тази стойност, е прочел фалшивия отговор и е действал въз основа на него — тук фалшива тревога е изключена. Примамките не съдържат използваема информация, реални пътища или валидни данни за достъп. При инсталиране тази функция е изключена, защото променя поведението по видим отвън начин.
Какво модулът не може
Той не замества защитна стена или защитна стена за уеб приложения. Разпознава известни шаблони за сондиране в пътищата, неуспешни опити за вход и подозрително поведение — но не и атаки срещу формуляри или опити за инжектиране чрез параметри.
Освен това вижда само това, което се връща през 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.