Odoo 19 Community: Web RBL – spærreliste for angrebstrafik på de egne websites

Kildekode: github.com/Alex0176/odoo-web-rbl — AGPL-3, frit anvendelig.

Den, der driver en Odoo-server på internettet, får besøg. Ikke lejlighedsvis, men uafbrudt. Over sytten dage har vi på vores fem websites 731.297 forespørgsler logget og analyseret. 110.511 af dem var ikke besøgende, men automatiseret søgning efter sårbarheder, adgangsdata og konfigurationsfiler.

Dette indlæg beskriver Web RBL, et open source-modul til Odoo 19 Community, der genkender, vurderer, registrerer og afviser denne trafik — og som udgiver spærrelisten som RBL-liste, altså i det format, som firewalls og reverse proxyer umiddelbart kan læse. Alle tal stammer fra den reelle drift.

Hvad modulet kan — funktionerne i overblik

Funktion	Hvad den gør	Udlevering
Mønstergenkendelse	Genkender sondering ud fra sti og endelse: .env, .git, konfigurationsfiler, cloudnøgler, CI/CD-byggeinstruktioner, WordPress, PHP, path traversal, databasemanager, GraphQL, kommandoudførelse via /api/fs/exec og lignende grænseflader	spær
Tre trin pr. mønster	spær, tæl eller meld — kan omstilles pr. mønster, uden kode	pr. mønster
Tærskler	Så mange træffere af det samme mønster, før der spærres; for logins ti	10 ved login
Loginforsvar	Mislykkede logins via formular og XML-RPC/JSON-RPC, mislykkede sessionskontroller, adgange til databasemanageren — i databasen, ikke i arbejdshukommelsen	til
Bot-genkendelse ved login	Den, der ignorerer ventemeldingen efter ti mislykkede forsøg og fortsat banker på, spærres med det samme	spær
Adfærdsgenkendelse	Adresser, der på fem minutter genererer tyve fejlsider og næsten ingen træfsider — altså gætter i stedet for at læse	meld
Vurdering 0–100	Hvor sikkert er det, at en angriber står bag adressen? Ud fra mønstrets alvor, antallet af forskellige mønstre, påfaldende dage, berørte domæner og antal træffere — med begrundelse i klartekst	til
Loginspærring efter vurdering	Fra en indstillelig vurdering er login forbudt, websitet forbliver læsbart	fra 40
Mistanke om stjålne adgangsdata	Et vellykket login fra en påfaldende adresse bliver indberettet og kan efter ønske tildeles som opgave — én gang pr. adresse og dag	til
Trusselslister	Tor-exitnoder, Spamhaus DROP, FireHOL Level 1, blocklist.de er forkonfigureret; enhver anden RBL-liste kan tilføjes via adressen, daglig afstemning, eget niveau pr. liste	meld
Ingen adgang til login	Det fjerde niveau for lister og lande: Websiden kan læses, loginformularen og grænsefladerne er lukket — det rette svar på Tor	Valgfri
Oprindelsesland	Land pr. hit og adresse via GeoLite2; modulet opdaterer selv databasen med en gratis licensnøgle	vis
Landeregler	Spærre, ingen adgang til login, indberette eller udtrykkeligt tillade — pr. land, bevidst uden standardværdi	ingen
Fejlkonfigurationer	QNAP, Synology, Exchange-Autodiscover, ActiveSync, WebDAV/CalDAV/CardDAV bliver genkendt, aldrig spærret og sat på en arbejdsliste med fund og berørt domæne	meld
Ticket pr. adresse	Et fund bliver efter ønske til en ticket — præcis én pr. adresse; en lukket ticket genåbnes i stedet for at blive fordoblet	fra
Obligatoriske sider og indsamlere	Den kanoniske sti til impressum er altid tilgængelig; maskinel afprøvning af fremmede stavemåder bliver genkendt og kan efter ønske spærres	meld
Positivliste	Adresser og netværk, der aldrig spærres; udfyldes dagligt fra firewallen (VPN-modparter) og fra de offentliggjorte adresseintervaller for Googlebot og Bingbot	til
Kundetildeling	Et hit fra en kundes netværk bliver tildelt kunden — fra positivlisten, aldrig gættet i hånden	til
Domæne og identifikator pr. hit	Hvilken webside blev kaldt, med hvilken user agent — begge dele mangler i adgangsloggen	til
Analyse	Diagram og pivot over alle hits: pr. mønster, dag, domæne, land, adresse	til
Lokkemad	Sonder får opdigtede svar med en kanarieværdi; den, der senere henter den, har læst dem	fra
RBL-levering	Spærrelisten som ren adresseliste eller JSON på en egen adresse beskyttet med token — til HAProxy, OPNsense og enhver firewall, der læser URL-lister	til

