Odoo 19 Community: Web RBL – estolista hyökkäysliikenteelle omilla verkkosivuilla

Lähdekoodi: github.com/Alex0176/odoo-web-rbl — AGPL-3, vapaasti käytettävissä.

Se, joka ylläpitää Odoo-palvelinta internetissä, saa vieraita. Ei satunnaisesti vaan taukoamatta. Seitsemäntoista päivän aikana olemme kirjanneet viidellä verkkosivustollamme ylös ja analysoineet 731 297 pyyntöä. 110 511 niistä ei ollut kävijöitä, vaan automatisoitua haavoittuvuuksien, tunnistetietojen ja konfiguraatiotiedostojen etsintää.

Tämä artikkeli kuvaa Web RBL:n, avoimen lähdekoodin moduulin Odoo 19 Communitylle, joka tunnistaa tämän liikenteen, arvioi sen, kirjaa sen ja torjuu sen — ja joka julkaisee estolistan RBL-listana, eli muodossa, jonka palomuurit ja käänteiset välityspalvelimet (Reverse Proxy) lukevat suoraan. Kaikki luvut ovat peräisin tuotantokäytöstä.

Mitä moduuli osaa — toiminnot yhdellä silmäyksellä

Toiminto	Mitä se tekee	Toimitus
Mallintunnistus	Tunnistaa luotaukset polusta ja päätteestä: .env, .git, konfiguraatiotiedostot, pilviavaimet, CI/CD-rakennusohjeet, WordPress, PHP, polun läpikäynti (Path Traversal), tietokannan hallintatyökalut, GraphQL, komentojen suoritus polun /api/fs/exec ja vastaavien rajapintojen kautta	estä
Kolme tasoa mallia kohden	estä, laske tai ilmoita — muutettavissa mallikohtaisesti, ilman koodia	mallikohtainen
Kynnysarvot	Näin monta saman mallin osumaa ennen kuin estetään; kirjautumisille kymmenen	10 kirjautumisessa
Kirjautumisen torjunta	Epäonnistuneet kirjautumiset lomakkeen ja XML-RPC/JSON-RPC:n kautta, epäonnistuneet istuntotarkistukset, pääsyt tietokannan hallintatyökaluun — tietokannassa, ei keskusmuistissa	päällä
Bottitunnistus kirjautumisessa	Se, joka ohittaa odotusilmoituksen kymmenen epäonnistuneen yrityksen jälkeen ja jatkaa koputtamista, estetään välittömästi	estä
Käyttäytymisen tunnistus	Osoitteet, jotka tuottavat viidessä minuutissa kaksikymmentä virhesivua ja tuskin yhtään osumasivua — eli arvaavat lukemisen sijaan	ilmoita
Arvio 0–100	Kuinka varmaa on, että osoitteen takana on hyökkääjä? Mallin vakavuudesta, eri mallien määrästä, poikkeavista päivistä, kohteena olevista toimialueista ja osumien määrästä — perusteluineen selkokielellä	päällä
Kirjautumisen esto arvion perusteella	Säädettävästä arviosta alkaen kirjautuminen on kielletty, verkkosivusto pysyy luettavana	40:stä alkaen
Epäilys varastetuista tunnistetiedoista	Onnistunut kirjautuminen epäilyttävästä osoitteesta ilmoitetaan ja halutessa osoitetaan tehtäväksi — kerran osoitetta ja päivää kohden	päällä
Uhkaluettelot	Tor-poistumissolmut, Spamhaus DROP, FireHOL Level 1 ja blocklist.de on esimääritetty; mikä tahansa muu RBL-luettelo voidaan lisätä osoitteella, päivittäinen vertailu, kullekin luettelolle oma taso	ilmoita
Ei pääsyä kirjautumiseen	Neljäs taso luetteloille ja maille: verkkosivusto on luettavissa, kirjautumislomake ja rajapinnat ovat kiinni — oikea vastaus Tor-verkolle	Valinnainen
Alkuperämaa	Maa jokaiselle osumalle ja osoitteelle GeoLite2:n avulla; moduuli päivittää tietokannan itse maksuttoman lisenssiavaimen avulla	näytä
Maasäännöt	Estä, ei pääsyä kirjautumiseen, ilmoita tai nimenomaisesti salli — maakohtaisesti, tarkoituksella ilman oletusarvoa	ei mitään
Virhemääritykset	QNAP, Synology, Exchange Autodiscover, ActiveSync ja WebDAV/CalDAV/CardDAV tunnistetaan, ei koskaan estetä, ja ne viedään työlistalle havaintoineen ja kyseisine verkkotunnuksineen	ilmoita
Tiketti osoitetta kohden	Havainnosta tehdään halutessa tiketti — täsmälleen yksi osoitetta kohden, suljettu tiketti avataan uudelleen sen sijaan, että syntyisi kaksoiskappale	pois
Pakolliset sivut ja keräilijät	Kanoninen yhteystietosivun (Impressum) polku pysyy aina tavoitettavissa; vieraiden kirjoitusasujen koneellinen kokeilu tunnistetaan ja halutessa estetään	ilmoita
Sallittujen luettelo	Osoitteet ja verkot, joita ei koskaan estetä; täyttyy päivittäin palomuurista (VPN-vastapäät) sekä Googlebotin ja Bingbotin julkaisemista osoitealueista	päällä
Asiakkaan yhdistäminen	Asiakkaan verkosta tullut osuma yhdistetään asiakkaaseen — sallittujen luettelon perusteella, ei koskaan käsin arvaten	päällä
Verkkotunnus ja tunniste osumaa kohden	Mihin verkkosivustoon pyyntö kohdistui ja millä User-Agentilla — kumpaakaan ei löydy käyttölokista	päällä
Analyysi	Kaavio ja pivot-taulukko kaikista osumista: kuvion, päivän, verkkotunnuksen, maan ja osoitteen mukaan	päällä
Houkute	Luotaimet saavat keksittyjä vastauksia, joissa on kanariaarvo; kuka sen myöhemmin hakee, on lukenut ne	pois
RBL-jakelu	Estoluettelo pelkkänä osoiteluettelona tai JSON-muodossa omassa, tokenilla suojatussa osoitteessa — HAProxylle, OPNsenselle ja jokaiselle palomuurille, joka lukee URL-luetteloita	päällä

