Odoo 19 Community: Web RBL – spärrlista för attacktrafik mot de egna webbplatserna

Källkod: github.com/Alex0176/odoo-web-rbl — AGPL-3, fritt användbar.

Den som driver en Odoo-server på internet får besök. Inte låt vara då och då, utan oavbrutet. Under sjutton dagar har vi på våra fem webbplatser loggat och utvärderat 731 297 förfrågningar. 110 511 av dem var inga besökare, utan automatiserad sökning efter sårbarheter, inloggningsuppgifter och konfigurationsfiler.

Det här inlägget beskriver Web RBL, en modul med öppen källkod för Odoo 19 Community som identifierar, värderar, bokför och avvisar den här trafiken — och som publicerar spärrlistan som RBL-lista, alltså i det format som brandväggar och reverse proxys läser direkt. Alla siffror kommer från skarp drift.

Vad modulen kan — funktionerna i överblick

Funktion	Vad den gör	Leverans
Mönsterigenkänning	Identifierar sondering via sökväg och filändelse: .env, .git, konfigurationsfiler, molnnycklar, CI/CD-bygganvisningar, WordPress, PHP, path traversal, databashanterare, GraphQL, kommandoexekvering via /api/fs/exec och liknande gränssnitt	blockera
Tre nivåer per mönster	blockera, räkna eller rapportera — kan ställas om per mönster, utan kod	per mönster
Trösklar	Så många träffar av samma mönster innan blockering; för inloggningar tio	10 vid inloggning
Inloggningsskydd	Misslyckade inloggningar via formulär och XML-RPC/JSON-RPC, misslyckade sessionskontroller, åtkomst till databashanteraren — i databasen, inte i arbetsminnet	på
Botigenkänning vid inloggningen	Den som ignorerar väntemeddelandet efter tio misslyckade försök och fortsätter knacka blockeras omedelbart	blockera
Beteendeigenkänning	Adresser som på fem minuter genererar tjugo felsidor och knappt någon träffsida — alltså gissar i stället för att läsa	rapportera
Värdering 0–100	Hur säkert är det att en angripare står bakom adressen? Utifrån mönstrets allvarlighetsgrad, antal olika mönster, anmärkningsvärda dagar, berörda domäner och antal träffar — med motivering i klartext	på
Inloggningsspärr efter värdering	Från en inställbar värdering är inloggning förbjuden, webbplatsen förblir läsbar	från 40
Misstanke om stulna inloggningsuppgifter	En lyckad inloggning från en misstänkt adress rapporteras och kan på begäran tilldelas som uppgift — en gång per adress och dag	på
Hotlistor	Tor-utgångsnoder, Spamhaus DROP, FireHOL Level 1 och blocklist.de är förkonfigurerade; valfri ytterligare RBL-lista kan läggas till via adress, daglig avstämning, egen nivå per lista	rapportera
Ingen åtkomst till inloggningen	Den fjärde nivån för listor och länder: webbplatsen går att läsa, inloggningsformuläret och gränssnitten är stängda — rätt svar på Tor	Alternativ
Ursprungsland	Land per träff och adress via GeoLite2; modulen uppdaterar databasen själv med en kostnadsfri licensnyckel	visa
Landsregler	Blockera, ingen åtkomst till inloggningen, rapportera eller uttryckligen tillåt — per land, medvetet utan förval	inga
Felkonfigurationer	QNAP, Synology, Exchange Autodiscover, ActiveSync och WebDAV/CalDAV/CardDAV identifieras, blockeras aldrig och läggs i en arbetslista med resultat och berörd domän	rapportera
Ärende per adress	Av ett fynd blir på begäran ett ärende — exakt ett per adress, ett stängt ärende öppnas igen i stället för att dupliceras	av
Obligatoriska sidor och datainsamlare	Den kanoniska sökvägen till impressum är alltid nåbar; automatiserad provning av främmande stavningar upptäcks och blockeras på begäran	rapportera
Tillåtelselista	Adresser och nätverk som aldrig blockeras; fylls dagligen från brandväggen (VPN-motparter) och från de publicerade adressintervallen för Googlebot och Bingbot	på
Kundkoppling	En träff från en kunds nätverk kopplas till kunden — utifrån tillåtelselistan, aldrig gissat för hand	på
Domän och identifierare per träff	Vilken webbplats som anropades och med vilken user-agent — båda saknas i åtkomstloggen	på
Utvärdering	Diagram och pivot över alla träffar: per mönster, dag, domän, land och adress	på
Lockbete	Sonder får påhittade svar med ett kanarievärde; den som senare hämtar det har läst dem	av
RBL-leverans	Spärrlistan som ren adresslista eller JSON på en egen adress skyddad med token — för HAProxy, OPNsense och varje brandvägg som läser URL-listor	på

