Odoo 19 Community: Web RBL – blokkeringsliste for angrepstrafikk mot egne nettsider

Kildekode: github.com/Alex0176/odoo-web-rbl — AGPL-3, fritt å bruke.

Den som driver en Odoo-server på internett, får besøk. Ikke av og til, men uavbrutt. Over sytten dager har vi på de fem nettsidene våre loggført og analysert 731 297 forespørsler. 110 511 av dem var ikke besøkende, men automatisert leting etter sårbarheter, påloggingsopplysninger og konfigurasjonsfiler.

Dette innlegget beskriver Web RBL, en modul med åpen kildekode for Odoo 19 Community som gjenkjenner, vurderer, registrerer og avviser denne trafikken — og som publiserer blokkeringslisten som RBL-liste, altså i formatet som brannmurer og reverse proxyer umiddelbart kan lese. Alle tall stammer fra reell drift.

Hva modulen kan — funksjonene i oversikt

Funksjon	Hva den gjør	Levering
Mønstergjenkjenning	Gjenkjenner sondering etter sti og filendelse: .env, .git, konfigurasjonsfiler, skynøkler, CI/CD-byggeinstrukser, WordPress, PHP, path traversal, databaseadministratorer, GraphQL, kommandokjøring via /api/fs/exec og lignende grensesnitt	blokkere
Tre nivåer per mønster	blokkere, telle eller melde — kan endres per mønster, uten kode	per mønster
Terskler	Så mange treff av samme mønster før det blokkeres; for pålogginger ti	10 ved pålogging
Påloggingsforsvar	Mislykkede pålogginger via skjema og XML-RPC/JSON-RPC, mislykkede sesjonskontroller, tilgang til databaseadministratoren — i databasen, ikke i arbeidsminnet	på
Bot-gjenkjenning ved påloggingen	Den som ignorerer ventemeldingen etter ti mislykkede forsøk og banker på videre, blokkeres umiddelbart	blokkere
Atferdsgjenkjenning	Adresser som på fem minutter genererer tjue feilsider og nesten ingen treffsider — altså gjetter i stedet for å lese	melde
Vurdering 0–100	Hvor sikkert er det at en angriper står bak adressen? Ut fra mønsterets alvorlighetsgrad, antall ulike mønstre, påfallende dager, berørte domener og antall treff — med begrunnelse i klartekst	på
Påloggingssperre etter vurdering	Fra en innstillbar vurdering er pålogging forbudt, nettsiden forblir lesbar	fra 40
Mistanke om stjålne påloggingsopplysninger	En vellykket innlogging fra en mistenkelig adresse blir rapportert og kan etter ønske tildeles som oppgave — én gang per adresse og dag	på
Trusselister	Tor-utgangsnoder, Spamhaus DROP, FireHOL Level 1, blocklist.de er forhåndskonfigurert; enhver annen RBL-liste kan legges inn via adressen, daglig avstemming, eget nivå per liste	melde
Ingen tilgang til innlogging	Det fjerde nivået for lister og land: nettstedet kan leses, men innloggingsskjemaet og grensesnittene er stengt — det riktige svaret på Tor	Valgfritt
Opprinnelsesland	Land per treff og adresse via GeoLite2; modulen oppdaterer databasen selv med en gratis lisensnøkkel	vis
Landsregler	Blokkere, ingen tilgang til innlogging, rapportere eller uttrykkelig tillatt — per land, bevisst uten forhåndsinnstilling	ingen
Feilkonfigurasjoner	QNAP, Synology, Exchange Autodiscover, ActiveSync, WebDAV/CalDAV/CardDAV gjenkjennes, blir aldri blokkert og legges i en arbeidsliste med funn og berørt domene	melde
Sak per adresse	Et funn blir etter ønske til en sak — nøyaktig én per adresse; en lukket sak åpnes på nytt i stedet for å dobles	av
Obligatoriske sider og innsamlere	Den kanoniske stien til impressum forblir alltid tilgjengelig; maskinell utprøving av fremmede skrivemåter oppdages og blokkeres etter ønske	melde
Tillatelsesliste	Adresser og nett som aldri blir blokkert; fylles daglig fra brannmuren (VPN-motstasjoner) og fra de publiserte adresseområdene til Googlebot og Bingbot	på
Kundetilordning	Et treff fra en kundes nett blir tilordnet kunden — fra tillatelseslisten, aldri gjettet for hånd	på
Domene og identifikator per treff	Hvilket nettsted ble kalt opp, og med hvilken User-Agent — begge deler mangler i tilgangsloggen	på
Analyse	Diagram og pivot over alle treff: per mønster, dag, domene, land, adresse	på
Lokkemat	Sonder får oppdiktede svar med en kanarverdi; den som senere henter den, har lest dem	av
RBL-levering	Blokkeringslisten som ren adresseliste eller JSON på en egen, tokenbeskyttet adresse — for HAProxy, OPNsense og enhver brannmur som leser URL-lister	på