Alt, hvad der leveres med indberette, fra eller valgfri, er bevidst sådan: Den, der aktiverer en spærring, skal gøre det, fordi han har iagttaget det i nogle dage, hvem der går i fælden — ikke fordi standardindstillingen ville det.

Analysen: hits pr. mønster over syv dage. Den højeste søjle er søgningen efter .env-filer.

RBL-lister: en standardiseret måde at levere spærringer på

RBL står for Real-time Blackhole List. Begrebet stammer fra mailverdenen, hvor Spamhaus og andre siden halvfemserne har offentliggjort lister over ondsindede afsenderadresser. Princippet er meget enkelt og netop derfor så udbredt: én adresse pr. linje, tilgængelig via HTTP, genindlæst jævnligt. Intet format, man først skal parse, ingen grænseflade, man skal bruge et værktøj til.

Stort set alle firewalls og reverse proxyer kan indlæse en sådan liste og bygge regler ud fra den. Producenterne kalder det forskellige ting, mekanismen er den samme overalt:

• OPNsense og pfSense — URL Table Alias: hent adresseliste via HTTP, brug den som alias i firewallregler, opdatering time- eller dagligt
• HAProxy — ACL-filer og maps: src -f sperrliste.txt i en http-request deny-regel, kan genindlæses via runtime-API'et uden genstart
• nginx — geo-modul med indlæst adressefil, eller deny-direktiver fra en genereret include-fil
• Fortinet FortiGate — External Block List hhv. Threat Feed: en URL, som firewallen henter en IP-liste fra og bruger i politikker
• Palo Alto Networks — External Dynamic List (EDL): samme princip, som egen objekttype i sikkerhedspolitikkerne
• Check Point — Custom Intelligence Feeds og IP Block Lists via en URL
• Cisco Secure Firewall (Firepower) — Security Intelligence Feeds med egne listekilder
• Sophos Firewall — Third-Party Threat Feeds: adresselister fra en URL som kilde til blokeringsregler
• Juniper SRX — Dynamic Address Entries fra feeds
• MikroTik RouterOS — Address Lists, udfyldt via script og fetch fra en URL
• CrowdSec — egne lister som kilde til bouncerne på ethvert understøttet system

Netop i dette format leverer Web RBL sin spærreliste. Firewallen smider pakkerne væk, før de når webserveren — og med dem ethvert andet forsøg fra den samme adresse, f.eks. på mailserveren eller VPN-gatewayen.

Begge retninger, men det rette sted

Vejen fungerer også omvendt: I Web RBL kan man tilføje enhver RBL-liste — en URL, et niveau, færdig. Tor-exitnoder, Spamhaus DROP, FireHOL og blocklist.de er forkonfigureret, flere kommer til med tre klik. Modulet opdeler hver liste i adresseintervaller og kontrollerer hver forespørgsel mod dem, på få mikrosekunder.

Og alligevel: Det er mere hensigtsmæssigt at bruge fremmede lister på firewallen foran. Af tre grunde. Firewallen ser alle tjenester, ikke kun HTTP — en adresse fra Spamhaus-listen skal også strande ved mailserveren og VPN'en. Den smider væk på pakkeniveau, før en forbindelse overhovedet kommer i stand, og koster dermed applikationsserveren intet. Og den er det sted, hvor sådanne lister under alle omstændigheder vedligeholdes; en anden kopi i applikationen er endnu et sted, der kan blive forældet.

