Odoo 19 Community: Web RBL – листа за блокирање на напаѓачки сообраќај на сопствените веб-страници

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

Кој управува со Odoo-сервер на интернет, добива посетители. Не повремено, туку непрекинато. Во текот на седумнаесет дена на нашите пет веб-страници запишавме и анализиравме 731.297 барања. 110.511 од нив не беа посетители, туку автоматизирано барање на слабости, пристапни податоци и конфигурациски датотеки.

Овој напис го опишува Web RBL, Open-Source-модул за Odoo 19 Community, што го препознава, оценува, книжи и одбива овој сообраќај — и што ја објавува листата за блокирање како RBL-листа, односно во форматот што Firewall-ите и Reverse-Proxy-јата директно го читаат. Сите бројки потекнуваат од реалното работење.

Што може модулот — функциите накратко

Функција	Што прави	Испорака
Препознавање на шаблони	Препознава сондирања по патека и наставка: .env, .git, конфигурациски датотеки, облак-клучеви, CI/CD-упатства за градење, WordPress, PHP, Path-Traversal, управувачи со бази на податоци, GraphQL, извршување на команди преку /api/fs/exec и слични интерфејси	блокирање
Три нивоа по шаблон	блокирање, броење или пријавување — прилагодливо по шаблон, без код	по шаблон
Прагови	Толку погодоци од истиот шаблон пред да се блокира; за најавувања десет	10 при најавување
Одбрана на најавувањето	Неуспешни најавувања преку маската и XML-RPC/JSON-RPC, неуспешни проверки на сесија, пристапи до управувачот со бази на податоци — во базата на податоци, не во работната меморија	вклучено
Препознавање на ботови при најавувањето	Кој ја игнорира пораката за чекање по десет неуспешни обиди и продолжува да чука, веднаш се блокира	блокирање
Препознавање на однесување	Адреси што за пет минути создаваат дваесет погрешни страници и речиси ниту една погодена страница — значи погодуваат наместо да читаат	пријавување
Оценка 0–100	Колку е сигурно дека зад адресата стои напаѓач? Според сериозноста на шаблонот, бројот на различни шаблони, приметливите денови, засегнатите домени и бројот на погодоци — со образложение со чист текст	вклучено
Блокада на најавување според оценка	Од подесива оценка нагоре најавувањето е забрането, веб-страницата останува читлива	од 40
Сомневање за украдени пристапни податоци	Една успешна најава од сомнителна адреса се пријавува и, по желба, се доделува како задача — еднаш по адреса и ден	вклучено
Листи на закани	Излезни Tor-јазли, Spamhaus DROP, FireHOL Level 1, blocklist.de се однапред конфигурирани; секоја дополнителна RBL-листа може да се внесе по адреса, дневно усогласување, посебно ниво за секоја листа	пријавување
Без пристап до најавата	Четвртото ниво за листи и земји: веб-страницата е читлива, формуларот за најава и интерфејсите се затворени — вистинскиот одговор на Tor	Опција
Земја на потекло	Земја по погодок и адреса преку GeoLite2; базата ја ажурира самиот модул со бесплатен лиценциски клуч	прикажи
Правила по земја	Блокирање, без пристап до најавата, пријавување или изрично слободно — по земја, намерно без претходно зададена вредност	нема
Погрешни конфигурации	QNAP, Synology, Exchange Autodiscover, ActiveSync, WebDAV/CalDAV/CardDAV се препознаваат, никогаш не се блокираат и се ставаат во работна листа со наод и засегнат домен	пријавување
Тикет по адреса	Од наодот, по желба, настанува тикет — точно еден по адреса, затворениот повторно се отвора наместо да се удвои	исклучено
Задолжителни страници и собирачи	Канонската патека до импресумот секогаш останува достапна; машинското пробување на туѓи начини на пишување се препознава и, по желба, се блокира	пријавување
Бела листа	Адреси и мрежи што никогаш не се блокираат; се полни секојдневно од заштитниот ѕид (VPN-спротивни страни) и од објавените адресни опсези на Googlebot и Bingbot	вклучено
Доделување на клиент	Погодокот од мрежата на еден клиент му се доделува нему — од белата листа, никогаш не се погодува рачно	вклучено
Домен и идентификатор по погодок	Која веб-страница била повикана, со кој User-Agent — и двете недостасуваат во пристапниот дневник	вклучено
Анализа	Дијаграм и пивот врз сите погодоци: по шема, ден, домен, земја, адреса	вклучено
Мамка	Сондите добиваат измислени одговори со канаринска вредност; кој подоцна ќе ја повика, ги прочитал	исклучено
RBL-испорака	Листата за блокирање како чиста листа на адреси или JSON на посебна адреса заштитена со токен — за HAProxy, OPNsense и секој заштитен ѕид што чита URL-листи	вклучено

Сè што се испорачува со пријави, исклучено или опција е намерно така: Кој вклучува блокада, треба да го стори затоа што неколку дена набљудувал, кој налетал на тоа — не затоа што така сакала зададената вредност.

Анализата: погодоци по шема во текот на седум дена. Највисокиот столб е пребарувањето на .env-датотеки.

RBL-листи: стандардизиран начин за испорака на блокади