Alt som leveres med rapportere, av eller valgfritt er bevisst slik: Den som aktiverer en blokkering, skal gjøre det fordi vedkommende har fulgt med i noen dager og vet hvem som havner der — ikke fordi forhåndsinnstillingen ville det slik.

Analysen: treff per mønster over sju dager. Den høyeste stolpen er søket etter .env-filer.

RBL-lister: en standardisert måte å levere blokkeringer på

RBL står for Real-time Blackhole List. Begrepet stammer fra e-postverdenen, der Spamhaus og andre siden nittitallet har publisert lister over ondsinnede avsenderadresser. Prinsippet er svært enkelt, og nettopp derfor så utbredt: én adresse per linje, tilgjengelig via HTTP, lastet inn på nytt jevnlig. Intet format som først må tolkes, intet grensesnitt som krever et verktøy.

Praktisk talt enhver brannmur og enhver reverse proxy kan lese inn en slik liste og bygge regler av den. Produsentene kaller det ulike ting, men mekanismen er den samme overalt:

• OPNsense og pfSense — URL Table Alias: laste adresselisten via HTTP, bruke den som alias i brannmurregler, oppdatering på timebasis eller daglig
• HAProxy — ACL-filer og Maps: src -f sperrliste.txt i en http-request deny-regel, kan lastes inn på nytt via kjøretids-API-et uten omstart
• nginx — geo-modulen med innlemmet adressefil, eller deny-direktiver fra en generert include-fil
• Fortinet FortiGate — External Block List eller Threat Feed: en URL som brannmuren henter en IP-liste fra og bruker i retningslinjer
• Palo Alto Networks — External Dynamic List (EDL): samme prinsipp, som egen objekttype i sikkerhetspolicyene
• 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 for blokkeringsregler
• Juniper SRX — Dynamic Address Entries fra feeds
• MikroTik RouterOS — Address Lists, fylt via skript og fetch fra en URL
• CrowdSec — egne lister som kilde for bouncerne på alle støttede systemer

Akkurat i dette formatet leverer Web RBL blokkeringslisten sin. Brannmuren kasserer pakkene før de når webserveren — og med dem ethvert annet forsøk fra samme adresse, for eksempel mot e-postserveren eller VPN-gatewayen.

Begge retninger, men på rett sted

Veien fungerer også motsatt vei: I Web RBL kan man legge inn en hvilken som helst RBL-liste — en URL, ett nivå, ferdig. Tor-utgangsnoder, Spamhaus DROP, FireHOL og blocklist.de er forhåndskonfigurert, flere kommer til med tre klikk. Modulen deler hver liste opp i adresseområder og kontrollerer hver forespørsel mot dem, på noen få mikrosekunder.

Og likevel: Det er mer fornuftig å bruke fremmede lister på brannmuren foran. Av tre grunner. Brannmuren ser alle tjenester, ikke bare HTTP — en adresse fra Spamhaus-listen skal også stoppes ved e-postserveren og VPN-en. Den kasserer på pakkenivå, før en forbindelse i det hele tatt kommer i stand, og koster dermed applikasjonsserveren ingenting. Og den er stedet der slike lister uansett vedlikeholdes; en andre kopi i applikasjonen er et andre sted som kan bli utdatert.