Hvad listerne i modulet så stadig er gode til: det, som en firewall ikke kan. Den kender ingen loginformular. Web RBL kan nægte en adresse fra Tor-listen adgang til login og alligevel levere websiden — den, der vil læse anonymt, må gerne det; den, der vil afprøve adgangskoder anonymt, må ikke. Og det kan indberette et vellykket login fra en listet adresse som mistænkeligt tilfælde. Begge dele kræver, at listen findes dér, hvor login finder sted.

Vurdering i stedet for mavefornemmelse

En adresse, der én gang har spurgt efter /wp-login.php, er noget andet end en, der over to dage er gået til værks med fem forskellige mønstre på tværs af tre domæner. Web RBL omregner det til en score fra 0 til 100 — ud fra det, det selv har set, uden fremmed tjeneste og uden forespørgsel udadtil.

En post: 99 hits, score 84, og begrundelsen i klartekst — sværeste mønster, fem forskellige alvorlige mønstre, to påfaldende dage, over tyve hits.

Scoren afgør to ting. Fra en indstillelig værdi er login forbudt — websiden forbliver læsbar, men den, der allerede har ledt efter adgangsdata, får ingen mulighed for at afprøve de fundne. Og et vellykket login fra en adresse med score bliver indberettet: Så har nogen ikke længere gættet, men vidst. Enten var den berettigede bruger på farten, eller også er adgangsdataene kommet på afveje — modulet afgør det ikke, det forelægger det for en person, der kan spørge efter. Selve adgangskoden bliver undervejs ikke berørt nogen steder.

Spærrelisten, filtreret efter score fra 40: antal hits, påfaldende dage, berørte domæner og den seneste sti pr. adresse.

Hvad Web RBL beskytter — beskyttelsen i enkeltheder

1. Adgangsdata forbliver uopdagede

Den største målte angrebsklasse leder ikke efter huller i Odoo, men efter glemte hemmeligheder. Over sytten dage:

• 57.721 forespørgsler efter .env-filer — her står databaseadgangskoder, API-nøgler og sessionshemmeligheder
• 5.535 forespørgsler efter konfigurationsfiler
• 4.388 forespørgsler efter cloud-adgangsdata: credentials.json, service-account.json, firebase-adminsdk.json, rclone.conf, .git-credentials
• 2.811 forespørgsler efter .git-mapper — den, der finder en, henter hele kildekoden inklusive historik ned
• 1.907 forespørgsler efter byggeinstruktioner som .github/workflows/deploy.yml eller .gitlab-ci.yml, hvor registre og nøglenavne står

Afgørende er her ikke antallet af forespørgsler, men antallet af forskellige adresser: /credentials.json kom fra 98 adresser, /.git-credentials fra 92. Det er ikke en enkelt scanner, men et standardrepertoire, der kører over hele verden samtidig.

2. Loginforsøg løber ud i sandet — varigt

Odoo har en egen bremse mod afprøvning af adgangskoder. Den har tre grænser, som er dokumenteret i selve Odoos kildekode: Tælleren ligger i arbejdshukommelsen hos arbejdsprocessen og nulstilles ved hver genstart, den forsinker kun i stedet for at spærre, og den tæller udelukkende forsøg, der når frem til adgangskodekontrollen.

Web RBL sætter ind de samme steder, men skriver til databasen. Dermed gælder:

• Status overlever enhver genstart og gælder på tværs af alle arbejdsprocesser
• Begge veje registreres: loginformularen /web/login og grænsefladerne /xmlrpc/2/common og /jsonrpc
• Også forsøg, der aldrig når frem til adgangskodekontrollen, registreres — f.eks. logins uden gyldigt sessionsmærke
• En mislykket adgang til databasemanageren bliver talt med; det er det mest alvorlige loginforsøg overhovedet