RBL значи Real-time Blackhole List. Поимот потекнува од светот на е-поштата, каде што Spamhaus и други од деведесеттите објавуваат листи на злонамерни адреси на испраќачи. Принципот е многу едноставен и токму затоа толку раширен: една адреса во секој ред, достапна преку HTTP, редовно повторно вчитувана. Нема формат кој прво треба да се парсира, нема интерфејс за кој ви треба алатка.

Практично секој заштитен ѕид и секој reverse proxy може да прочита таква листа и од неа да изгради правила. Производителите го нарекуваат различно, механизмот насекаде е ист:

• 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 од feed-ови
• 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 повици на веб-интерфејсот на еден QNAP NAS — sync-клиент чија цел повеќе не е точна. Една единствена врска чукаше 962 пати.
• 65 Autodiscover-барања — еден Outlook што веб-доменот го смета за свој Exchange

Такви адреси никогаш не се блокираат. Блокадата не го отстранува дефектот, го крие — и го погодува оној чиј уред е веќе погрешно поставен. Наместо тоа настанува запис со текст на наод и засегнатите домени, од кој по желба автоматски станува тикет: точно еден по адреса, и ако се затвори, а адресата повторно се јави, истиот тикет повторно се отвора, наместо да настане втор.

Се препознаваат QNAP, Synology, Exchange Autodiscover, ActiveSync како и WebDAV-, CalDAV- и CardDAV-клиенти. Шемите при тоа ги именуваат точните имиња на датотеки и директориуми, никогаш голи екстензии: Во истиот директориум /cgi-bin/ безопасните sync-повици лежат веднаш до класични сонди како printenv.pl.

Белата листа: адреси што никогаш не се блокираат

Цената на една грешка не е иста за сите адреси. Кај скенер од центар за податоци лажната тревога не чини ништо. Кај спротивната страна на тунел до локација, го чини локацијата.

Затоа постои втора листа што стои пред првата: адреси и мрежи што никогаш не се блокираат. Таа при тоа ништо не го замолчува — кој е на неа, и натаму се проверува и книжи, само последицата отпаѓа. Тоа е разликата од исклучок во заштитниот ѕид: Тој прави слеп, оваа прави само трпелив.

Се полни секојдневно од два извори: од самиот заштитен ѕид со сите VPN-спротивни страни, за новоподесен тунел да не зависи од тоа дали некој ќе помисли на листата за блокирање — и од објавените адресни опсези на Google и Microsoft за нивните crawler-и. Само така може вистински Googlebot да се разликува од скенер што така се нарекува. Пребарувачите никогаш не смеат да се блокираат; кој ги исклучува, ја отстранува својата страница од индексирањето без пат назад.

При тоа важи правило поважно од усогласувањето: Празен одговор никогаш не брише. Ако изворот не одговори, одговори празно или неразбирливо, листата останува непроменета. Бела листа што при пречка сама се празни, во најлошиот можен момент ги однесува со себе сите тунели.

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

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

Импресумот не е обична страница. Мора да остане достапен за луѓе, бидејќи блокадата врз него го создава токму прекршокот што го бара еден собирач. Истовремено тоа е страницата на која стојат име и адреса — а со тоа и цел на машинска жетва.

Кај австрискиот бран опомени поради вградени Google-фонтови, дневниците покажаа дека писмата не потекнуваат од единечни посети, туку од автоматизиран масовен напад: различни, меѓусебно неповрзани хостови на растојание од милисекунди.

Web RBL го решава тоа со намалување на ниво наместо исклучок. Канонската патека /impressum не одговара на ниту една шема и секогаш останува достапна. Туѓи начини на пишување како /impressum.php — што на една Odoo-страница не може да постојат — се пријавуваат, а кој не сака да ја прифати машинската жетва, менува еден параметар. sitemap и robots се изземени од ова и во принцип не можат да се блокираат: Не содржат лични податоци, а нивното преземање е задача на секој crawler на пребарувач.

Домен и идентификатор: што недостасува во пристапниот дневник

Пристапниот дневник на werkzeug не запишува ниту повиканиот хост ниту идентификаторот на повикувачот. Odoo ги добива и двата, се разбира — без хостот не би можел при повеќе веб-страници воопшто да ја избере вистинската. Но подоцна не може да се прочита.

Web RBL ги зачувува и двете по погодок. Тоа одговара на две прашања на кои инаку не може да се одговори: која веб-страница ја повикува погрешната конфигурација — а со тоа и кому му припаѓа доменот — и дали една адреса посетува една страница или сите. Повеќе меѓусебно неповрзани домени од истата адреса се знак на масовен напад, и ја зголемуваат оценката.

Колку значи идентификаторот, покажа една анализа на еден од нашите веб-сајтови: Над седумдесет проценти од целиот сообраќај таму отпаѓаа на еден единствен повикувач, распределен на повеќе од сто адреси. Без идентификаторот тоа би изгледало како распределен scraper. Беше GPTBot, crawler-от на OpenAI — постојано бараше robots.txt и се однесуваше сосема коректно.

Безбедносните аспекти поединечно

1. Препознавањето на проксито — најопасното место воопшто

Ако Odoo работи зад reverse proxy и 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.