Tallene som burde gi deg søvnproblemer

La meg starte med et tall som krever oppmerksomhet: Av 2 931 eksponerte MySQL-databaser som nylig ble skannet, hadde 2 930 allerede blitt merket av ransomware-operatører. Dette er ikke en spådom. Det er ikke et "dette kan skje." Det er bekreftet målstatus.

Prosentdelen? 99,96 prosent.

Hvis du har operert med antakelsen om at eksponerte databaser kanskje går ubemerket hen – at de sitter stille til noen snubler over dem – så knuser denne dataen den illusjonen. Trusselaktørene venter ikke. De ser på.

Den seks år gamle metoden som fremdeles fungerer

Her er det urovekkende: Metodene som brukes er ikke noe sofistikert zero-day angrep. Det er i bunn og grunn den samme tilnærmingen som har sirkulert siden rundt 2019-2020.

Vi snalker om:

• Automatiserte skanninger etter eksponerte databaseporter (3306, i MySQLs tilfelle)
• Credential stuffing med standard eller svake passord
• Databaseopptelling for å identifisere høyverdige mål
• Stille datauthenting før kryptering
• Ransomware-installasjon med stadig kortere tidslinjer

Verktøyene er blitt modne. Automatiseringen har blitt bedre. Men kjerneproblemet? Feilkonfigurering. Eksponerte porter. Glemte testmiljøer som fremdeles er koblet til offentlig internett.

Dette er ikke et speilbilde av sofistikerte nasjonale aktører. Dette er opportunistisk skanning i industriell skala, utført av grupper som har gjort databasekompromittering til en effektiv forretningsmodell.

Hvorfor eksponerte databaser er lavthengende frukt

Du lurer kanskje på: Hvis dette er så godt kjent, hvorfor forblir databaser eksponert?

Svaret er overraskende enkelt:

1. Utviklerens bekvemmelighet – Lokal utvikling innebærer ofte åpne porter for enkel tilgang. Å sende til produksjon skjer noen ganger med disse innstillingene intakte.

2. Sky-feilkonfigureringer – Offentlige skyinstanser starter ofte med sikkerhetsgrupper i tillatende tilstander "bare for å teste."

3. Glemte testmiljøer – Den staging-serveren fra 2022? Fremdeles i drift. Fremdeles eksponert.

4. Mangel på oversikt – Teamene vet rett og slett ikke hva som er internett-utsett.

5. Antakelsen om anonymitet – "Hvem ville angripe oss?" Svaret: Automatiserte boter som ikke diskriminerer.

Hva dette betyr for din infrastruktur

Hvis du kjører noen MySQL-databaser – enten det er for applikasjonen din, analysene dine eller kundedataene dine – må du behandle eksponerte instanser som kompromittert, selv om du ikke har sett bevis på inntrenging.

Angrepfren metodikk forutsetter:

• Databaser er dårlig overvåket
• Sikkerhetskopier kan befinne seg på samme kompromitterte system
• Organisasjoner vil få panikk og betale heller enn å gjenopprette fra verifiserte sikkerhetskopier
• Oppdagelses- og responstidene er treg nok til at kryptering lønner seg

De tar ikke feil, i mange tilfeller.

Umiddelbare tiltak å sette i verk

Kartlegg eksponeringen din:

• Bruk verktøy som Shodan, Censys eller BinaryEdge for å sjekke om IP-ene dine dukker opp i internett-skannende databaser
• Gjennomgå sikkerhetsgruppene og nettverks-ACL-ene hos skyleverandøren din
• Sørg for at ingen databaseport er tilgjengelig fra 0.0.0.0/0

Forsterk autentiseringen:

• Håndhev sterke, unike passord for alle databasekontoer
• Implementer IP-tillatelseslister der det er mulig
• Vurder tilkoblingstunnelering gjennom VPN eller bastion-verter i stedet for direkte eksponering

Verifiser sikkerhetskopiestrategien din:

• Lagres sikkerhetskopiene offline eller i en separat sikkerhetssone?
• Når var siste vellykkede gjenopprettingstest?
• Har du point-in-time recovery-mulighet?

Aktiver logging og overvåking:

• Database-revisjonslogger bør fange opp tilkoblingsforsøk, spørringer og administrative handlinger
• Sett opp varsler for uvanlige tilgangsmonstre eller bulk dataeksport
• Vurder databaseaktivitetsmonitoreringsløsninger (DAM)

Det større bildet: Sikkerhet som infrastruktur

Dette er ikke bare et databaseproblem. Det er en påminnelse om at sikkerhet må behandles som grunnleggende infrastruktur, ikke som en ettertanke.

Hos NameOcean ser vi dette mønsteret om igjen og om igjen – startups og utviklere som beveger seg raskt, leverer funksjoner, og ved et uhell eksponerer infrastruktur. Presset for å iterere raskt er reelt, men kostnaden ved et ransomwarehendelse eller datalekkasje er langt høyere enn ingeniørtimene som trengs for å sikre ting skikkelig fra starten av.

Domeneregistraren din, hosting-leverandøren din, DNS-konfigurasjonen din – dette er alle inngangsporter som fortjener samme gransking du (forhåpentligvis) anvender på database-laget ditt.

Konklusjon: Anta at du blir observert

De 2 930 flaggede databasene er ikke anomalier. De er representative for en bredere virkelighet: hvis databasen din er eksponert mot internett, er den allerede på noens radar.

Metodikken er seks år gammel fordi den fungerer. La ikke fortrolighet med disse angrepsmetodene lure deg inn i selvtilfredshet. La det heller motivere til handling.

Kartlegg eksponeringen din. Lås ned tilgangen. Verifiser sikkerhetskopiene dine. Og husk: i dagens trussellandskap er usynlighet ingen sikkerhetsstrategi.

Hold deg trygg der ute.

Har du spørsmål om sikring av databaseinfrastrukturen eller hosting-miljøet ditt? Legg dem gjerne i kommentarene – vi er her for å hjelpe deg med å bygge sikkert fra grunnen av.