Datahorses

Open databasepoorten: MySQL, PostgreSQL, MongoDB, Redis en Elasticsearch vanaf internet bereikbaar

Door · · 4 min leestijd

Een databasepoort staat open wanneer iedereen op internet er een verbinding mee kan opzetten. Uw applicatie moet de database kunnen bereiken; een willekeurige computer in een ander land niet. Toch kan één firewallregel, een gewijzigde configuratieregel of een standaardinstelling in de cloud ervoor zorgen dat MySQL, PostgreSQL, MongoDB, Redis of Elasticsearch antwoord geeft aan het hele internet.

Een open poort is niet automatisch een datalek. Als de authenticatie sterk is en de software up-to-date, moet een aanvaller daar nog altijd langs. Maar een open poort maakt van uw database iets waar iedereen aan kan morrelen, wachtwoorden op kan raden en op bekende kwetsbaarheden kan testen. Door de poort te sluiten verdwijnt die hele categorie risico's.

Dit artikel zet de standaardpoorten op een rij, laat zien hoe u ze van buitenaf controleert en legt uit hoe u ze goed afsluit.

De standaardpoorten die u moet kennen

Dit zijn de standaardpoorten volgens de documentatie van elke leverancier:

Diensten kunnen ook op andere poorten draaien. Zie deze lijst dus als vertrekpunt, niet als volledige scan.

Hoe databases op internet belanden

De meeste van deze producten zijn standaard veiliger dan vroeger:

Blootstelling ontstaat dus meestal door een bewuste wijziging die tijdelijk bedoeld was:

  • iemand zette bind-address = 0.0.0.0, listen_addresses = '*' of bindIpAll zodat een ontwikkelaar thuis kon verbinden,
  • protected mode of de beveiliging werd uitgeschakeld "om het werkend te krijgen",
  • een security group in de cloud of een firewallregel laat de poort toe vanaf 0.0.0.0/0,
  • een Docker-optie -p 6379:6379 publiceert de poort op elke interface van de host,
  • een oude test- of stagingserver met een eigen database werd nooit uitgezet.

De Redis-documentatie is duidelijk over het risico: Redis is ontworpen voor vertrouwde clients in vertrouwde omgevingen, en een bereikbare instantie kan met één enkel FLUSHALL-commando haar volledige dataset kwijtraken.

Zo controleert u van buitenaf

De controle moet van buiten uw netwerk komen, anders test u alleen het interne pad. Gebruik een machine op een andere verbinding (een cloud-VM, een hotspot van uw telefoon) en test alleen IP-adressen die van u zijn:

for port in 3306 5432 27017 6379 9200 9300; do
  nc -z -w 3 203.0.113.10 $port && echo "$port open" || echo "$port closed"
done

Op de server zelf ziet u op welke adressen elke dienst luistert:

sudo ss -tlnp | grep -E ':(3306|5432|27017|6379|9200|9300)\b'

127.0.0.1:5432 of een privéadres is wat u wilt zien. 0.0.0.0:5432 of [::]:5432 betekent dat de dienst op elke interface luistert en dat alleen een firewall tussen de dienst en het internet staat.

Internetscanners houden ook voor elk extern IP-adres bij welke poorten openstaan. Voor een snelle blik op wat er voor een van uw adressen is vastgelegd, biedt Shodan een eenvoudige opzoekfunctie op https://internetdb.shodan.io/<your-ip>.

Zo sluit u het goed af

Werk met 2 lagen, zodat één fout de database niet opnieuw blootstelt:

  1. Luister alleen op privé-interfaces. bind-address = 127.0.0.1 (MySQL), listen_addresses = 'localhost' of een privé-IP (PostgreSQL), net.bindIp (MongoDB), bind 127.0.0.1 met protected-mode yes (Redis), network.host op een privéadres (Elasticsearch).
  2. Beperk op netwerkniveau. De firewall of de security group in de cloud laat de databasepoort alleen toe vanaf uw applicatieservers.
  3. Toegang op afstand via een tunnel. Ontwikkelaars verbinden via SSH-tunnels of een VPN, nooit via een open poort.
  4. Vereis overal authenticatie, ook op interne netwerken: gebruikers met minimale rechten, lange wachtwoorden en TLS voor verbindingen die een host verlaten.
  5. Houd de software bijgewerkt, zodat een poort die per ongeluk toch openstaat niet ook nog een versie met bekende kwetsbaarheden draait.

Was een database bereikbaar met zwakke of helemaal geen authenticatie, ga er dan van uit dat de gegevens mogelijk gekopieerd zijn: vervang de inloggegevens, bekijk de logs en ga na welke meldplichten u hebt.

Korte checklist

  • Maak een lijst van alle externe IP-adressen die uw bedrijf gebruikt, ook van oude servers.
  • Test de gangbare databasepoorten van buitenaf.
  • Zorg dat elke database alleen op localhost of een privéadres luistert.
  • Laat databasepoorten in de firewall alleen toe vanaf applicatieservers.
  • Controleer opnieuw na elke migratie, nieuwe server of wijziging in Docker.

Open diensten komen zelden alleen voor. Ze staan vaak op dezelfde vergeten stagingservers waar ook .env- en back-upbestanden uitlekken.

Hoe Datahorses helpt

Datahorses bewaakt uw bedrijf elke dag van buitenaf en laat zien welke diensten een aanvaller op uw externe adressen kan zien, waaronder databasepoorten en toegang op afstand zoals RDP of SSH, samen met bekende kwetsbaarheden voor de versies die ze prijsgeven. Wij gaan uw systemen niet binnen en hebben geen toegang nodig. Bij elke bevinding horen exacte herstelstappen voor uw ontwikkelaar, zoals beschreven in wat er gebeurt als wij iets vinden. Het voorbeelddashboard laat zien hoe zo'n rapport eruitziet.

Meer artikelen

Alle artikelen