Teamet mitt forvalter en nøkkelapplikasjon for Møller Mobility Group, som gir bileiere tilgang til viktig informasjon om kjøretøyene sine, muligheten til å administrere bilrelasjoner, bestille verkstedtjenester og skadetakst. Applikasjonen, kalt Bilhold, har daglig mellom 1200 og 1600 brukere som forventer pålitelig funksjonalitet. Dette er historien om hvordan 10% av disse brukerne plutselig ble utestengt fra applikasjonen.

Arkitekturen for app'en kan, veldig forenklet, illustreres slik:

Det er et .NET Core backend API som brukes av en Android app, en Ios app og en nettside. APIet kjører i AKS og vi bruker CloudFlare for eksponere tjenestene på internett.

Vi bruker logg-verktøyet DataDog som gir oss god oversikt over hva som skjer i applikasjonen. Med logging både i frontend og i backend så vi vet stort sett når noe går galt, men i frontend er ting litt mer kaotisk og det er ikke alltid like lett å se hva som faktisk har skjedd. I en lengre periode ble vi oppmerksom på logger som så slik ut:

Dette var forespørsler gjort mot backend fra frontend som feilet. Det merkelige var at de ble logget i frontend med statuskode 0, men det var ingen spor av dem i backend-loggene. Loggene innholdt heller ingen andre detaljer om hva som hadde gått galt. Vi ble etter hvert klar over at dette kan skje av mange ulike årsaker, og at det ikke nødvendigvis betyr at noe er feil:

• Forespørselen kunne blitt avbrutt av noe i frontend-koden. F.eks hvis brukeren ble videresendt til innlogging samtidig som andre forespørsler var pågående
• Forespørselen kunne blitt blokkert pga feil oppsett av CORS
• Brukeren kunne midlertidig mistet internett-tilgang eller ha ustabilt nett

I mange av tilfellene var det nok en av disse årsakene, men 20. oktober skjedde det noe. Plutselig fikk vi veldig mange flere slike forespørsler som feilet. Det kunne virke som at ca 10% av brukerne opplevde å bli blokkert og dermed ute av stand til å bruke applikasjonen.

Hva som forårsaket denne plutselige økningen var uklart, og ingen brukere hadde på dette tidspunktet rapportert om problemer til kundesupport. At ingen hadde tatt kontakt kunne ha sammenheng med at app'en rett og slett ikke fungerte for brukerne. Vi sendte ut e-post til noen av de som virket berørt, men uten at vi fikk noe svar.

Vi kunne ikke å finne feil noe sted, og for de fleste brukerne fungerte alt som det skulle. Alle vi kjente som brukte appen opplevde heller ingen problemer. Tilfeldigvis, da en interaksjonsdesigner i teamet skulle intervjue en bruker om deres opplevelse med appen, oppdaget vi noe. Appen fungerte ikke for brukeren, og intervjueren kunne ikke forstå hvorfor. Da vi undersøkte denne brukerens sesjon i loggene, fant vi noe interessant.

Loggen viste at denne brukeren hadde samme problem som vi hadde observert for de andre brukerne, altså at forespørsler ble avbrutt med statuskode 0. Det nye vi oppdaget var at enkelte forespørsler fungerte helt fint, mens andre ble blokkert. Tidligere hadde vi ikke lagt merke til at fellesnevneren for de som ble blokkert var at de alle var subdomener av `mollercloud.no` domenet.

Hva var spesielt med `mollercloud.no`? Egentlig ingenting, så vidt vi visste, men det måtte være noe og nå hadde vi en bruker som var villig til å hjelpe oss med å finne ut hva som var problemet. Etter å ha tatt en prat, så ble det klart at app'en fungerte helt fint på hjemmenettet til brukeren. Det var på jobb-nettet problemet oppsto. Brukeren jobbet i Lørenskog kommune, så vi kontaktet IT-avdelingen der for å se om de kunne hjelpe oss.

IT-avdelingen kunne bekrefte at alle forespørsler gjort mot vår backend som ligger på `*.mollercloud.no` ble av ukjent grunn blokkert av deres systemer. De visste ikke hvorfor, men vi fikk en skjermdump som viste at de hadde et sikkerhetssystem kalt `FortiGuard` som blokkerte url'en. Vi kom ikke noe lengre med dette sporet, men vi ble nysgjerrige på hvilke andre internettleverandører brukerne som ble blokkert brukte.

Det viste seg at de aller fleste som ble blokkert var Telenor-brukere. Var dette fordi Telenor er stor i Norge og at mange er koblet opp med Telenor? Eller kunne det skyldes en kombinasjon av at mange bruker Telenor og at Telenor har noe som blokkerer brukerne våre?

Tilfeldigvis, omtrent samtidig som vi oppdaget dette, tok en frustrert Telenor-kunde kontakt med vår kunde-support og klagde på at Bilhold-app'en ikke fungerte. Vi tok kontakt og han var heldigvis veldig ivrig etter å hjelpe oss med å finne feilen. Det viste seg at han er koblet opp med Telenor både på hjemmenettet og på mobilnettet, og at Bilhold ikke fungerte på noen av disse nettene. Over telefon får vi hjulpet han med å logge på hans Telenor-bruker og finner sikkerhetsinnstillingene for nettverket hans. En av sidene så slik ut:

Nettverket hans var beskyttet av et produkt kalt Nettvern+. Etter litt eksperimentering får vi bekreftet at det er Nettvern+ som gjør at brukeren blir blokkert. Med vanlig Nettvern eller nettvern avslått fungerer alt som normalt. Selv om dette var et stort steg i riktig retning for å finne ut hva som hadde skjedd så var fortsatt mye uklart. Det fantes tydeligvis flere sikkerhetsprodukter tilknyttet ulike nettleverandører som blokkerer trafikken til brukerne våre, men hvorfor? De måtte ha noe til felles.

Svartelisten
Den mest logiske forklaringen syntes å være at det måtte finnes informasjon tilgengelig et sted som alle disse sikkerhetsproduktene benyttet seg av. Kunne vi ha blitt svartelistet av noen? Det finnes mange nettjenester for å sjekke om en IP-adresse eller et domene er svartelistet, men disse listene brukes vanligvis til å blokkere utsending av søppelpost. Vi prøvde likevel en av disse tjenestene, et verktøy kalt MX Toolbox.

Og resultatet var veldig interessant:

Domenet vårt, `mollercloud.no` var svartelistet hos et sted kalt SpamHaus. De er kjent for å lage svartelister for å blokkere utsendere av e-post spam.

SpamHaus oppgir at de har lagt oss til i en såkalt Domain Blocklist, som de kaller `SpamHaus DBL`. Mollercloud.no er blitt listet som et «spam» domene, altså et domene som sender ut søppelpost. Bortsett fra dette oppgir ikke SpamHaus først noen detaljer om hvorfor vi er blokkert, men vi sender inn en forespørsel om å bli fjernet fra svartelisten.

Vi får etter hvert et ganske diffust svar fra SpamHaus om hvorfor vi er blitt svartelistet. Vi er tydeligvis i et "Internet Bad Neighborhood", uten noen detaljer om hva det skal bety. Det virker sannsynlig at SpamHaus på en eller annen måte er relatert til Telenor sitt Nettvern+ produkt og FortiGuard, men det virket rart at de skulle ha noe med hverandre å gjøre.

Svaret fant vi delvis på på SpamHaus sine egne nettsider. Det viste seg at SpamHaus selv har et produkt som blokkerer DNS-oppslag, en slags DNS brannmur, som benytter seg av svartelistene de selv eier. Ut fra dette gjettet vi på at Telenor hadde noe lignende, der SpamHaus var en av kildene. Vi tok kontakt med Telenor for å høre om det stemte og, etter en del fram og tilbake, fikk vi bekreftet at Nettvern+ integrerte med SpamHaus og brukte SpamHaus DBL listen til å blokkere domener.

SpamHaus svarer etter hvert og gir litt mer detaljer om hvorfor vi ble blokkert:

I følge SpamHaus er grunnen til at domenet har blitt svartelistet at domenet peker mot to IP-addresser som har dårlig rykte. Disse IP-addressene tilhører CloudFlare som vi bruker for å eksponere tjenestene våre på internett.

Etter litt research bestemmer vi oss for at beste løsning på problemet er å prøve å bytte IP-adresser. Vi hadde allerede en CloudFlare Enterprise konto som ga oss statiske IP'er, men den ga oss også muligheten til å få nye IP-addresser. Det var en liten prosess, men etter en uke fikk vi nye CloudFlare IPer. Deretter sendte vi inn en ny forespørsel til SpamHaus om å bli fjernet fra svartelisten. Det neste som skjedde var nesten litt magisk. SpamHaus fjernet oss fra listen umiddelbart, sannsynligvis fordi de automatisk kunne sjekke at domenet ikke lengre var knyttet til de gamle IP-addressene. Like etterpå oppdaget vi at trafikken til de fleste brukerne fungerte som normalt igjen. Det viste seg at Telenor automatisk hadde oppdaget endringen hos SpamHaus og hadde fjernet blokkeringen av domenet vårt.

Hvordan fikk disse IP-addressene dårlig rykte? Det fant vi dessverre aldri ut, men vi har noen teorier. En av dem gikk ut på at det kan ha skjedd en rotasjon av IP-adresser hos CloudFlare, slik at vi fikk nye IPer som tidligere hadde vært brukt av noen med uærlige hensikter. Det finnes flere tråder på nettet om at lignende har skjedd med andre, men vi fant ingen håndfaste bevis på at dette var tilfellet for oss. I tillegg skal CloudFlare Enterprise gi oss statiske IP-er som egentlig ikke skal endre seg, så denne teorien virket etter hvert mindre sannsynlig.

Den andre teorien var at noen faktisk hadde klart å sende ut spam fra vårt domene og at SpamHaus korrekt hadde oppdaget dette. Det ble gjort en nøye gjennomgang av alt oppsett av e-post, spesielt mtp e-postautentisering med SPF (Sender Policy Framework), men ingen store feil ble funnet. Det eneste var at e-post sendt fra mollercloud.no som feilet SPF-sjekken ble satt til `quarantine` i stedet for `reject`. Dette ble selvfølgelig endret, men burde ikke vært nok til å bli flagget som en utsender av spam. Hva som faktisk var årsaken får vi nok dessverre aldri vite, men lærdommen er at man bør beskytte domenene sine så godt som mulig mot misbruk for å unngå slike problemer. Ved hjelp av SPF kan man forhindre at noen sender spam fra ditt domene og med DMARC kan du overvåke mulig misbruk. I tillegg bør man sørge for å bare eksponere IP-adresser som ikke kan endre seg ut på internett, spesielt for verdifulle domener.