En eksponeret database ødelægger ikke dit website. Den virker upåklageligt, mens den står åben, der er ingen fejl at opdage og ingen kunde, der klager — og præcis derfor står de sådan i årevis og ikke i dage.

Næsten ingen af dem bliver åbnet med vilje. De bliver åbnet midlertidigt under en flytning, en fejlsøgning eller en førstegangsopsætning, og så bliver den midlertidige tilstand den permanente, fordi der aldrig er noget, der gør opmærksom på den.

Databaser: dem der betyder mest

Databaseporte bør kun kunne nås fra jeres applikationsservere over et privat netværk — aldrig fra det offentlige internet. De sædvanlige mistænkte er standardporten: PostgreSQL på 5432, MySQL og MariaDB på 3306, MongoDB på 27017, Redis på 6379, Elasticsearch på 9200, Microsoft SQL Server på 1433 og Memcached på 11211, som oven i købet er fremragende til at forstærke angreb mod andre.

To af dem fortjener særlig omtale, fordi deres historiske standardindstillinger var farlige. Redis og Elasticsearch blev begge designet til betroede interne netværk og blev i årevis leveret uden autentificering slået til. Begge har siden rettet det — Redis har haft beskyttet tilstand slået til som standard siden 3.2, og Elasticsearch slår autentificering til fra version 8 — men internettet er fuldt af ældre installationer, opgraderede opsætninger der har taget de gamle indstillinger med sig, og containere startet med beskyttelserne udtrykkeligt slået fra. En eksponeret instans af en af dem har ofte betydet fuld læseadgang til data, og i Redis' tilfælde af og til fjernudførelse af kode, uden at der skulle bruges adgangsoplysninger overhovedet.

Konsekvensen af eksponering her er ikke "en angriber finder måske en sårbarhed på et tidspunkt". Det er ofte direkte adgang til jeres kundedata, i dag, med intet andet end en klient.

Fjernadministration

De her giver en angriber en loginprompt, hvilket betyder, at de kan angribe den vedvarende og usynligt:

  • SSH (22) — som regel den ene port, der legitimt skal kunne nås. Det realistiske mål er at begrænse den: kun nøglebaseret autentificering, adgangskodelogin slået fra, og adgang begrænset til kendte adresser eller en VPN, hvor det kan lade sig gøre.
  • RDP (3389) — Windows fjernskrivebord og et af de mest konsekvent misbrugte indgangspunkter på internettet. Den bør stå bag en VPN. Ikke hærdet og eksponeret. Bag en VPN.
  • Admin-sider til databaser — phpMyAdmin, Adminer og lignende værktøjer over HTTP. Det er webapplikationer med deres egen sårbarhedshistorik, placeret direkte foran jeres data.
  • SMB (445) — Windows fildeling, og den vej flere af de største ransomware-udbrud tog. Der findes ingen opsætning, der gør det forsvarligt at eksponere; den hører til på et privat netværk eller bag en VPN.
  • VNC (5900) — fjernskrivebord med en svag autentificeringsmodel og en lang historik med at stå åbent helt uden adgangskode.
  • Container- og orkestrerings-API'er — en eksponeret Docker-dæmon på 2375 svarer til at dele root ud på værten, uden autentificering. Port 2376 er den TLS-beskyttede udgave og er kun så sikker som opsætningen af dens klientcertifikater. Et eksponeret Kubernetes-API på 6443 eller en kubelet på 10250 har historisk givet mulighed for at udføre kommandoer inde i kørende containere.

Gamle protokoller i klartekst

FTP på 21 og Telnet på 23 sender adgangsoplysninger i klartekst. Enhver, der sidder mellem klienten og serveren, læser adgangskoden. Står en af dem åben, er spørgsmålet ikke, hvordan man hærder den, men hvad der stadig bruger den, og hvor hurtigt den kan erstattes med SFTP eller SSH.

Filer, ikke kun porte

Den samme slags uheld producerer offentligt læsbare filer, og de er ofte hurtigere at udnytte end en åben port, fordi de slet ikke kræver protokolviden:

  • .env-filer, som typisk indeholder databaseadgangskoder, API-nøgler og betalingsnøgler i klartekst.
  • Databasedumps — backup.sql og lignende, efterladt i web-roden efter en flytning.
  • En eksponeret .git-mappe, som gør det muligt at rekonstruere hele jeres kildehistorik, inklusive enhver nøgle, der er blevet committet undervejs.
  • Rester fra editorer og backups — config.php.bak, config.php~ og lignende. De bliver som regel serveret som ren tekst frem for udført, hvilket betyder, at kildekoden og dens adgangsoplysninger kan læses i en browser.