Hva listene i modulen da fortsatt er gode for: det en brannmur ikke kan. Den kjenner ikke noe innloggingsskjema. Web RBL kan nekte en adresse fra Tor-listen tilgang til innloggingen og likevel levere nettstedet — den som vil lese anonymt, skal få lov til det; den som vil prøve seg frem med passord anonymt, får det ikke. Og modulen kan melde en vellykket innlogging fra en oppført adresse som mistenkelig tilfelle. Begge deler trenger listen der innloggingen finner sted.

Vurdering i stedet for magefølelse

En adresse som har spurt etter /wp-login.php én gang, er noe annet enn en som har gått gjennom fem forskjellige mønstre over tre domener på to dager. Web RBL regner dette om til en vurdering fra 0 til 100 — ut fra det modulen selv har observert, uten fremmed tjeneste og uten forespørsel utad.

En oppføring: 99 treff, vurdering 84, og begrunnelsen i klartekst — tyngste mønster, fem forskjellige alvorlige mønstre, to mistenkelige dager, over tjue treff.

Vurderingen avgjør to ting. Fra en justerbar verdi er innlogging forbudt — nettstedet forblir lesbart, men den som allerede har lett etter innloggingsdata, får ingen mulighet til å prøve ut det som ble funnet. Og en vellykket innlogging fra en adresse med vurdering blir rapportert: Da har noen ikke lenger gjettet, men visst. Enten var den rettmessige brukeren på reise, eller så er innloggingsdataene kommet på avveie — modulen avgjør ikke det, den legger det frem for noen som kan spørre. Selve passordet berøres aldri underveis.

Blokkeringslisten, filtrert etter vurdering fra 40: antall treff, mistenkelige dager, berørte domener og siste sti per adresse.

Hva Web RBL beskytter — beskyttelsen i detalj

1. Innloggingsdata forblir uoppdaget

Den største målte angrepsklassen leter ikke etter sårbarheter i Odoo, men etter hemmeligheter som er blitt liggende. Over sytten dager:

• 57.721 forespørsler etter .env-filer — der ligger databasepassord, API-nøkler og sesjonshemmeligheter
• 5.535 forespørsler etter konfigurasjonsfiler
• 4.388 forespørsler etter skytilgangsdata: credentials.json, service-account.json, firebase-adminsdk.json, rclone.conf, .git-credentials
• 2.811 forespørsler etter .git-kataloger — den som finner en, laster ned hele kildekoden med historikk
• 1.907 forespørsler etter byggeinstruksjoner som .github/workflows/deploy.yml eller .gitlab-ci.yml, der registre og nøkkelnavn står oppført

Det avgjørende er ikke antallet forespørsler, men antallet forskjellige adresser: /credentials.json kom fra 98 adresser, /.git-credentials fra 92. Det er ingen enkelt skanner, men et standardrepertoar som kjører over hele verden samtidig.

2. Innloggingsforsøk går i tomme intet — varig

Odoo har en egen brems mot utprøving av passord. Den har tre grenser som er dokumentert i selve Odoo-kildekoden: Telleren ligger i arbeidsminnet til arbeidsprosessen og nullstilles ved hver omstart, den forsinker bare i stedet for å blokkere, og den teller utelukkende forsøk som kommer frem til passordkontrollen.

Web RBL setter inn på de samme stedene, men skriver til databasen. Dermed gjelder:

• Tilstanden overlever enhver omstart og gjelder på tvers av alle arbeidsprosesser
• Det registreres begge veier: innloggingsskjemaet /web/login og grensesnittene /xmlrpc/2/common og /jsonrpc
• Det registreres også forsøk som aldri kommer frem til passordkontrollen — for eksempel innlogginger uten gyldig sesjonsmerke
• En mislykket tilgang til databasebehandleren blir også talt med; det er det mest alvorlige innloggingsforsøket overhodet

