Onveilige Elasticsearch-instanties: risico’s en snelle mitigaties

In dit artikel leggen we helder en praktisch uit waarom open Elasticsearch-instanties gevaarlijk zijn en welke directe stappen je kunt nemen om ze veilig te maken.

Waarom een open Elasticsearch-instantie gevaarlijk is

Elasticsearch is een gedistribueerde zoek- en analytics-engine die veel wordt gebruikt voor logs en metrics. Als een node of cluster publiek bereikbaar is op poort 9200 zonder bescherming, kan dat leiden tot datalekken, sabotage van indices of het uitlezen van gevoelige configuratiegegevens. Sommige plugins en dynamic scripting-opties vergroten het risico op remote code execution.

Hoe controleer je snel of een instantie publiek bereikbaar is

Een snelle, niet-destructieve check (voer alleen uit op systemen waar je toestemming voor hebt):

curl -s http://example.com:9200/ | jq .

Als het antwoord zonder authenticatie informatie toont zoals cluster_name of version, is de service publiek bereikbaar en moet je direct handelen.

Directe mitigaties (prioriteit en exacte stappen)

Voer deze stappen in deze volgorde uit om het risico snel te verlagen:

• Bind alleen aan interne interfaces

  # /etc/elasticsearch/elasticsearch.yml
  network.host: 127.0.0.1
  

  In een clusteromgeving specificeer je alleen de interne netwerkadressen van de nodes.

• Beperk netwerktoegang (firewall of cloud security groups)

  # iptables voorbeeld (root)
  iptables -A INPUT -p tcp --dport 9200 -s 10.0.0.0/8 -j ACCEPT
  iptables -A INPUT -p tcp --dport 9200 -j DROP
  

  In cloudomgevingen gebruik je security groups of NSG’s om toegang vanaf het internet te blokkeren.

• Activeer authenticatie en TLS

  Activeer Elastic Security (X-Pack) of zet een reverse proxy met TLS en authenticatie voor kleine setups.

  # nginx reverse proxy voorbeeld
  server {
    listen 443 ssl;
    server_name es.example.local;
    ssl_certificate /etc/ssl/certs/es.pem;
    ssl_certificate_key /etc/ssl/private/es.key;
  
    location / {
      proxy_pass http://127.0.0.1:9200;
      proxy_set_header Host $host;
      proxy_set_header X-Real-IP $remote_addr;
      auth_basic "Restricted";
      auth_basic_user_file /etc/nginx/.htpasswd;
    }
  }
  

• Schakel dynamic scripting uit tenzij strikt nodig

  # elasticsearch.yml
  script.allowed_types: none
  

• Beveilig snapshots en opslag

  Sla snapshots op in private storage met encryptie en beperk toegangsrechten. Controleer recent aangemaakte snapshots op ongeautoriseerde exports.

Incident-respons checklist (direct uitvoeren bij ontdekking)

• Sluit publieke toegang met firewall/security groups.
• Schakel of verhoog audit logging en verzamel recentere logs.
• Controleer op onbekende snapshots of exports en markeer verdachte items.
• Reset alle beheerderscredentials en roep forensische snapshots op indien nodig.
• Restoureer corrupte indices vanuit vertrouwde backups.

Detectie en monitoring

Voorbeeld-commando’s en queries die helpen bij detectie (gebruik met bevoegdheid):

# lijst indices (alleen met credentials)
curl -s -u elastic:password http://127.0.0.1:9200/_cat/indices?v

# zoek naar snapshot-activiteit
curl -s -u elastic:password "http://127.0.0.1:9200/_snapshot/_all?pretty"

Zet alerts in je SIEM op ongebruikelijke requests naar poort 9200, ongewone snapshot-creaties en spikes in delete- of bulk API-calls.

Praktische inschatting

• Impact: hoog bij gevoelige logs/PII; dataverlies kan groot zijn.
• Rembedieningstijd: netwerkfixes en firewallregels: minuten; volledige recovery (backups + forensisch onderzoek): uren-dagen.

Samenvattend: sluit eerst netwerktoegang, zet daarna authenticatie en TLS in, en controleer snapshots en logs. Plan daarna een migratie naar een beveiligde configuratie met monitoring en periodieke audits.