Kaikki, mikä toimitetaan tilassa ilmoita, pois tai valinnainen, on tarkoituksella niin: sen, joka ottaa eston käyttöön, tulee tehdä se siksi, että on seurannut tilannetta muutaman päivän ja nähnyt, kuka siihen jää — ei siksi, että oletusasetus sen määräsi.

Analyysi: osumat kuvion mukaan seitsemän päivän ajalta. Korkein palkki on .env-tiedostojen etsintä.

RBL-luettelot: standardoitu tapa jakaa estoja

RBL tulee sanoista Real-time Blackhole List. Käsite on peräisin sähköpostimaailmasta, jossa Spamhaus ja muut ovat julkaisseet 1990-luvulta lähtien luetteloita haitallisista lähettäjäosoitteista. Periaate on mahdollisimman yksinkertainen ja juuri siksi niin yleinen: yksi osoite riviä kohden, haettavissa HTTP:llä, ladataan säännöllisesti uudelleen. Ei muotoa, jota pitäisi ensin jäsentää, ei rajapintaa, johon tarvittaisiin jokin työkalu.

Käytännössä jokainen palomuuri ja jokainen käänteinen välityspalvelin (reverse proxy) osaa lukea tällaisen luettelon ja rakentaa siitä sääntöjä. Valmistajat nimeävät asian eri tavoin, mutta mekanismi on kaikkialla sama:

• OPNsense ja pfSense — URL Table Alias: osoiteluettelon lataus HTTP:llä, käyttö aliaksena palomuurisäännöissä, päivitys tunti- tai päiväväleillä
• HAProxy — ACL-tiedostot ja Maps: src -f sperrliste.txt http-request deny -säännössä, ladattavissa uudelleen ajonaikaisen rajapinnan kautta ilman uudelleenkäynnistystä
• nginx — geo-moduuli liitetyn osoitetiedoston kanssa tai deny-käskyt luodusta include-tiedostosta
• Fortinet FortiGate — External Block List eli Threat Feed: URL, josta palomuuri hakee IP-luettelon ja käyttää sitä käytännöissä
• Palo Alto Networks — External Dynamic List (EDL): sama periaate, omana objektityyppinään tietoturvakäytännöissä
• Check Point — Custom Intelligence Feeds ja IP Block Lists URL:n kautta
• Cisco Secure Firewall (Firepower) — Security Intelligence Feeds omilla luettelolähteillä
• Sophos Firewall — Third-Party Threat Feeds: URL:stä haettavat osoiteluettelot estosääntöjen lähteenä
• Juniper SRX — Dynamic Address Entries syötteistä
• MikroTik RouterOS — Address Lists, täytetään skriptillä ja fetch-komennolla URL:stä
• CrowdSec — omat luettelot lähteenä bouncereille jokaisessa tuetussa järjestelmässä