Tærsklen for logins er sat til ti, og grunden er en måling: Af ni mislykkede logins på sytten dage stammede flertallet fra kunder, som selv satte adgangen op på et andet apparat og ved den lejlighed indtastede det forkerte domæne — i ét tilfælde deres eget, bare med bindestreg i stedet for punktum. En spærring ved det første fejlforsøg ville dermed ikke have ramt angribere, men kunder under opsætningen.

Den, der derimod bliver ved med at banke på, selv om serveren allerede har svaret »vent venligst et øjeblik«, bliver spærret med det samme. Denne meddelelse læser et menneske og venter; den, der ignorerer den, er et program. Et eget mønster med tærskel nul fanger netop dette tilfælde, og det kan ikke ramme en kollega: Dertil når kun den, der allerede har ti fejlforsøg bag sig og derefter fortsætter.

3. Angrebet koster ikke serveren noget længere

En sonde mod en sti som /@fs/../../.env var før modulet dyr: Odoo leder efter fejlsiden, renderer den, støder ved opbygningen af adressen på punktum-segmenterne og fejler derefter også på fejlsidens fejlside. To stacktraces pr. sonde. Målt blev 28.401 sådanne fejl på sytten dage, dertil 9.467 følgefejl.

Web RBL griber ind i ir.http._match, altså før ruteopslaget. Svaret gives uden skabelon, uden databaseadgang udover spærrekontrollen og uden logline. Kontrollen mod positivliste, trusselslister og landeregler kører fra cachen over sorterede adresseintervaller — få mikrosekunder, også ved over tredive tusind intervaller.

4. Firewallen smider angriberen ud, før han når frem

Spærrelisten udgives som RBL-liste, som HAProxy og OPNsense læser direkte. Angriberen når dermed slet ikke webserveren længere — og heller ingen anden tjeneste på samme vært. En adgang, der én gang er genkendt som ondsindet, beskytter således med tilbagevirkende kraft hele maskinen.

Tre niveauer: spærre, tælle, indberette

Ikke enhver forespørgsel ud i det blå er et angreb. Web RBL skelner derfor mellem tre niveauer, og niveauet kan skiftes pr. mønster, uden at man rører koden.

Niveau	Den udløsende forespørgsel	Konsekvens for adressen
spærre	afvises	spærret i 24 timer, efter tre påfaldende dage permanent
tælle	går igennem	kun registreret, ingen spærring
indberette	går igennem	registreret med fundtekst, bliver aldrig spærret

For trusselslister og lande findes et fjerde: ingen adgang til login. Websiden forbliver læsbar, loginformular og grænseflader er lukket. Det er mellemvejen for alt, hvad der er mistænkeligt, men ikke behøver at være ondsindet — Tor, et datacenterområde, et land uden kunder.

Hvilke angreb der genkendes

Alle mønstre er afprøvet mod ægte trafik. Antallet af forskellige adresser står bevidst ved siden af — det viser, om et mønster rammer en enkelt scanner eller en udbredt fremgangsmåde.

Angrebsklasse	Forespørgsler	Adresser
.env-indsamling	57.721	223
PHP-sonder	12.237	256
Stitraversering med lønsomt mål	10.046	64
Konfigurationsfiler	5.535	114
Cloud-adgangsnøgler	4.388	152
WordPress-sonder	3.366	385
.git-indsamling	2.811	255
Odoo-rekognoscering (databasemanager, versionsforespørgsel)	2.500	213
AI-værktøjskæder og kommandoudførelse (/mcp, /api/fs/exec)	2.450	74
Byggeinstruktioner (CI/CD)	1.907	88
GraphQL-endpoints	1.878	71

Bemærkelsesværdig er den yngste klasse. /api/fs/exec blev forespurgt 369 gange fra 54 forskellige adresser — det er ikke en læseadgang, men et forsøg på at udføre kommandoer. Sådanne mål fandtes ikke for to år siden; de stammer fra grænseflader til nye AI-værktøjer og opgavekøer. Den, der kun retter sit forsvar mod WordPress og PHP, ser intet af det. I scoren vejer denne klasse tilsvarende tungt.