Terskelen for innlogginger er satt til ti, og grunnen er en måling: Av ni mislykkede innlogginger på sytten dager kom flertallet fra kunder som satte opp tilgangen selv på et annet apparat og da oppga feil domene — i ett tilfelle sitt eget, bare med bindestrek i stedet for punktum. En blokkering ved første mislykkede forsøk hadde dermed ikke rammet angripere, men kunder under oppsettet.

Den som derimot banker videre selv om serveren allerede har svart «vent litt», blir umiddelbart blokkert. Denne meldingen leser et menneske og venter; den som ignorerer den, er et program. Et eget mønster med terskel null fanger akkurat dette tilfellet, og det kan ikke ramme en kollega: Dit kommer bare den som allerede har ti mislykkede forsøk bak seg og deretter fortsetter.

3. Angrepet koster serveren ingenting lenger

En sonde mot en sti som /@fs/../../.env var dyrt før modulen: Odoo leter etter feilsiden, rendrer den, snubler under oppbyggingen av adressen i punktsegmentene og feiler deretter også på feilsiden til feilsiden. To stakksporinger per sonde. Det ble målt 28.401 slike feil på sytten dager, i tillegg til 9.467 følgefeil.

Web RBL setter inn i ir.http._match, altså før rutefinningen. Svaret gis uten mal, uten databasetilgang utover blokkeringskontrollen og uten logglinje. Kontrollen mot tillatelsesliste, trusselister og landsregler kjører fra bufferen over sorterte adresseområder — noen få mikrosekunder, selv ved over tretti tusen områder.

4. Brannmuren kaster angriperen ut før han kommer frem

Blokkeringslisten publiseres som RBL-liste som HAProxy og OPNsense leser direkte. Angriperen når dermed ikke lenger webserveren — og heller ingen annen tjeneste på samme vert. En tilgang som én gang er gjenkjent som ondsinnet, beskytter slik bakover i tid hele maskinen.

Tre nivåer: blokkere, telle, rapportere

Ikke enhver forespørsel i det blå er et angrep. Web RBL skiller derfor mellom tre nivåer, og nivået kan stilles om per mønster, uten å røre koden.

Nivå	Forespørselen som utløser	Konsekvens for adressen
blokkere	avvises	blokkert i 24 timer, permanent etter tre mistenkelige dager
telle	går gjennom	bare registrert, ingen blokkering
rapportere	går gjennom	registrert med funntekst, blir aldri blokkert

For trusselister og land finnes det et fjerde: ingen tilgang til innlogging. Nettstedet forblir lesbart, innloggingsskjema og grensesnitt er stengt. Det er mellomveien for alt som er mistenkelig, men ikke nødvendigvis ondsinnet — Tor, et datasenterområde, et land uten kunder.

Hvilke angrep som gjenkjennes

Alle mønstre er testet mot ekte trafikk. Antallet forskjellige adresser står bevisst ved siden av — det viser om et mønster treffer én enkelt skanner eller en utbredt framgangsmåte.

Angrepsklasse	Forespørsler	Adresser
.env-uthenting	57.721	223
PHP-sonder	12.237	256
Sti-traversering med lukrativt mål	10.046	64
Konfigurasjonsfiler	5.535	114
Skytilgangsnøkler	4.388	152
WordPress-sonder	3.366	385
.git-uthenting	2.811	255
Odoo-rekognosering (databasebehandler, versjonsforespørsel)	2.500	213
KI-verktøykjeder og kommandokjøring (/mcp, /api/fs/exec)	2.450	74
Byggeinstruksjoner (CI/CD)	1.907	88
GraphQL-endepunkter	1.878	71

Den nyeste klassen er bemerkelsesverdig. /api/fs/exec ble forespurt 369 ganger fra 54 forskjellige adresser — det er ingen lesetilgang, men et forsøk på å kjøre kommandoer. Slike mål fantes ikke for to år siden; de stammer fra grensesnitt til nye KI-verktøy og oppgavekøer. Den som bare retter forsvaret mot WordPress og PHP, ser ingenting av dette. I vurderingen veier denne klassen tilsvarende tungt.