Juuri tässä muodossa Web RBL toimittaa estoluettelonsa. Palomuuri hylkää paketit ennen kuin ne saavuttavat verkkopalvelimen — ja niiden mukana jokaisen muun saman osoitteen yrityksen, esimerkiksi sähköpostipalvelimeen tai VPN-yhdyskäytävään.

Molempiin suuntiin, mutta oikeassa paikassa

Tie toimii myös toiseen suuntaan: Web RBL:ään voi lisätä minkä tahansa RBL-luettelon — yksi URL, yksi taso, valmis. Tor-poistumissolmut, Spamhaus DROP, FireHOL ja blocklist.de on esimääritetty, lisää tulee kolmella napsautuksella. Moduuli purkaa jokaisen luettelon osoitealueiksi ja tarkistaa jokaisen pyynnön niitä vasten muutamassa mikrosekunnissa.

Ja silti: järkevämpää on käyttää vieraita luetteloita palomuurissa sen edellä. Kolmesta syystä. Palomuuri näkee kaikki palvelut, ei vain HTTP:tä — Spamhaus-luettelon osoitteen tulee epäonnistua myös sähköpostipalvelimella ja VPN:ssä. Se hylkää pakettitasolla, ennen kuin yhteyttä edes muodostuu, ja säästää siten sovelluspalvelimen kuormalta. Ja se on paikka, jossa tällaisia luetteloita muutenkin ylläpidetään; toinen kopio sovelluksessa on toinen paikka, joka voi vanhentua.

Mihin luetteloita moduulissa sitten tarvitaan: siihen, mihin palomuuri ei pysty. Se ei tunne kirjautumislomaketta. Web RBL voi evätä Tor-luettelon osoitteelta pääsyn kirjautumiseen ja silti toimittaa verkkosivuston — se, joka haluaa lukea nimettömänä, saa tehdä niin; se, joka haluaa kokeilla salasanoja nimettömänä, ei. Ja se voi ilmoittaa luetellun osoitteen onnistuneen kirjautumisen epäilyttäväksi. Molemmat edellyttävät luetteloa siellä, missä kirjautuminen tapahtuu.

Arviointi vaistojen sijaan

Osoite, joka on kerran kysynyt polkua /wp-login.php, on eri asia kuin osoite, joka on kahtena päivänä käynyt viiden eri kuvion kautta kolmen verkkotunnuksen läpi. Web RBL laskee tämän arvosanaksi 0–100 — sen perusteella, minkä se on itse nähnyt, ilman ulkopuolista palvelua ja ilman ulkoisia kyselyitä.

Yksi merkintä: 99 osumaa, arvosana 84 ja perustelu selkokielellä — vakavin kuvio, viisi eri vakavaa kuviota, kaksi epäilyttävää päivää, yli kaksikymmentä osumaa.

Arvosana ratkaisee kaksi asiaa. Säädettävästä arvosta alkaen kirjautuminen on kielletty — verkkosivusto pysyy luettavana, mutta se, joka on jo etsinyt tunnuksia, ei saa mahdollisuutta kokeilla löytämiään. Ja osoitteen onnistunut kirjautuminen, jolla on arvosana, ilmoitetaan: silloin joku ei ole enää arvannut, vaan tiennyt. Joko oikeutettu käyttäjä oli liikkeellä tai tunnukset ovat joutuneet vääriin käsiin — moduuli ei ratkaise sitä, vaan antaa asian jollekulle, joka voi kysyä. Itse salasanaan ei kosketa missään vaiheessa.

Estoluettelo suodatettuna arvosanalla 40 alkaen: osumien määrä, epäilyttävät päivät, kohteena olleet verkkotunnukset ja kunkin osoitteen viimeisin polku.

Mitä Web RBL suojaa — suojausvaikutus yksityiskohtaisesti

1. Tunnukset pysyvät löytymättä

Suurin mitattu hyökkäysluokka ei etsi Odoon aukkoja, vaan unohtuneita salaisuuksia. Seitsemäntoista päivän aikana:

• 57 721 pyyntöä .env-tiedostoihin — niissä on tietokannan salasanoja, API-avaimia ja istuntosalaisuuksia
• 5 535 pyyntöä määritystiedostoihin
• 4 388 pyyntöä pilvipalvelun tunnuksiin: credentials.json, service-account.json, firebase-adminsdk.json, rclone.conf, .git-credentials
• 2 811 pyyntöä .git-hakemistoihin — sen löytävä lataa koko lähdekoodin historioineen itselleen
• 1 907 pyyntöä rakennusohjeisiin, kuten .github/workflows/deploy.yml tai .gitlab-ci.yml, joissa mainitaan rekisterit ja avainten nimet

Ratkaisevaa ei ole pyyntöjen määrä, vaan eri osoitteiden määrä: /credentials.json tuli 98 osoitteesta, /.git-credentials 92:sta. Kyse ei ole yksittäisestä skannerista, vaan vakioohjelmistosta, joka pyörii maailmanlaajuisesti samanaikaisesti.

2. Kirjautumisyritykset menevät hukkaan — pysyvästi

Odoossa on oma jarrunsa salasanojen kokeilua vastaan. Sillä on kolme rajaa, jotka on dokumentoitu itse Odoon lähdekoodiin: laskuri sijaitsee työprosessin keskusmuistissa ja nollautuu jokaisessa uudelleenkäynnistyksessä, se vain viivästää eikä estä, ja se laskee vain yritykset, jotka pääsevät salasanan tarkistukseen asti.

Web RBL tarttuu samoihin kohtiin, mutta kirjoittaa tietokantaan. Näin ollen pätee:

• Tila säilyy jokaisen uudelleenkäynnistyksen yli ja on voimassa kaikissa työprosesseissa
• Huomioon otetaan molemmat reitit: kirjautumislomake /web/login ja rajapinnat /xmlrpc/2/common ja /jsonrpc
• Huomioon otetaan myös yritykset, jotka eivät koskaan pääse salasanan tarkistukseen asti — esimerkiksi kirjautumiset ilman kelvollista istuntotunnistetta
• Epäonnistunut pääsy tietokannan hallintaan lasketaan mukaan; se on kaikkein vakavin kirjautumisyritys

Kirjautumisten kynnys on kymmenen, ja syynä on mittaus: yhdeksästä epäonnistuneesta kirjautumisesta seitsemäntoista päivän aikana suurin osa tuli asiakkailta, jotka olivat itse ottamassa käyttöön pääsyä toisella laitteella ja kirjoittivat väärän verkkotunnuksen — yhdessä tapauksessa oman verkkotunnuksensa, mutta pisteen sijasta yhdysviivalla. Esto ensimmäisestä epäonnistuneesta yrityksestä ei olisi osunut hyökkääjiin, vaan asiakkaisiin käyttöönoton aikana.

Se, joka sen sijaan jatkaa koputtamista, vaikka palvelin on jo vastannut ”odota hetki”, estetään heti. Tämän viestin lukee ihminen ja odottaa; ohjelma ohittaa sen. Oma kuvio, jonka kynnys on nolla, nappaa juuri tämän tapauksen, eikä se voi osua kollegaan: sinne päätyy vain se, jolla on jo kymmenen epäonnistunutta yritystä takanaan ja joka sen jälkeen jatkaa.

3. Hyökkäys ei maksa palvelimelle enää mitään

Luotain polkuun kuten /@fs/../../.env oli ennen moduulia kallis: Odoo etsii virhesivun, renderöi sen, kompastuu osoitteen rakentamisessa piste-segmentteihin ja epäonnistuu siten myös virhesivun virhesivun kohdalla. Kaksi pinojälkilokia luotainta kohden. Seitsemäntoista päivän aikana mitattiin 28 401 tällaista virhettä, lisäksi 9 467 seuraamusvirhettä.

Web RBL puuttuu kohtaan ir.http._match, siis ennen reitin etsintää. Vastaus annetaan ilman mallipohjaa, ilman tietokantayhteyttä estotarkistusta pidemmälle ja ilman lokiriviä. Tarkistus sallittujen luetteloa, uhkaluetteloita ja maasääntöjä vasten tehdään välimuistista lajiteltujen osoitealueiden avulla — muutama mikrosekunti, vielä yli kolmenkymmenentuhannen alueen kohdalla.

4. Palomuuri heittää hyökkääjän ulos ennen kuin tämä ehtii perille