Allt som levereras med rapportera, av eller alternativ är medvetet så: Den som aktiverar en spärr på riktigt ska göra det eftersom hen har sett på i några dagar vem som drabbas — inte eftersom förvalet ville det.

Utvärderingen: träffar per mönster under sju dagar. Den högsta stapeln är sökningen efter .env-filer.

RBL-listor: ett standardiserat sätt att leverera spärrar

RBL står för Real-time Blackhole List. Begreppet kommer från e-postvärlden, där Spamhaus och andra sedan nittiotalet publicerar listor över skadliga avsändaradresser. Principen är mycket enkel och just därför så utbredd: en adress per rad, hämtbar via HTTP, omladdad regelbundet. Inget format som först måste tolkas, inget gränssnitt som kräver ett verktyg.

Praktiskt taget varje brandvägg och varje reverse proxy kan läsa in en sådan lista och bygga regler av den. Tillverkarna kallar det olika, men mekanismen är densamma överallt:

• OPNsense och pfSense — URL Table Alias: hämta adresslistan via HTTP, använd den som alias i brandväggsregler, uppdatering varje timme eller varje dag
• HAProxy — ACL-filer och Maps: src -f sperrliste.txt i en http-request deny-regel, kan laddas om via runtime-API:et utan omstart
• nginx — geo-modulen med inkluderad adressfil, eller deny-direktiv från en genererad include-fil
• Fortinet FortiGate — External Block List resp. Threat Feed: en URL från vilken brandväggen hämtar en IP-lista och använder den i policyer
• Palo Alto Networks — External Dynamic List (EDL): samma princip, som en egen objekttyp i säkerhetspolicyerna
• Check Point — Custom Intelligence Feeds och IP Block Lists via en URL
• Cisco Secure Firewall (Firepower) — Security Intelligence Feeds med egna listkällor
• Sophos Firewall — Third-Party Threat Feeds: adresslistor från en URL som källa för blockeringsregler
• Juniper SRX — Dynamic Address Entries från flöden
• MikroTik RouterOS — Address Lists, fylls via skript och fetch från en URL
• CrowdSec — egna listor som källa för bouncers på varje system som stöds

Just i det här formatet levererar Web RBL sin spärrlista. Brandväggen kastar paketen innan de når webbservern — och med dem varje annat försök från samma adress, till exempel mot e-postservern eller VPN-gatewayen.

Båda riktningarna, men på rätt ställe

Vägen fungerar också åt andra hållet: I Web RBL går det att lägga in valfri RBL-lista — en URL, en nivå, klart. Tor-utgångsnoder, Spamhaus DROP, FireHOL och blocklist.de är förkonfigurerade, fler tillkommer med tre klick. Modulen delar upp varje lista i adressintervall och kontrollerar varje förfrågan mot dem, på några få mikrosekunder.