Trusselister og opprinnelsesland

Fire lister, 32.851 adresseområder, alle satt til «bare rapportere». Hver ytterligere liste er én adresse og ett nivå.

En fremmed liste er en påstand som noen andre fremsetter, av grunner vi ikke kjenner, om trafikk vi aldri har sett. Den kan være feil, utdatert eller ment for et annet formål: blocklist.de samler først og fremst adresser som andre steder har prøvd seg frem med SSH-innlogginger, og det sier lite om en webserver. Derfor fører Web RBL fremmede lister adskilt fra den egne blokkeringslisten, og derfor er forhåndsinnstillingen rapportere. Og vår egen tillatelsesliste vinner alltid: En kunde som vi kjenner, veier tyngre enn en tredjeparts vurdering.

Opprinnelseslandet står ved hvert treff og hver adresse. For vurderingen er det uerstattelig — et innloggingsforsøk fra eget land klokken ti om formiddagen er noe annet enn et fra et land uten en eneste kunde. Til generell utestengning duger det lite, og det sier våre egne tall: Angriperne i listen vår kom overveiende fra skyområder i Belgia, Finland og Nederland. En blokkering av alt utenfor det tysktalende området hadde ikke rammet dem — men derimot egne medarbeidere på ferie og kunder på forretningsreise.

Landsregler leveres tomme, og visningen forklarer hvorfor.

Rapportere feilkonfigurasjoner i stedet for å blokkere

Det vanligste tilfellet i ekte trafikk er verken angrep eller besøkende, men defekt programvare som tar webserveren for noe annet:

• 1.367 kall mot webgrensesnittet til en QNAP-NAS — en synkroniseringsklient hvis mål ikke stemmer lenger. Én enkelt tilkobling banket på 962 ganger.
• 65 Autodiscover-forespørsler — en Outlook som tar webdomenet for å være sin Exchange

Slike adresser blir aldri blokkert. En blokkering utbedrer ikke feilen, den skjuler den — og rammer den hvis enhet allerede er feil innstilt. I stedet opprettes en oppføring med funntekst og de berørte domenene, som etter ønske automatisk blir til en sak: nøyaktig én per adresse, og hvis den lukkes og adressen dukker opp igjen, åpnes den samme saken på nytt i stedet for at det opprettes en andre.

Gjenkjent blir QNAP, Synology, Exchange Autodiscover, ActiveSync samt WebDAV-, CalDAV- og CardDAV-klienter. Mønstrene angir eksakte filnavn og kataloger, aldri bare filendelser: I samme katalog /cgi-bin/ ligger de ufarlige synkroniseringskallene rett ved siden av klassiske sonder som printenv.pl.

Tillatelseslisten: adresser som aldri blir blokkert

Prisen for en feil er ikke lik for alle adresser. Ved en skanner fra et datasenter koster en falsk alarm ingenting. Ved motstasjonen til en stedstunnel koster den hele stedet.

Derfor finnes det en andre liste som står foran den første: adresser og nett som aldri blir blokkert. Den demper ikke noe — den som står på den, blir fortsatt kontrollert og registrert, bare konsekvensen faller bort. Det er forskjellen fra en unntaksregel i brannmuren: Den gjør blind, denne gjør bare tålmodig.

Den fylles daglig fra to kilder: fra selve brannmuren med alle VPN-motstasjoner, slik at en nyoppsatt tunnel ikke er avhengig av at noen husker blokkeringslisten — og fra de publiserte adresseområdene til Google og Microsoft for deres crawlere. Bare slik kan en ekte Googlebot skilles fra en skanner som kaller seg det. Søkemotorer må aldri blokkeres; den som stenger dem ute, tar siden sin ut av indekseringen uten vei tilbake.