Estoluettelo julkaistaan RBL-luettelona, jonka HAProxy ja OPNsense lukevat suoraan. Hyökkääjä ei siten enää tavoita verkkopalvelinta — eikä mitään muutakaan palvelua samalla isännällä. Kerran haitalliseksi tunnistettu pääsyyritys suojaa näin taannehtivasti koko koneen.

Kolme tasoa: estä, laske, ilmoita

Kaikki tyhjään osuvat pyynnöt eivät ole hyökkäyksiä. Web RBL erottaa siksi kolme tasoa, ja tason voi vaihtaa kuviokohtaisesti koskematta koodiin.

Taso	Laukaisseen pyynnön kohtalo	Seuraus osoitteelle
estä	hylätään	estetty 24 tunniksi, kolmen epäilyttävän päivän jälkeen pysyvästi
laske	päästetään läpi	vain kirjataan, ei estoa
ilmoita	päästetään läpi	kirjataan havaintotekstin kanssa, ei koskaan estetä

Uhkaluetteloille ja maille on olemassa neljäs: ei pääsyä kirjautumiseen. Verkkosivusto pysyy luettavana, kirjautumislomake ja rajapinnat ovat kiinni. Se on keskitie kaikelle, mikä on epäilyttävää mutta ei välttämättä haitallista — Tor, jokin datakeskusalue, maa, jossa ei ole asiakkaita.

Mitkä hyökkäykset tunnistetaan

Kaikki kuviot on testattu todellista liikennettä vasten. Eri osoitteiden määrä on tarkoituksella rinnalla — se osoittaa, osuuko kuvio yksittäiseen skanneriin vai yleiseen toimintatapaan.

Hyökkäysluokka	Pyynnöt	Osoitteet
.env-poiminta	57.721	223
PHP-luotaimet	12.237	256
Polkujen läpikäynti (path traversal) kannattavalla kohteella	10.046	64
Määritystiedostot	5.535	114
Pilvipalvelun käyttöavaimet	4.388	152
WordPress-luotaimet	3.366	385
.git-poiminta	2.811	255
Odoon tiedustelu (tietokannan hallinta, versiokysely)	2.500	213
Tekoälytyökaluketjut ja komentojen suoritus (/mcp, /api/fs/exec)	2.450	74
Rakennusohjeet (CI/CD)	1.907	88
GraphQL-päätepisteet	1.878	71

Huomionarvoinen on uusin luokka. /api/fs/exec pyydettiin 369 kertaa 54 eri osoitteesta — se ei ole lukuyritys, vaan yritys suorittaa komentoja. Tällaisia kohteita ei ollut kaksi vuotta sitten; ne ovat peräisin uusien tekoälytyökalujen rajapinnoista ja tehtäväjonoista. Se, joka kohdistaa puolustuksensa vain WordPressiin ja PHP:hen, ei näe niistä mitään. Arvosanassa tämä luokka painaa vastaavasti paljon.

Uhkaluettelot ja alkuperämaa

Neljä luetteloa, 32 851 osoitealuetta, kaikki tilassa ”vain ilmoita”. Jokainen lisäluettelo on yksi osoite ja yksi taso.

Vieras luettelo on väite, jonka joku toinen esittää syistä, joita emme tunne, liikenteestä, jota emme ole koskaan nähneet. Se voi olla väärä, vanhentunut tai tarkoitettu toiseen käyttöön: blocklist.de kerää lähinnä osoitteita, jotka ovat muualla kokeilleet SSH-kirjautumisia, ja se kertoo verkkopalvelimesta vähän. Siksi Web RBL pitää vieraat luettelot erillään omasta estoluettelostaan, ja siksi oletusarvo on ilmoita. Ja oma sallittujen luettelo voittaa aina: tuntemamme asiakas painaa enemmän kuin kolmannen osapuolen arvio.

Alkuperämaa näkyy jokaisessa osumassa ja jokaisessa osoitteessa. Arvioinnissa se on korvaamaton — kirjautumisyritys omasta maasta kello kymmenen aamupäivällä on eri asia kuin yritys maasta, jossa ei ole yhtään asiakasta. Yleiseen ulosulkemiseen se ei sovellu juuri lainkaan, ja sen kertovat omat lukumme: luettelomme hyökkääjät tulivat pääosin pilvialueilta Belgiassa, Suomessa ja Alankomaissa. Esto kaikelle saksankielisen alueen ulkopuolelta ei olisi osunut heihin — mutta olisi osunut omiin työntekijöihin lomalla ja asiakkaisiin työmatkalla.

Maasäännöt toimitetaan tyhjinä, ja näkymä kertoo, miksi.