Och ändå: Det är mer meningsfullt att använda främmande listor på brandväggen i förväg. Av tre skäl. Brandväggen ser alla tjänster, inte bara HTTP — en adress från Spamhaus-listan ska också stoppas vid e-postservern och VPN:et. Den kastar paket på paketnivå, innan en anslutning över huvud taget kommer till stånd, och kostar därmed applikationsservern ingenting. Och den är platsen där sådana listor ändå underhålls; en andra kopia i applikationen är ett andra ställe som kan bli inaktuellt.

Vad listorna i modulen då är bra för: det som en brandvägg inte kan. Den känner inte till något inloggningsformulär. Web RBL kan nekta en adress från Tor-listan åtkomst till inloggningen och ändå leverera webbplatsen — den som vill läsa anonymt ska få göra det; den som vill prova lösenord anonymt ska inte få det. Och den kan rapportera en lyckad inloggning från en listad adress som misstänkt fall. Båda delarna kräver listan där inloggningen sker.

Bedömning i stället för magkänsla

En adress som en enda gång har frågat efter /wp-login.php är något annat än en som under två dagar har gått fram med fem olika mönster över tre domäner. Web RBL räknar om detta till en poäng från 0 till 100 — utifrån det den själv har sett, utan extern tjänst och utan förfrågan utåt.

En post: 99 träffar, poäng 84, och motiveringen i klartext — svåraste mönstret, fem olika allvarliga mönster, två påfallande dagar, över tjugo träffar.

Poängen avgör två saker. Från ett inställbart värde är inloggning förbjuden — webbplatsen förblir läsbar, men den som redan har letat efter inloggningsuppgifter får ingen möjlighet att prova dem. Och en lyckad inloggning från en adress med poäng rapporteras: Då har någon inte längre gissat utan vetat. Antingen var den behöriga användaren på resa, eller så har inloggningsuppgifterna kommit på avvägar — modulen avgör inte vilket, den lägger fallet hos någon som kan fråga. Själva lösenordet berörs aldrig.

Spärrlistan, filtrerad på poäng från 40: antal träffar, påfallande dagar, berörda domäner och senaste sökväg per adress.

Vad Web RBL skyddar — skyddseffekten i detalj

1. Inloggningsuppgifter förblir oupptäckta

Den största uppmätta angreppsklassen letar inte efter säkerhetshål i Odoo, utan efter bortglömda hemligheter. Under sjutton dagar:

• 57 721 förfrågningar efter .env-filer — där finns databaslösenord, API-nycklar och sessionshemligheter
• 5 535 förfrågningar efter konfigurationsfiler
• 4 388 förfrågningar efter molninloggningsuppgifter: credentials.json, service-account.json, firebase-adminsdk.json, rclone.conf, .git-credentials
• 2 811 förfrågningar efter .git-kataloger — den som hittar en laddar ner hela källkoden inklusive historik
• 1 907 förfrågningar efter byggbeskrivningar som .github/workflows/deploy.yml eller .gitlab-ci.yml, där register och nyckelnamn står

Avgörande är inte antalet förfrågningar, utan antalet olika adresser: /credentials.json kom från 98 adresser, /.git-credentials från 92. Det är ingen enskild skanner, utan en standardrepertoar som körs över hela världen samtidigt.

2. Inloggningsförsök går i stöpet — varaktigt

Odoo har en egen broms mot att prova sig fram till lösenord. Den har tre begränsningar, som är dokumenterade i själva Odoo-källkoden: Räknaren ligger i arbetsminnet hos arbetsprocessen och nollställs vid varje omstart, den fördröjer bara i stället för att blockera, och den räknar endast försök som tar sig ända till lösenordskontrollen.

Web RBL sätter in på samma ställen, men skriver till databasen. Därmed gäller:

• Statusen överlever varje omstart och gäller över alla arbetsprocesser
• Båda vägarna registreras: inloggningsformuläret /web/login och gränssnitten /xmlrpc/2/common och /jsonrpc
• Även försök som aldrig når lösenordskontrollen registreras — till exempel inloggningar utan giltigt sessionsmärke
• Ett misslyckat försök att nå databashanteraren räknas med; det är det allvarligaste inloggningsförsöket över huvud taget