Her gjelder en regel som er viktigere enn avstemmingen: Et tomt svar sletter aldri. Svarer kilden ikke, tomt eller uforståelig, forblir listen uendret. En tillatelsesliste som tømmer seg selv ved en feil, tar i verst tenkelige øyeblikk med seg alle tunneler.

Har en oppføring i tillatelseslisten en kunde, blir hvert treff fra dennes nett tilordnet kunden. En feilkonfigurasjon har dermed umiddelbart en kontaktperson, uten at noen må slå opp adresser.

Obligatoriske opplysninger og automatiserte datainnsamlere

Impressum er ingen vanlig side. Den må forbli tilgjengelig for mennesker, for en blokkering der skaper nettopp bruddet som en innsamler leter etter. Samtidig er det siden der navn og adresse står — og dermed målet for maskinell høsting.

Under den østerrikske bølgen av varselbrev på grunn av innbygde Google-skrifttyper viste loggene at brevene ikke stammet fra enkeltbesøk, men fra et automatisert rundskudd: ulike, urelaterte verter med noen millisekunders mellomrom.

Web RBL løser dette med nedgradering i stedet for unntak. Den kanoniske stien /impressum treffer ikke noe mønster og forblir alltid tilgjengelig. Fremmede skrivemåter som /impressum.php — som ikke kan finnes på en Odoo-side — blir rapportert, og den som ikke vil finne seg i den maskinelle høstingen, stiller om en parameter. sitemap og robots er unntatt og kan i utgangspunktet ikke blokkeres: De inneholder ingen personopplysninger, og å hente dem er oppgaven til enhver søkemotor-crawler.

Domene og identifikator: det som mangler i tilgangsloggen

Tilgangsloggen til werkzeug skriver verken ned verten som ble kalt opp eller identifikatoren til den som kaller. Odoo får begge deler selvfølgelig — uten verten kunne det ved flere nettsteder ikke velge det riktige. Men man kan ikke slå det opp etterpå.

Web RBL registrerer begge deler per treff. Det besvarer to spørsmål som ellers ikke lar seg besvare: hvilket nettsted en feilkonfigurasjon kaller — og dermed hvilken kunde domenet tilhører — og om en adresse besøker én side eller alle. Flere urelaterte domener fra samme adresse er kjennetegnet på rundskuddet, og de øker vurderingen.

Hvor mye identifikatoren betyr, viste en analyse på et av våre nettsteder: Over sytti prosent av all trafikk skyldtes der én eneste oppringer, fordelt på mer enn hundre adresser. Uten identifikatoren hadde det sett ut som en distribuert scraper. Det var GPTBot, crawleren til OpenAI — den spurte gang på gang etter robots.txt og oppførte seg helt korrekt.

Sikkerhetsaspektene i detalj

1. Proxy-gjenkjenningen — det farligste punktet av alle

Kjører Odoo bak en reverse proxy og er proxy_mode feil satt, ser modulen den samme adressen ved hver forespørsel: proxyens. En blokkering ville da stenge ute alle besøkende samtidig.

Derfor kontrollerer Web RBL før hver blokkering om adressebestemmelsen er pålitelig. Den krever proxy_mode sammen med en videresendings-header, nekter å arbeide hvis en videresending kommer inn uten proxy_mode, og nekter det også ved mer enn én mellomliggende proxy. Ved tvil blir det ikke blokkert.

2. Aldri egne nett

Private adresseområder, loopback, link-local og CGNAT er fast unntatt. De kan under ingen omstendighet havne på listen, heller ikke for hånd. Det samme gjelder fremmede lister: Private og reserverte områder samt absurd store nett forkastes ved innlesingen.

3. En egen feil må ikke ta nettstedet med seg

Hele kontrollen kjører i en sikring som fanger opp enhver feil. Det som går galt her, blir logget, og forespørselen fortsetter uendret. En beskyttelsesmodul som tar nettstedet med seg ved en egen feil, er verre enn ingen. Alle spørringer i forespørselsveien kjører dessuten uten besøkendes nettleserspråk og uten sortering etter oversatte felt — en besøkende med et språk som ikke er installert, må ikke kunne få kontrollen to feile.