Virhemääritykset ilmoitetaan eikä estetä

Yleisin tapaus todellisessa liikenteessä ei ole hyökkäys eikä kävijä, vaan viallinen ohjelmisto, joka pitää verkkopalvelinta jonakin toisena:

• 1 367 kutsua QNAP-NAS-laitteen verkkorajapintaan — synkronointiasiakas, jonka kohde ei enää täsmää. Yksi ainoa liittymä koputti 962 kertaa.
• 65 Autodiscover-kyselyä — Outlook, joka pitää verkkotunnusta Exchange-palvelimenaan

Tällaisia osoitteita ei koskaan estetä. Esto ei korjaa vikaa, vaan piilottaa sen — ja osuu siihen, jonka laite on jo valmiiksi väärin asetettu. Sen sijaan syntyy merkintä havaintotekstin ja kohteena olleiden verkkotunnusten kanssa, josta halutessa tulee automaattisesti tiketti: osoitetta kohden täsmälleen yksi, ja jos se suljetaan ja osoite tulee uudelleen esiin, sama tiketti avautuu uudelleen sen sijaan, että syntyisi toinen.

Tunnistettavia ovat QNAP, Synology, Exchange Autodiscover, ActiveSync sekä WebDAV-, CalDAV- ja CardDAV-asiakkaat. Kuviot nimeävät tarkat tiedostonimet ja hakemistot, eivät koskaan pelkkiä päätteitä: Samassa /cgi-bin/-hakemistossa vaarattomat synkronointikutsut ovat aivan perinteisten luotainten, kuten printenv.pl, vieressä.

Sallittujen luettelo: osoitteet, joita ei koskaan estetä

Erehdyksen hinta ei ole kaikille osoitteille sama. Datakeskuksesta tulevan skannerin kohdalla väärä hälytys ei maksa mitään. Toimipisteen tunnelin vastapään kohdalla se maksaa koko toimipisteen.

Siksi on olemassa toinen luettelo, joka on ensimmäisen edellä: osoitteet ja verkot, joita ei koskaan estetä. Se ei mykistä mitään — se, joka on luettelossa, tarkistetaan ja kirjataan edelleen, vain seuraus jää pois. Tämä on ero palomuurin poikkeuksesta: se tekee sokeaksi, tämä vain kärsivälliseksi.

Se täytetään päivittäin kahdesta lähteestä: itse palomuurista kaikkine VPN-vastapäineen, jotta uuden tunnelin toimivuus ei ole kiinni siitä, että joku muistaa estoluettelon — ja Googlen ja Microsoftin julkaisemista osoitealueista niiden indeksointirobooteille. Vain siten oikean Googlebotin voi erottaa skannerista, joka esiintyy sellaisena. Hakukoneita ei saa koskaan estää; se, joka sulkee ne ulos, poistaa sivustonsa indeksoinnista ilman paluutietä.

Tässä pätee sääntö, joka on vertailua tärkeämpi: Tyhjä vastaus ei koskaan poista mitään. Jos lähde ei vastaa, vastaa tyhjää tai käsittämätöntä, luettelo pysyy ennallaan. Sallittujen luettelo, joka tyhjenee itsestään häiriön sattuessa, vie pahimpana mahdollisena hetkenä kaikki tunnelit mukanaan.

Jos sallittujen luettelon merkinnällä on asiakas, jokainen hänen verkostaan tuleva osuma yhdistetään hänelle. Virhemäärityksellä on siten heti yhteyshenkilö, eikä kenenkään tarvitse hakea osoitteita ylös.

Pakolliset tiedot ja automatisoidut tiedonkerääjät

Yhteystietosivu (Impressum) ei ole tavallinen sivu. Sen täytyy pysyä ihmisten tavoitettavissa, sillä sen esto luo juuri sen rikkomuksen, jota keräilijä etsii. Samalla se on sivu, jolla nimi ja osoite ovat — ja siten koneellisen sadonkorjuun kohde.

Itävallassa upotettujen Google-fonttien vuoksi liikkeelle lähteneen vaatimuskirjeiden aallon yhteydessä lokit osoittivat, etteivät kirjeet johtuneet yksittäisistä käynneistä, vaan automatisoidusta laajasta ryntäyksestä: eri, toisiinsa liittymättömiä isäntiä millisekuntien välein.