Tröskeln för inloggningar står på tio, och skälet är en mätning: Av nio misslyckade inloggningar på sjutton dagar kom de flesta från kunder som själva ställde in åtkomsten på ytterligare en enhet och därvid angav fel domän — i ett fall den egna, bara med bindestreck i stället för punkt. En spärr vid första misslyckade försöket hade därmed inte träffat angripare, utan kunder under installationen.

Den som däremot fortsätter knacka fast servern redan har svarat ”vänta ett ögonblick” blir omedelbart blockerad. Det meddelandet läser en människa och väntar; den som ignorerar det är ett program. Ett eget mönster med tröskel noll fångar just detta fall, och det kan inte drabba en kollega: Dit kommer bara den som redan har tio misslyckade försök bakom sig och därefter fortsätter.

3. Angreppet kostar servern ingenting längre

En sond mot en sökväg som /@fs/../../.env var före modulen dyr: Odoo letar efter felsidan, renderar den, snubblar vid uppbyggnaden av adressen över punktsegmenten och misslyckas sedan även med felsidan för felsidan. Två stackspår per sond. Uppmätt var 28 401 sådana fel på sjutton dagar, dessutom 9 467 följdfel.

Web RBL ingriper i ir.http._match, alltså före vägvalet. Svaret ges utan mall, utan databasåtkomst utöver spärrkontrollen och utan loggrad. Kontrollen mot tillåtelselista, hotlistor och landsregler körs från cachen över sorterade adressintervall — några få mikrosekunder, även vid över trettiotusen intervall.

4. Brandväggen kastar ut angriparen innan han hinner fram

Spärrlistan publiceras som RBL-lista som HAProxy och OPNsense läser direkt. Angriparen når webbservern alltså inte längre alls — och inte heller någon annan tjänst på samma värd. Ett en gång som skadligt identifierat anrop skyddar på så sätt hela maskinen i efterhand.

Tre nivåer: blockera, räkna, rapportera

Inte varje förfrågan som går i tomma luften är ett angrepp. Web RBL skiljer därför mellan tre nivåer, och nivån kan ställas om per mönster, utan att man rör koden.

Nivå	Den utlösande förfrågan	Följd för adressen
blockera	avvisas	blockeras i 24 timmar, efter tre påfallande dagar permanent
räkna	släpps igenom	bara bokförd, ingen spärr
rapportera	släpps igenom	bokförd med fyndtext, blockeras aldrig

För hotlistor och länder finns en fjärde: ingen åtkomst till inloggningen. Webbplatsen förblir läsbar, inloggningsformulär och gränssnitt är stängda. Det är mellanvägen för allt som är misstänkt men inte behöver vara skadligt — Tor, ett datacenterintervall, ett land utan kunder.

Vilka angrepp som upptäcks

Alla mönster är testade mot verklig trafik. Antalet olika adresser står medvetet bredvid — det visar om ett mönster träffar en enskild skanner eller ett utbrett förfarande.

Angreppsklass	Förfrågningar	Adresser
.env-avläsning	57.721	223
PHP-sonder	12.237	256
Path traversal mot lönsamt mål	10.046	64
Konfigurationsfiler	5.535	114
Molnåtkomstnycklar	4.388	152
WordPress-sonder	3.366	385
.git-avläsning	2.811	255
Odoo-rekognosering (databashanterare, versionsförfrågan)	2.500	213
AI-verktygskedjor och kommandokörning (/mcp, /api/fs/exec)	2.450	74
Byggbeskrivningar (CI/CD)	1.907	88
GraphQL-slutpunkter	1.878	71