4. Observere før man blokkerer

Etter installasjonen er blokkering av oppførte adresser ved vanlige forespørsler slått av. Sonder avvises og registreres, alt annet går gjennom. Slik kan man følge med noen dager på hvem som faktisk havner på listen før noen blir stengt ute. Det samme gjelder atferdsgjenkjenning, trusselister og landsregler: rapportere først, blokkere etter vurdering.

5. Smale mønstre i stedet for brede nett

En feilaktig gjenkjent besøkende er dyrere enn en oversett sonde. Hvert mønster bærer derfor sitt nivå, og det kan stilles om per mønster. En filendelse alene er sjelden nok: Ved .php står 14.012 ekte sonder mot en håndfull gamle lenker, ved .asp er forholdet omvendt. Slike avgjørelser skal måles, ikke anslås.

6. En frigivelse for hånd blir stående

Den som frigir en adresse, hadde en grunn. Et nytt treff setter ikke denne avgjørelsen stilltiende ut av kraft.

7. Listen er beskyttet, men ingen hemmelighet

Endepunktet krever et token og svarer uten gyldig token med 404, ikke med 403 — at adressen eksisterer, blir dermed ikke engang bekreftet. Sammenligningen kjører med konstant tid. Selve listen inneholder ikke noe fortrolig: Den består av adresser som på eget initiativ har banket på hos oss.

8. Ingen hemmeligheter i regnskapet

Ved mislykkede innlogginger noteres det forsøkte brukernavnet, aldri passordet. Ved databasebehandleren leses det ingenting ut av de overleverte verdiene: Der står hovedpassordet helt fremst, og en oppføring i en blokkeringsliste havner i hver databasesikkerhetskopi. Lisensnøkkelen for GeoLite2 står bare i systemparameteren og ikke i noen logglinje.

9. Lokkematen røper ikke noe brukbart

Valgfritt svarer Web RBL på sonder med oppdiktet innhold som inneholder en entydig kanarverdi. Den som senere henter denne verdien, har lest det forfalskede svaret og handlet deretter — en falsk alarm er dermed utelukket. Lokkematen inneholder ingen brukbare opplysninger, ingen ekte stier og ingen gyldige innloggingsdata. Denne funksjonen leveres avslått, for den endrer atferden på en måte som er synlig utad.

Hva modulen ikke kan

Den erstatter ingen brannmur og ingen Web Application Firewall. Den gjenkjenner kjente sonderingsmønstre i stier, mislykkede innlogginger og mistenkelig atferd — ikke angrep på skjemaer, ikke innsmuglingsforsøk i parametere.

Den ser dessuten bare det som kommer tilbake over HTTP. Det en angriper gjør med stjålne database- eller postkassetilganger, forblir usynlig — og nettopp derfor er kanarverdiene stier og ikke innloggingsdata.

Og den erstatter ikke aktsomhet: En modul som avviser .env-sonder, gjør ikke en ved en feil levert .env-fil ufarlig.

Tilgjengelighet

Web RBL er offentlig tilgjengelig under AGPL-3 og kjører produktivt hos oss på fem nettsteder:

github.com/Alex0176/odoo-web-rbl

Modulen forutsetter Odoo 19 Community og har ingen avhengigheter utenom base og web. Sakskoblingen er valgfri og krever ikke noe bestemt sakssystem; uten et slikt skjer det rett og slett ingenting. Opprinnelseslandet trenger den gratis GeoLite2-databasen fra MaxMind; mangler den, forblir feltet tomt og alt annet fungerer uendret.

Les videre: Hvordan Web RBL passer inn i en komplett sikkerhetsarkitektur -- sammen med brannmur, tofaktorautentisering og rettigheter, inkludert trinn-for-trinn-veiledning: Kombinere sikkerhetsarkitekturen i Odoo 19 riktig.

Spørsmål, merknader og feilrapporter tar vi gjerne imot — helst som issue på GitHub.