Web RBL ratkaisee tämän alentamalla tasoa poikkeuksen sijaan. Kanoninen polku /impressum ei osu mihinkään kuvioon ja pysyy aina tavoitettavissa. Vieraat kirjoitusasut, kuten /impressum.php — joita Odoo-sivustolla ei voi olla — ilmoitetaan, ja se, joka ei halua hyväksyä koneellista sadonkorjuuta, vaihtaa yhtä parametria. sitemap ja robots on rajattu tämän ulkopuolelle ja niitä ei periaatteessa voi estää: ne eivät sisällä henkilötietoja, ja niiden hakeminen on jokaisen hakukoneen indeksointirobotin tehtävä.

Verkkotunnus ja tunniste: mikä käyttölokista puuttuu

Werkzeugin käyttöloki ei kirjaa ylös kutsuttua isäntää eikä kutsujan tunnistetta. Odoo saa molemmat tietysti — ilman isäntää se ei voisi valita useasta verkkosivustosta oikeaa. Jälkikäteen niitä ei kuitenkaan voi enää lukea.

Web RBL tallentaa molemmat jokaisesta osumasta. Se vastaa kahteen kysymykseen, joihin ei muuten saa vastausta: mihin verkkosivustoon virhemääritys kohdistuu — ja siten kenelle asiakkaalle verkkotunnus kuuluu — ja käykö osoite yhdellä sivulla vai kaikilla. Saman osoitteen useat toisiinsa liittymättömät verkkotunnukset ovat laajan ryntäyksen tunnusmerkki, ja ne nostavat arvosanaa.

Kuinka paljon tunniste merkitsee, osoitti yhden verkkosivustomme analyysi: yli seitsemänkymmentä prosenttia koko liikenteestä tuli siellä yhdeltä ainoalta kutsujalta, jakautuneena yli sadalle osoitteelle. Ilman tunnistetta se olisi näyttänyt hajautetulta skraperilta. Kyseessä oli GPTBot, OpenAI:n indeksointirobotti — se kysyi yhä uudelleen tiedostoa robots.txt ja käyttäytyi täysin oikein.

Tietoturvanäkökohdat yksityiskohtaisesti

1. Välityspalvelimen tunnistus — kaikkein vaarallisin kohta

Jos Odoo toimii käänteisen välityspalvelimen takana ja proxy_mode on asetettu väärin, moduuli näkee jokaisessa pyynnössä saman osoitteen: välityspalvelimen osoitteen. Esto sulkisi silloin kaikki kävijät ulos samanaikaisesti.

Siksi Web RBL tarkistaa ennen jokaista estoa, onko osoitteen määritys luotettava. Se edellyttää proxy_mode-asetusta yhdessä edelleenlähetysotsakkeen kanssa, kieltäytyy toimimasta, jos edelleenlähetys tulee ilman proxy_mode-asetusta, ja kieltäytyy yhtä lailla, jos välityspalvelimia on useampi kuin yksi. Epäselvässä tapauksessa ei estetä.

2. Omia verkkoja ei koskaan

Yksityiset osoitealueet, loopback, link-local ja CGNAT on suljettu pysyvästi pois. Ne eivät voi missään olosuhteissa päätyä luetteloon, ei edes käsin. Sama pätee vieraisiin luetteloihin: yksityiset ja varatut alueet sekä järjettömän suuret verkot hylätään luettaessa.

3. Oma virhe ei saa viedä verkkosivustoa mukanaan

Koko tarkistus suoritetaan suojauksessa, joka nappaa jokaisen virheen. Se, mikä menee tässä pieleen, kirjataan lokiin, ja pyyntö jatkaa muuttumattomana. Suojausmoduuli, joka omassa virhetilanteessaan vie verkkosivuston mukanaan, on pahempi kuin ei mitään. Kaikki pyyntöpolun kyselyt suoritetaan lisäksi ilman kävijän selainkieltä ja ilman käännettyjen kenttien mukaista lajittelua — kävijä, jolla on asentamaton kieli, ei saa pystyä kaatamaan tarkistusta.

4. Seuranta ennen estoa

Asennuksen jälkeen luetteloitujen osoitteiden esto tavallisissa pyynnöissä on poistettu käytöstä. Luotaimet hylätään ja kirjataan, kaikki muu menee läpi. Näin voi seurata muutaman päivän, kuka todella päätyy luetteloon, ennen kuin ketään suljetaan ulos. Sama pätee käyttäytymisen tunnistukseen, uhkaluetteloihin ja maasääntöihin: ensin ilmoita, estä vasta harkinnan jälkeen.