Den senaste klassen är anmärkningsvärd. /api/fs/exec anropades 369 gånger från 54 olika adresser — det är inte en läsåtkomst, utan ett försök att köra kommandon. Sådana mål fanns inte för två år sedan; de härrör från gränssnitt i nya AI-verktyg och uppgiftsköer. Den som bara riktar sitt försvar mot WordPress och PHP ser inget av detta. I poängsättningen väger denna klass följaktligen tungt.

Hotlistor och ursprungsland

Fyra listor, 32 851 adressintervall, alla på ”endast rapportera”. Varje ytterligare lista är en adress och en nivå.

En främmande lista är ett påstående som någon annan ställer upp, av skäl vi inte känner till, om trafik vi aldrig har sett. Den kan vara fel, föråldrad eller avsedd för ett annat syfte: blocklist.de samlar framför allt adresser som någon annanstans har provat SSH-inloggningar, och det säger föga om en webbserver. Därför för Web RBL främmande listor åtskilda från den egna spärrlistan, och därför är förvalet rapportera. Och den egna tillåtelselistan vinner alltid: En kund som vi känner väger tyngre än en tredje parts bedömning.

Ursprungslandet står vid varje träff och varje adress. För bedömningen är det oumbärligt — ett inloggningsförsök från eget land klockan tio på förmiddagen är något annat än ett från ett land utan en enda kund. För generell utestängning duger det dåligt, och det säger våra egna siffror: Angriparna i vår lista kom övervägande från molnintervall i Belgien, Finland och Nederländerna. En spärr för allt utanför den tysktalande regionen hade inte träffat dem — däremot egna medarbetare på semester och kunder på affärsresa.

Landsregler levereras tomma, och vyn förklarar varför.

Rapportera felkonfigurationer i stället för att blockera

Det vanligaste fallet i verklig trafik är varken angrepp eller besökare, utan trasig programvara som tar webbservern för något annat:

• 1 367 anrop mot webbgränssnittet på en QNAP-NAS — en synkroniseringsklient vars mål inte stämmer längre. En enda anslutning knackade på 962 gånger.
• 65 Autodiscover-förfrågningar — en Outlook som tar webbdomänen för sin Exchange

Sådana adresser blockeras aldrig. En spärr åtgärdar inte felet, den döljer det — och drabbar den vars enhet redan är felinställd. I stället skapas en post med fyndtext och de berörda domänerna, av vilken det på begäran automatiskt blir ett ärende: exakt ett per adress, och stängs det och adressen sticker ut på nytt, öppnas samma ärende igen i stället för att ett andra skapas.

QNAP, Synology, Exchange Autodiscover, ActiveSync samt WebDAV-, CalDAV- och CardDAV-klienter identifieras. Mönstren anger exakta filnamn och kataloger, aldrig bara ändelser: I samma katalog /cgi-bin/ ligger de ofarliga synkroniseringsanropen direkt bredvid klassiska sonder som printenv.pl.

Tillåtelselistan: adresser som aldrig blockeras

Priset för ett misstag är inte detsamma för alla adresser. För en skanner från ett datacenter kostar ett falsklarm ingenting. För motparten i en platstunnel kostar det platsen.

Därför finns en andra lista som står före den första: adresser och nätverk som aldrig blockeras. Den tystar inget — den som står på den kontrolleras och bokförs fortfarande, bara följden uteblir. Det är skillnaden mot ett undantag i brandväggen: Det gör en blind, den här gör en bara tålmodig.

Den fylls dagligen från två källor: från själva brandväggen med alla VPN-motparter, så att en nyinrättad tunnel inte behöver förlita sig på att någon kommer ihåg spärrlistan — och från de publicerade adressintervallen för Google och Microsoft för deras crawlers. Bara så går det att skilja en äkta Googlebot från en skanner som kallar sig så. Sökmotorer får aldrig blockeras; den som stänger ute dem tar bort sin webbplats ur indexeringen utan väg tillbaka.