Trusselslister og oprindelsesland

Fire lister, 32.851 adresseintervaller, alle på »kun indberette«. Hver yderligere liste er en adresse og et niveau.

En fremmed liste er en påstand, som en anden opstiller, af grunde, vi ikke kender, om trafik, vi aldrig har set. Den kan være forkert, forældet eller tænkt til et andet formål: blocklist.de samler især adresser, der andre steder har afprøvet SSH-logins, og det siger ikke meget om en webserver. Derfor fører Web RBL fremmede lister adskilt fra den egen spærreliste, og derfor er standardværdien indberette. Og den egen positivliste vinder altid: En kunde, som vi kender, vejer tungere end en tredjeparts vurdering.

Oprindelseslandet står ved hvert hit og hver adresse. Til vurdering er det uundværligt — et loginforsøg fra eget land klokken ti om formiddagen er noget andet end et fra et land uden en eneste kunde. Til generel udelukkelse duer det dårligt, og det siger vores egne tal: Angriberne i vores liste kom overvejende fra cloud-områder i Belgien, Finland og Holland. En spærring af alt uden for det tysktalende område ville ikke have ramt dem — men derimod egne medarbejdere på ferie og kunder på forretningsrejse.

Landeregler leveres tomme, og visningen forklarer, hvorfor.

Indberette fejlkonfigurationer i stedet for at spærre

Det hyppigste tilfælde i ægte trafik er hverken angreb eller besøgende, men defekt software, der tager webserveren for noget andet:

• 1.367 kald til webgrænsefladen på en QNAP-NAS — en synkroniseringsklient, hvis mål ikke passer længere. Én enkelt forbindelse bankede på 962 gange.
• 65 Autodiscover-forespørgsler — en Outlook, der tager webdomænet for sin Exchange

Sådanne adresser bliver aldrig spærret. En spærring afhjælper ikke defekten, den skjuler den — og rammer den, hvis apparat i forvejen er indstillet forkert. I stedet opstår der en post med fundtekst og de berørte domæner, hvoraf der efter ønske automatisk bliver en ticket: præcis én pr. adresse, og bliver den lukket, og adressen igen falder i øjnene, genåbnes den samme ticket, i stedet for at der opstår en ny.

Der genkendes QNAP, Synology, Exchange-Autodiscover, ActiveSync samt WebDAV-, CalDAV- og CardDAV-klienter. Mønstrene nævner derved nøjagtige filnavne og mapper, aldrig blotte endelser: I samme mappe /cgi-bin/ ligger de harmløse synkroniseringskald lige ved siden af klassiske sonder som printenv.pl.

Positivlisten: adresser, der aldrig spærres

Prisen for en fejl er ikke den samme for alle adresser. Ved en scanner fra et datacenter koster en falsk alarm intet. Ved modparten i en lokationstunnel koster den lokationen.

Derfor findes der en anden liste, som står foran den første: adresser og netværk, der aldrig spærres. Den gør dog intet stille — den, der står på den, bliver stadig kontrolleret og registreret, kun konsekvensen udebliver. Det er forskellen til en undtagelse i firewallen: Den gør blind, denne gør kun tålmodig.

Den udfyldes dagligt fra to kilder: fra selve firewallen med alle VPN-modparter, så en nyoprettet tunnel ikke er afhængig af, at nogen husker spærrelisten — og fra de offentliggjorte adresseintervaller fra Google og Microsoft til deres crawlere. Kun sådan kan en ægte Googlebot skelnes fra en scanner, der kalder sig det. Søgemaskiner må aldrig spærres; den, der udelukker dem, tager sin side ud af indekseringen uden vej tilbage.