Sådan tjekker du

Tjek udefra jeres eget netværk. Det er dét, folk gør forkert: et tjek kørt inde fra kontoret eller fra serveren selv afprøver en vej, der ikke er den, angribere bruger, og firewall-regler er ofte forskellige mellem dem. Brug en maskine på en helt anden forbindelse eller en scanningstjeneste, og scan den offentlige adresse, jeres domæne rent faktisk peger på.

Bemærk også, at det ikke er en engangsopgave. Firewall-regler bliver bygget om under flytninger, cloud-sikkerhedsgrupper bliver redigeret af folk, der ikke tænker på jeres database, og en midlertidig regel tilføjet under en hændelse er præcis den slags, der aldrig bliver fjernet igen. Et tjek fortæller dig om i dag; kun et gentaget tjek fortæller dig om næste kvartal.

Hvad man gør, når man finder noget

Luk først, undersøg bagefter. Begræns porten til de adresser, der har brug for den — et privat netværk, en sikkerhedsgruppe, en firewall-regel — og find først derefter ud af, hvor længe den har stået åben.

Gå derefter ud fra, at den er blevet fundet. Kunne en database nås, så behandl dens indhold som potentielt læst og dens adgangsoplysninger som kompromitteret. Udskift dem. Adgangslogs kan måske fortælle jer noget, men fravær af spor i en log, der måske slet ikke var slået til, er ikke bevis for, at der ikke skete noget.

Hvilke porte bør aldrig være eksponeret mod internettet?

Databaseporte frem for alt — PostgreSQL 5432, MySQL 3306, MongoDB 27017, Redis 6379, Elasticsearch 9200, SQL Server 1433 — som kun bør kunne nås fra jeres applikationsservere over et privat netværk. Dertil fjernadministration: SMB på 445 og RDP på 3389 hører bag en VPN, admin-sider som phpMyAdmin bør ikke være offentlige, og en eksponeret Docker-dæmon på 2375 svarer til at forære root væk. Gamle klartekstprotokoller som FTP og Telnet sender adgangsoplysninger i klartekst og bør erstattes.

Hvordan ved jeg, om min database er eksponeret?

Det opdager du ikke i den daglige drift, og det er kerneproblemet: en eksponeret database ødelægger ingenting, giver ingen fejl og udløser ingen kundeklage, så den står åben i årevis. Den eneste måde at vide det på er at tjekke udefra jeres eget netværk — en scanning kørt inde fra kontoret eller fra serveren selv afprøver en anden vej, og firewall-regler er ofte forskellige mellem dem.

Hvorfor er en eksponeret Redis eller Elasticsearch særlig alvorlig?

Fordi Redis og Elasticsearch begge blev designet til betroede interne netværk og i årevis blev leveret uden autentificering slået til. Begge har siden ændret deres standardindstillinger — Redis ved 3.2, Elasticsearch ved version 8 — men ældre installationer, opgraderede opsætninger og containere startet med beskyttelserne slået fra er stadig almindelige. En eksponeret instans har ofte betydet fuld læseadgang til data uden nogen adgangsoplysninger overhovedet, og i Redis' tilfælde af og til fjernudførelse af kode. Risikoen er ikke, at en angriber måske finder en sårbarhed på et tidspunkt — det er direkte adgang til jeres data med intet andet end en almindelig klient.

Hvad skal jeg gøre, hvis jeg finder en åben port?

Luk porten først og undersøg bagefter: begræns porten til de adresser, der har brug for den, via en firewall-regel, en sikkerhedsgruppe eller et privat netværk, og find først derefter ud af, hvor længe den har stået åben. Gå derefter ud fra, at den er fundet — kunne en database nås, så behandl dens indhold som potentielt læst og dens adgangsoplysninger som kompromitteret, og udskift dem. Fravær af spor i en log, der måske ikke var slået til, er ikke bevis for, at der ikke skete noget.

Hvor VulnControl passer ind

VulnControl scanner et udvalgt sæt TCP-porte med høj signalværdi udefra jeres netværk og melder databaser, fjernadministration og admin-sider, der kan nås fra det offentlige internet — sammen med et tjek for følsomme filer, der kan hentes offentligt. Den laver almindelige forbindelser og læser det, tjenesterne selv byder ind med; den forsøger aldrig at udnytte noget eller logge ind, og den scanner kun værter, I har bekræftet at eje. Fordi den kører efter en plan, fanger den også den regel, der bliver tilføjet igen under næste års flytning.

Start gratis Udforsk VulnControl