Här gäller en regel som är viktigare än avstämningen: Ett tomt svar raderar aldrig. Svarar källan inte, tomt eller obegripligt, förblir listan oförändrad. En tillåtelselista som tömmer sig själv vid ett fel tar i sämsta tänkbara stund med sig alla tunnlar.

Om en post i tillåtelselistan har en kund kopplad, kopplas varje träff från dennes nätverk till kunden. En felkonfiguration har därmed omedelbart en kontaktperson, utan att någon behöver slå upp adresser.

Obligatoriska uppgifter och automatiserade datainsamlare

Impressum är ingen vanlig sida. Den måste förbli nåbar för människor, för en spärr där skapar just den överträdelse som en insamlare söker. Samtidigt är det sidan där namn och adress står — och därmed målet för maskinell skörd.

Vid den österrikiska vågen av varningsbrev på grund av inbäddade Google-typsnitt visade loggarna att breven inte kom från enstaka besök, utan från en automatiserad rundmaning: olika, osammanhängande värdar med millisekunders mellanrum.

Web RBL löser detta genom nedgradering i stället för undantag. Den kanoniska sökvägen /impressum träffas inte av något mönster och förblir alltid nåbar. Främmande stavningar som /impressum.php — som inte kan finnas på en Odoo-sida — rapporteras, och den som inte vill acceptera den maskinella skörden ställer om en parameter. sitemap och robots är undantagna och kan i princip inte blockeras: De innehåller inga personuppgifter, och att hämta dem är varje sökmotors crawlers uppgift.

Domän och identifierare: det som saknas i åtkomstloggen

Åtkomstloggen från werkzeug skriver varken ned den anropade värden eller anroparens identifierare. Odoo får naturligtvis båda — utan värden kunde den vid flera webbplatser inte alls välja rätt. Men i efterhand går det inte att läsa upp det.

Web RBL registrerar båda per träff. Det besvarar två frågor som annars inte går att besvara: vilken webbplats som en felkonfiguration anropar — och därmed vilken kund domänen tillhör — och om en adress besöker en sida eller alla. Flera osammanhängande domäner från samma adress är kännetecknet för rundmaningen, och de höjer poängen.

Hur mycket identifieraren betyder visade en utvärdering på en av våra webbplatser: Över sjuttio procent av hela trafiken kom där från en enda anropare, fördelad över mer än hundra adresser. Utan identifieraren hade det sett ut som en distribuerad scraper. Det var GPTBot, OpenAI:s crawler — den frågade gång på gång efter robots.txt och betedde sig helt korrekt.

Säkerhetsaspekterna i detalj

1. Proxyidentifieringen — den farligaste punkten över huvud taget

Körs Odoo bakom en reverse proxy och är proxy_mode felaktigt inställt, ser modulen vid varje förfrågan samma adress: proxyns. En spärr skulle då stänga ute alla besökare samtidigt.

Därför kontrollerar Web RBL före varje spärr om adressbestämningen är tillförlitlig. Den kräver proxy_mode tillsammans med en vidarebefordringsrubrik, vägrar arbeta om en vidarebefordran kommer utan proxy_mode och vägrar likaså vid mer än en mellanliggande proxy. Vid tvekan blockeras inte.

2. Aldrig egna nätverk

Privata adressintervall, loopback, link-local och CGNAT är fast undantagna. De kan under inga omständigheter hamna på listan, not ens för hand. Detsamma gäller främmande listor: Privata och reserverade intervall samt absurt stora nät förkastas vid inläsningen.

3. Ett eget fel får inte dra med sig webbplatsen

Hela kontrollen körs i ett skyddsskikt som fångar upp varje fel. Vad som går snett här loggas, och förfrågan fortsätter oförändrad. En skyddsmodul som vid ett eget fel drar med sig webbplatsen är värre än ingen alls. Alla frågor i förfrågningsvägen körs dessutom utan besökarens webbläsarspråk och utan sortering efter översatta fält — en besökare med ett språk som inte är installerat får inte låta kontrollen misslyckas.