Her gælder en regel, der er vigtigere end afstemningen: Et tomt svar sletter aldrig. Svarer kilden ikke, tomt eller uforståeligt, forbliver listen uændret. En positivliste, der tømmer sig selv ved en fejl, tager i det værst tænkelige øjeblik alle tunneller med.

Bærer en post på positivlisten en kunde, bliver ethvert hit fra dennes netværk tildelt kunden. En fejlkonfiguration har dermed straks en kontaktperson, uden at nogen skal slå adresser op.

Obligatoriske oplysninger og automatiserede dataindsamlere

Impressum er ikke en almindelig side. Den skal forblive tilgængelig for mennesker, for en spærring på den skaber netop den overtrædelse, som en indsamler leder efter. Samtidig er det siden, hvor navn og adresse står — og dermed målet for maskinel høst.

Under den østrigske bølge af advarsler på grund af indlejrede Google-skrifttyper viste logfilerne, at brevene ikke stammede fra enkeltbesøg, men fra en automatiseret storstilet aktion: forskellige, indbyrdes urelaterede værter med få millisekunders mellemrum.

Web RBL løser det ved nedgradering i stedet for undtagelse. Den kanoniske sti /impressum rammer slet intet mønster og forbliver altid tilgængelig. Fremmede stavemåder som /impressum.php — som ikke kan findes på en Odoo-side — bliver indberettet, og den, der ikke vil acceptere den maskinelle høst, ændrer en parameter. sitemap og robots er undtaget herfra og kan grundlæggende ikke spærres: De indeholder ingen personoplysninger, og at hente dem er enhver søgemaskine-crawlers opgave.

Domæne og identifikator: hvad der mangler i adgangsloggen

Adgangsloggen fra werkzeug skriver hverken den kaldte vært eller kalderens identifikator med. Odoo får begge selvfølgelig — uden værten kunne det ved flere websider slet ikke vælge den rigtige. Men bagefter kan man ikke slå det op.

Web RBL fastholder begge dele pr. hit. Det besvarer to spørgsmål, som ellers ikke lader sig besvare: hvilken webside en fejlkonfiguration kalder — og dermed hvilken kunde domænet tilhører — og om en adresse besøger én side eller alle. Flere indbyrdes urelaterede domæner fra den samme adresse er kendetegnet for den store aktion, og de hæver scoren.

Hvor meget identifikatoren betyder, viste en analyse på en af vores websider: Over halvfjerds procent af al trafik skyldtes dér én enkelt kalder, fordelt over mere end hundrede adresser. Uden identifikatoren ville det have set ud som en distribueret scraper. Det var GPTBot, OpenAIs crawler — den spurgte igen og igen efter robots.txt og opførte sig fuldstændig korrekt.

Sikkerhedsaspekterne i enkeltheder

1. Proxy-genkendelsen — det farligste sted overhovedet

Kører Odoo bag en reverse proxy, og proxy_mode er sat forkert, ser modulet ved hver forespørgsel den samme adresse: proxyens. En spærring ville så udelukke alle besøgende samtidig.

Derfor kontrollerer Web RBL før hver spærring, om adressebestemmelsen er pålidelig. Det kræver proxy_mode sammen med en videresendelses-header, afviser at arbejde, hvis en videresendelse ankommer uden proxy_mode, og afviser det ligeledes ved mere end én mellemliggende proxy. I tvivlstilfælde spærres der ikke.

2. Aldrig egne netværk

Private adresseintervaller, loopback, link-local og CGNAT er fast undtaget. De kan under ingen omstændigheder havne på listen, heller ikke i hånden. Det samme gælder fremmede lister: Private og reserverede intervaller samt absurd store netværk forkastes ved indlæsningen.

3. En egen fejl må ikke tage websiden med

Hele kontrollen kører i en sikring, der fanger enhver fejl. Hvad der går galt her, bliver logget, og forespørgslen fortsætter uændret. Et beskyttelsesmodul, der ved en egen fejl tager websiden med, er værre end slet intet. Alle forespørgsler i forespørgselsstien kører desuden uden den besøgendes browsersprog og uden sortering efter oversatte felter — en besøgende med et ikke-installeret sprog må ikke få kontrollen til at fejle.