5. Tarkat kuviot laajojen verkkojen sijaan

Väärin tunnistettu kävijä on kalliimpi kuin ohi mennyt luotain. Siksi jokaisella kuviolla on oma tasonsa, ja se on vaihdettavissa kuviokohtaisesti. Pelkkä tiedostopääte riittää harvoin: kun .php-päätteellä on 14 012 oikeaa luotainta ja kourallinen vanhoja linkkejä, .asp-päätteellä suhde on päinvastainen. Tällaiset päätökset kuuluvat mitattaviksi, ei arvattaviksi.

6. Käsin tehty vapautus pysyy voimassa

Se, joka vapauttaa osoitteen, on tehnyt sen syystä. Uusi osuma ei kumoa tätä päätöstä äänettömästi.

7. Luettelo on suojattu, mutta ei salaisuus

Päätepiste vaatii tokenin ja vastaa ilman kelvollista tokenia koodilla 404, ei 403 — osoitteen olemassaoloa ei siten vahvisteta lainkaan. Vertailu tapahtuu vakioajassa. Luettelo itsessään ei sisällä mitään luottamuksellista: se koostuu osoitteista, jotka ovat omasta aloitteestaan koputtaneet ovellemme.

8. Ei salaisuuksia kirjanpidossa

Epäonnistuneista kirjautumisista kirjataan yritetty käyttäjänimi, ei koskaan salasanaa. Tietokannan hallinnan kohdalla annetuista arvoista luetaan ei yhtään mitään: siellä ensimmäisenä on pääsalasana, ja estoluettelon merkintä päätyy jokaiseen tietokannan varmuuskopioon. GeoLite2:n lisenssiavain on vain järjestelmäparametrissa eikä missään lokirivillä.

9. Houkute ei paljasta mitään hyödynnettävää

Valinnaisesti Web RBL vastaa luotaimille keksityllä sisällöllä, joka sisältää yksiselitteisen kanariaarvon. Se, joka hakee tämän arvon myöhemmin, on lukenut väärennetyn vastauksen ja toiminut sen perusteella — väärä hälytys on tällöin poissuljettu. Houkutteet eivät sisällä hyödynnettäviä tietoja, eivät oikeita polkuja eivätkä kelvollisia tunnuksia. Tämä toiminto toimitetaan pois päältä, koska se muuttaa ulospäin näkyvää käyttäytymistä.

Mitä moduuli ei osaa

Se ei korvaa palomuuria eikä Web Application Firewallia. Se tunnistaa tunnetut tiedustelukuviot poluissa, epäonnistuneet kirjautumiset ja poikkeavan käyttäytymisen — ei hyökkäyksiä lomakkeisiin eikä parametreihin kohdistuvia injektioyrityksiä.

Se näkee lisäksi vain sen, mikä tulee takaisin HTTP:n kautta. Mitä hyökkääjä tekee anastetuilla tietokanta- tai postilaatikkotunnuksilla, jää näkymättömiin — ja juuri siksi kanariaarvot ovat polkuja eivätkä tunnuksia.

Eikä se korvaa huolellisuutta: moduuli, joka hylkää .env-luotaimet, ei tee vahingossa toimitetusta .env-tiedostosta vaaratonta.

Saatavuus

Web RBL on julkisesti saatavilla AGPL-3-lisenssillä ja toimii meillä tuotannossa viidellä verkkosivustolla:

github.com/Alex0176/odoo-web-rbl

Moduuli edellyttää Odoo 19 Communityä, eikä sillä ole riippuvuuksia lukuun ottamatta base- ja web-moduuleja. Tikettiyhteys on valinnainen eikä vaadi mitään tiettyä tikettijärjestelmää; ilman sitä ei yksinkertaisesti tapahdu mitään. Alkuperämaa tarvitsee MaxMindin maksuttoman GeoLite2-tietokannan; jos se puuttuu, kenttä jää tyhjäksi ja kaikki muu toimii muuttumattomana.

Lue lisää: Miten Web RBL sopii kokonaisvaltaiseen tietoturva-arkkitehtuuriin -- yhdessä palomuurin, kaksivaiheisen todennuksen ja käyttöoikeuksien kanssa, vaihe vaiheelta etenevine ohjeineen: Odoo 19 -tietoturva-arkkitehtuurin oikea yhdistäminen.

Otamme mielellämme vastaan kysymyksiä, huomautuksia ja virheraportteja — mieluiten GitHubin issueina.