4. Observera före blockering

Efter installationen är blockering av listade adresser vid vanliga förfrågningar avstängd. Sonder avvisas och bokförs, allt annat släpps igenom. På så sätt kan man under några dagar se vilka som faktiskt hamnar på listan innan någon stängs ute. Detsamma gäller beteendeigenkänning, hotlistor och landsregler: rapportera först, blockera efter granskning.

5. Snäva mönster i stället för breda nät

En felaktigt identifierad besökare är dyrare än en förbisedd sond. Varje mönster har därför sin nivå, och den kan ställas om per mönster. En filändelse räcker sällan ensam: För .php står 14 012 äkta sonder mot en handfull gamla länkar, för .asp är förhållandet det omvända. Sådana beslut ska mätas, inte uppskattas.

6. En frigivning för hand består

Den som frigör en adress hade ett skäl. En ytterligare träff sätter inte detta beslut ur spel i det tysta.

7. Listan är skyddad, men ingen hemlighet

Slutpunkten kräver en token och svarar utan giltig token med 404, inte med 403 — adressens existens bekräftas alltså inte ens. Jämförelsen sker i konstant tid. Själva listan innehåller inget konfidentiellt: Den består av adresser som av egen drift har knackat på hos oss.

8. Inga hemligheter i bokföringen

Vid misslyckade inloggningar noteras det försökta användarnamnet, aldrig lösenordet. Vid databashanteraren läses ingenting alls ur de överlämnade värdena: Där står huvudlösenordet allra först, och en post i en spärrlista hamnar i varje databassäkerhetskopia. Licensnyckeln för GeoLite2 står endast i systemparametern och i ingen loggrad.

9. Lockbetet avslöjar inget användbart

Valfritt besvarar Web RBL sonder med påhittat innehåll som innehåller ett entydigt kanarievärde. Den som senare hämtar detta värde har läst det förfalskade svaret och därefter agerat — ett falsklarm är därmed uteslutet. Lockbetena innehåller inga användbara uppgifter, inga riktiga sökvägar och inga giltiga inloggningsuppgifter. Funktionen levereras avstängd, eftersom den ändrar beteendet på ett sätt som syns utåt.

Vad modulen inte kan

Den ersätter varken en brandvägg eller en Web Application Firewall. Den upptäcker kända sonderingsmönster i sökvägar, misslyckade inloggningar och påfallande beteende — inte angrepp mot formulär, inte injektionsförsök i parametrar.

Den ser dessutom bara det som kommer tillbaka via HTTP. Vad en angripare gör med stulna databas- eller postlådeåtkomster förblir osynligt — och just därför är kanarievärdena sökvägar och inte inloggningsuppgifter.

Och den ersätter inte omsorgsfullhet: En modul som avvisar .env-sonder gör en av misstag utlämnad .env-fil inte ofarlig.

Tillgänglighet

Web RBL är offentligt tillgänglig under AGPL-3 och körs hos oss i produktion på fem webbplatser:

github.com/Alex0176/odoo-web-rbl

Modulen förutsätter Odoo 19 Community och har inga beroenden utöver base och web. Ärendekopplingen är valfri och kräver inget särskilt ärendesystem; utan ett sådant händer helt enkelt ingenting. Ursprungslandet kräver den kostnadsfria GeoLite2-databasen från MaxMind; saknas den förblir fältet tomt och allt annat fungerar oförändrat.

Läs vidare: Hur Web RBL passar in i en fullständig säkerhetsarkitektur -- tillsammans med brandvägg, tvåfaktorsautentisering och behörigheter, inklusive steg-för-steg-anvisning: Kombinera Odoo 19:s säkerhetsarkitektur på rätt sätt.

Frågor, kommentarer och felrapporter tar vi gärna emot — helst som issue på GitHub.