Odoo 19 Community: Web RBL – списък за блокиране на атакуващ трафик към собствените уебсайтове

Изходен код: github.com/Alex0176/odoo-web-rbl — AGPL-3, свободно използваем.

Който управлява Odoo сървър в интернет, получава посещения. Не от време на време, а непрекъснато. В продължение на седемнадесет дни записвахме и анализирахме на петте ни уебсайта 731 297 заявки. 110 511 от тях не бяха посетители, а автоматизирано търсене на уязвимости, данни за достъп и конфигурационни файлове.

Тази публикация описва Web RBL, модул с отворен код за 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 се разпознават, никога не се блокират и се поставят в работен списък със заключение и засегнатия домейн	съобщаване
Тикет за адрес	От заключението при желание се създава тикет — точно един за адрес, затворен тикет се отваря отново, вместо да се дублира	изкл.
Задължителни страници и събирачи	Каноничният път към страницата с 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 от feeds
• 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
Вериги от AI инструменти и изпълнение на команди (/mcp, /api/fs/exec)	2.450	74
Инструкции за изграждане (CI/CD)	1.907	88
GraphQL крайни точки	1.878	71

Забележителен е най-новият клас. /api/fs/exec е бил поискан 369 пъти от 54 различни адреса — това е не достъп за четене, а опит за изпълнение на команди. Такива цели нямаше преди две години; те идват от интерфейсите на нови AI инструменти и опашки със задачи. Който насочва защитата си само към 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 от скенер, който се представя за такъв. Търсачките никога не бива да се блокират; който ги блокира, изважда сайта си от индексирането без път обратно.

При това важи правило, по-важно от сверяването: Празен отговор никога не изтрива. Ако източникът не отговори, отговори празно или неразбираемо, списъкът остава непроменен. Един разрешен списък, който при неизправност сам се изпразва, отнася в най-лошия възможен момент всички тунели.

Ако запис в разрешения списък носи клиент, всяко попадение от мрежата му се свързва с него. Така погрешната конфигурация има веднага контактно лице, без някой да трябва да търси адреси.

Задължителна информация и автоматизирани събирачи на данни

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.