4. Observere før spærring

Efter installationen er spærring af listede adresser ved almindelige forespørgsler slået fra. Sonder afvises og registreres, alt andet går igennem. Så kan man i nogle dage læse med om, hvem der faktisk havner på listen, før nogen bliver udelukket. Det samme gælder adfærdsgenkendelse, trusselslister og landeregler: først indberette, spærre efter besigtigelse.

5. Snævre mønstre i stedet for brede net

En forkert genkendt besøgende er dyrere end en overset sonde. Hvert mønster bærer derfor sit niveau, og det kan skiftes pr. mønster. En filendelse alene er sjældent nok: Ved .php står 14.012 ægte sonder over for en håndfuld gamle links, ved .asp er forholdet omvendt. Sådanne beslutninger hører til at blive målt, ikke skønnet.

6. En manuel frigivelse består

Den, der frigiver en adresse, havde en grund. Et yderligere hit sætter ikke stiltiende denne beslutning ud af kraft.

7. Listen er beskyttet, men ingen hemmelighed

Endpointet kræver et token og svarer uden gyldigt token med 404, ikke med 403 — adressens eksistens bliver dermed slet ikke bekræftet. Sammenligningen kører i konstant tid. Selve listen indeholder intet fortroligt: Den består af adresser, som af sig selv har banket på hos os.

8. Ingen hemmeligheder i regnskabet

Ved mislykkede logins noteres det forsøgte brugernavn, aldrig adgangskoden. Ved databasemanageren læses der af de overleverede værdier slet intet: Dér står øverst masteradgangskoden, og en post i en spærreliste vandrer ind i hver databasesikkerhedskopi. Licensnøglen til GeoLite2 står kun i systemparameteren og i ingen logline.

9. Lokkemaden afslører intet anvendeligt

Valgfrit besvarer Web RBL sonder med opdigtet indhold, der indeholder en entydig kanarieværdi. Den, der senere henter denne værdi, har læst det forfalskede svar og handlet derefter — en falsk alarm er dermed udelukket. Lokkemaden indeholder ingen anvendelige oplysninger, ingen ægte stier og ingen gyldige adgangsdata. Denne funktion leveres slået fra, fordi den ændrer adfærden på en udadtil synlig måde.

Hvad modulet ikke kan

Det erstatter hverken en firewall eller en Web Application Firewall. Det genkender kendte sonderingsmønstre i stier, mislykkede logins og påfaldende adfærd — ikke angreb på formularer, ikke indsmuglingsforsøg i parametre.

Det ser desuden kun, hvad der kommer tilbage over HTTP. Hvad en angriber gør med erobrede database- eller postkasseadgange, forbliver usynligt — og netop derfor er kanarieværdierne stier og ikke adgangsdata.

Og det erstatter ikke omhyggelighed: Et modul, der afviser .env-sonder, gør en ved en fejl udleveret .env-fil ikke ufarlig.

Tilgængelighed

Web RBL er offentligt tilgængeligt under AGPL-3 og kører hos os produktivt på fem websider:

github.com/Alex0176/odoo-web-rbl

Modulet forudsætter Odoo 19 Community og har ingen afhængigheder ud over base og web. Ticket- tilslutningen er valgfri og kræver intet bestemt ticketsystem; uden et sådant sker der simpelthen intet. Oprindelseslandet kræver den gratis GeoLite2-database fra MaxMind; mangler den, forbliver feltet tomt, og alt andet arbejder uændret.

Læs videre: Hvordan Web RBL passer ind i en komplet sikkerhedsarkitektur -- sammen med firewall, tofaktorgodkendelse og rettigheder, inklusive trin-for-trin-vejledning: Kombinér Odoo 19-sikkerhedsarkitekturen rigtigt.

Spørgsmål, bemærkninger og fejlrapporter modtager vi gerne — helst som issue på GitHub.