Elasticsearch 9 nativ auf Ubuntu/Debian installieren und absichern (APT, TLS, UFW)

Wer Elasticsearch im Produktionsbetrieb ernsthaft einsetzt, kommt irgendwann an den Punkt, an dem Docker-Netzwerk-Overhead, Cgroup-Limits und Container-Abstraktion mehr stören als helfen. Die native Installation direkt auf dem Host – als systemd-Dienst, gesteuert per APT – ist schlanker, transparenter und bei Monitoring-Integrationen oft einfacher zu warten. Seit Elasticsearch 8.x (und damit auch 9.x) übernimmt das Paket beim Erststart automatisch die TLS-Konfiguration und setzt ein Superuser-Passwort; du musst Security also nicht mehr manuell verdrahten. Diese Anleitung zeigt den vollständigen Weg: von der Repository-Einrichtung über die Absicherung mit UFW bis zur JVM-Heap-Dimensionierung für den Echteinsatz.

Voraussetzungen

1. Betriebssystem: Ubuntu 22.04 LTS, 24.04 LTS oder 26.04 LTS; alternativ Debian 11 oder 12 – jeweils amd64 oder arm64
2. RAM: Mindestens 2 GB (für Tests); Empfehlung für Produktion: 8 GB oder mehr
3. Festplatte: Mindestens 20 GB freier Speicherplatz für Daten und Logs
4. Zugang: Root- oder sudo-Berechtigung auf dem Server
5. Netzwerk: Internetverbindung zum Elastic APT-Repository (artifacts.elastic.co)
6. Firewall: UFW vorinstalliert (bei Ubuntu standardmäßig vorhanden; sudo apt install ufw falls nicht)

Schritt 1: Abhängigkeiten installieren und GPG-Schlüssel einrichten

Zunächst holst du die benötigten Systempakete und importierst den Elastic-Signing-Key. Der GPG-Fingerprint dient als Verifikation – prüfe ihn nach dem Import im Terminal.

sudo apt update
sudo apt install ca-certificates curl gpg apt-transport-https -y

GPG-Schlüssel herunterladen und im Keyring ablegen:

sudo install -d -m 0755 /usr/share/keyrings
curl -fsSL https://artifacts.elastic.co/GPG-KEY-elasticsearch \
  | sudo gpg --dearmor --yes -o /usr/share/keyrings/elasticsearch-keyring.gpg
sudo chmod 0644 /usr/share/keyrings/elasticsearch-keyring.gpg

Fingerprint des importierten Schlüssels anzeigen und prüfen:

gpg --no-default-keyring \
  --keyring /usr/share/keyrings/elasticsearch-keyring.gpg \
  --fingerprint

Verifizieren: Die Ausgabe muss den Fingerprint 4609 5ACC 8548 582C 1A26 99A9 D27D 666C D88E 42B4 enthalten. Weicht der angezeigte Wert ab, brich den Vorgang sofort ab – das deutet auf eine manipulierte Verbindung hin.

Schritt 2: APT-Repository hinzufügen

Das Elastic APT-Repository verwendet die Suite-Bezeichnung stable – nicht den Ubuntu-Codenamen wie jammy oder noble. Dieser Unterschied ist der häufigste Fallstrick bei der Repository-Einrichtung und führt sonst zu 404-Fehlern beim apt update.

Empfohlenes DEB822-Format (moderne APT-Syntax):

printf '%s\n' \
  'Types: deb' \
  'URIs: https://artifacts.elastic.co/packages/9.x/apt' \
  'Suites: stable' \
  'Components: main' \
  'Architectures: amd64 arm64' \
  'Signed-By: /usr/share/keyrings/elasticsearch-keyring.gpg' \
  | sudo tee /etc/apt/sources.list.d/elasticsearch.sources

Alternativ im klassischen Einzeiler-Format:

echo "deb [signed-by=/usr/share/keyrings/elasticsearch-keyring.gpg] https://artifacts.elastic.co/packages/9.x/apt stable main" \
  | sudo tee /etc/apt/sources.list.d/elastic-9.x.list

Repository-Einbindung testen:

sudo apt update

Verifizieren: apt update darf keinen Fehler für artifacts.elastic.co ausgeben. Ein Hit oder Get in der Ausgabe bestätigt die korrekte Einbindung.

Schritt 3: Elasticsearch installieren und als systemd-Dienst einrichten

sudo apt install elasticsearch

Nach der Installation systemd-Konfiguration neu laden, Autostart aktivieren und den Dienst starten:

sudo systemctl daemon-reload
sudo systemctl enable elasticsearch.service
sudo systemctl start elasticsearch.service

Dienststatus prüfen:

sudo systemctl status elasticsearch.service

Verifizieren: Die Ausgabe zeigt Active: active (running). Falls der Dienst sich im Status activating befindet, ist der Erststart-Prozess (Auto-Configure Security) noch nicht abgeschlossen – das ist bei schwächeren Servern normal und kann 30–60 Sekunden dauern.

Schritt 4: Auto-generiertes Passwort sichern (Pflicht!)

Dies ist der kritischste Schritt der gesamten Installation. Elasticsearch schreibt das Passwort für den elastic-Superuser einmalig beim Erststart in die Systemd-Logs. Wird es hier verpasst, muss später elasticsearch-reset-password verwendet werden.

sudo journalctl -u elasticsearch.service | grep -A5 "Password for the elastic user"

Passwort nachträglich zurücksetzen (interaktiv, neues Passwort selbst wählen):

sudo /usr/share/elasticsearch/bin/elasticsearch-reset-password -i -u elastic

Oder automatisch ein neues Passwort generieren lassen:

sudo /usr/share/elasticsearch/bin/elasticsearch-reset-password -u elastic

Schritt 5: Installation testen (HTTPS mit Auto-TLS)

Elasticsearch hört nach dem Erststart bereits auf HTTPS. Das automatisch generierte CA-Zertifikat liegt unter /etc/elasticsearch/certs/http_ca.crt und wird beim Test-Request als vertrauenswürdige CA angegeben:

sudo curl --cacert /etc/elasticsearch/certs/http_ca.crt \
  -u elastic:DEIN_PASSWORT \
  https://localhost:9200

Verifizieren: Die Antwort ist ein JSON-Objekt mit den Feldern cluster_name, version.number (z. B. 9.4.1) und tagline: "You Know, for Search". Erscheint stattdessen ein TLS-Fehler, ist der Erststart möglicherweise noch nicht vollständig abgeschlossen.

Schritt 6: Produktionskonfiguration in elasticsearch.yml

Die zentrale Konfigurationsdatei liegt unter /etc/elasticsearch/elasticsearch.yml. Für den Einzelserver-Betrieb sind vor allem vier Einstellungen entscheidend: Cluster-Name, Node-Name, Netzwerk-Bind und der Single-Node-Discovery-Modus.

sudo nano /etc/elasticsearch/elasticsearch.yml

Empfohlene Produktionseinstellungen:

# Cluster- und Node-Identitaet (immer explizit setzen)
cluster.name: mein-prod-cluster
node.name: node-01

# Netzwerk: nur auf interne IP binden, NICHT 0.0.0.0
network.host: 127.0.0.1
# Fuer servernetzwerk-interne Erreichbarkeit:
# network.host: 10.0.1.5

# Ports
http.port: 9200
transport.port: 9300

# Single-Node-Modus (Pflicht fuer Einzelinstanz!)
discovery.type: single-node

# Datenpfade (korrekt durch APT gesetzt)
path.data: /var/lib/elasticsearch
path.logs: /var/log/elasticsearch

# Security (automatisch vom Erststart geschrieben - nur pruefen, nicht loeschen)
xpack.security.enabled: true
xpack.security.enrollment.enabled: true

xpack.security.http.ssl:
  enabled: true
  keystore.path: certs/http.p12

xpack.security.transport.ssl:
  enabled: true
  verification_mode: certificate
  keystore.path: certs/transport.p12
  truststore.path: certs/transport.p12

Nach Änderungen Dienst neu starten:

sudo systemctl restart elasticsearch.service

Wichtige Hinweise: discovery.type: single-node ist für Einzelinstanzen zwingend erforderlich – ohne diese Einstellung wartet Elasticsearch auf weitere Cluster-Mitglieder. network.host: 0.0.0.0 darf in der Produktion niemals ohne gleichzeitige Firewall-Regeln gesetzt werden.

Schritt 7: JVM-Heap korrekt dimensionieren

Elasticsearch läuft auf der JVM – eine falsche Heap-Dimensionierung ist einer der häufigsten Performance-Killer. Die Faustregel: 50 % des verfügbaren RAMs, aber niemals mehr als 26–31 GB (Grenze für Compressed Object Pointers, kurz CoP). Wird diese Grenze überschritten, deaktiviert die JVM einen wichtigen Speicheroptimierungs-Mechanismus.

JVM-Heap-Datei anlegen (Beispiel für einen Server mit 8 GB RAM):

printf '%s\n' '-Xms4g' '-Xmx4g' \
  | sudo tee /etc/elasticsearch/jvm.options.d/heap.options
sudo systemctl restart elasticsearch.service

Wichtig: -Xms (Initial Heap) und -Xmx (Max Heap) müssen immer auf denselben Wert gesetzt werden, um Heap-Resizing-Overhead zu vermeiden.

Schritt 8: UFW-Firewall-Regeln setzen

Ohne Firewall ist Port 9200 für alle Interfaces erreichbar, die in network.host konfiguriert sind. Für die Härtung gilt: Port 9200 (REST-API) und Port 9300 (Node-Transport) dürfen nur für explizit vertrauenswürdige IPs oder Subnetze erreichbar sein. Die grundlegende VPS-Absicherung wird in der Anleitung VPS absichern und härten mit UFW, SSH-Keys und Fail2Ban ausführlich beschrieben.

Grundlegende UFW-Konfiguration sicherstellen:

sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow OpenSSH

Elasticsearch-Ports gezielt freigeben:

# Port 9200 nur fuer eine bestimmte Anwendungs-IP:
sudo ufw allow from 192.168.1.50 to any port 9200 proto tcp

# Oder fuer ein ganzes internes Subnetz:
sudo ufw allow from 10.0.1.0/24 to any port 9200 proto tcp

# Port 9300 (Transport) nur intern (fuer Cluster-Setups):
sudo ufw allow from 10.0.1.0/24 to any port 9300 proto tcp

UFW aktivieren und Status prüfen:

sudo ufw enable
sudo ufw status numbered

Aktive Listener kontrollieren:

sudo ss -tlnp | grep -E ':9200|:9300'

Verifizieren: ss zeigt Elasticsearch nur auf der in network.host konfigurierten IP-Adresse, nicht auf 0.0.0.0. ufw status listet die definierten Regeln für Ports 9200 und 9300.

Schritt 9: Weitere Built-in-User einrichten (optional)

Wenn du Kibana oder Logstash anschließen möchtest, musst du die jeweiligen systeminternen Benutzer ebenfalls mit Passwörtern ausstatten:

# Kibana-System-Benutzer:
sudo /usr/share/elasticsearch/bin/elasticsearch-reset-password -u kibana_system

# Logstash-System-Benutzer:
sudo /usr/share/elasticsearch/bin/elasticsearch-reset-password -u logstash_system

Schritt 10: Manuelles TLS-Zertifikat mit elasticsearch-certutil (optional)

Das automatisch generierte TLS-Setup reicht für die meisten Produktionsszenarien aus. Wenn du jedoch eine eigene CA verwenden oder Hostnamen und SANs (Subject Alternative Names) gezielt steuern möchtest, bietet elasticsearch-certutil einen interaktiven Wizard:

# Eigene CA erzeugen:
sudo /usr/share/elasticsearch/bin/elasticsearch-certutil ca \
  --out /etc/elasticsearch/certs/elastic-stack-ca.p12

# HTTP-Zertifikat erzeugen (interaktiver Wizard):
sudo /usr/share/elasticsearch/bin/elasticsearch-certutil http

Keystore-Passwort sicher hinterlegen:

sudo /usr/share/elasticsearch/bin/elasticsearch-keystore add \
  xpack.security.http.ssl.keystore.secure_password

Nach einem Zertifikatstausch müssen die neuen Dateien für den Systembenutzer elasticsearch lesbar sein:

sudo chown elasticsearch:elasticsearch /etc/elasticsearch/certs/*.p12
sudo chmod 0640 /etc/elasticsearch/certs/*.p12

Schritt 11: Elasticsearch aktualisieren

Dank des APT-Repositories ist das Update-Prozedere unkompliziert:

sudo apt update
sudo apt install --only-upgrade elasticsearch
sudo systemctl restart elasticsearch.service

Wenn du verhindern möchtest, dass Elasticsearch bei einem unbeaufsichtigten apt upgrade automatisch mitaktualisiert wird:

sudo apt-mark hold elasticsearch

Übersicht: Wichtige Pfade und Ports

Troubleshooting / Typische Fehler

Passwort beim Erststart verpasst

Das auto-generierte Passwort erscheint nur einmal in den Logs. Wenn der Zeitraum bereits verstrichen ist, hilft nur noch: sudo /usr/share/elasticsearch/bin/elasticsearch-reset-password -i -u elastic.

Repository-Suite falsch angegeben

Die Suite im APT-Eintrag muss stable heißen, nicht jammy, focal oder ein anderer Ubuntu-Codename. Falscher Eintrag führt zu 404-Fehlern beim apt update.

curl gibt „SSL certificate problem" zurück

Stelle sicher, dass du --cacert /etc/elasticsearch/certs/http_ca.crt angibst. Nach einem manuellen certutil-Lauf muss der Client das neue CA-Zertifikat verwenden.

Dienst startet nach YAML-Änderung nicht mehr

YAML ist einrückungs-sensitiv – verwende ausschließlich Leerzeichen, keine Tabs. Logs prüfen mit sudo journalctl -u elasticsearch.service -n 50.

Security-Auto-Config wurde nicht ausgeführt

Die automatische Sicherheitskonfiguration wird nur beim allerersten Start ausgeführt und nur dann, wenn keine inkompatiblen Einstellungen in elasticsearch.yml vorhanden sind. Wer vor dem Erststart bereits Einstellungen gesetzt hat, muss TLS und Passwort manuell konfigurieren.

Heap-Warning: „heap size is too high"

Elasticsearch warnt, wenn der Heap über 50 % des verfügbaren RAMs liegt. Werte in /etc/elasticsearch/jvm.options.d/heap.options korrigieren und Dienst neu starten.

Zertifikatspfade falsch oder Berechtigungen fehlen

Wenn http.p12 oder transport.p12 nicht in /etc/elasticsearch/certs/ liegen oder die Rechte für den Benutzer elasticsearch nicht stimmen, startet der Dienst nicht. Prüfen mit ls -la /etc/elasticsearch/certs/.

Häufige Fragen

Wird Docker benötigt?

Nein. Elasticsearch 9.x wird direkt über das offizielle Elastic APT-Repository als natives Debian-Paket installiert und läuft als systemd-Dienst auf dem Host. Docker ist für diese Installationsvariante nicht erforderlich.

Ist TLS bei Elasticsearch 9 standardmäßig aktiv?

Ja. Seit Elasticsearch 8.0 (gilt auch für 9.x) aktiviert der Erststart automatisch TLS für HTTP- und Transport-Layer und generiert die nötigen Zertifikate unter /etc/elasticsearch/certs/. Eine manuelle Konfiguration ist bei Neuinstallationen nicht mehr zwingend erforderlich.

Wie groß soll der JVM-Heap sein?

Empfehlung: 50 % des verfügbaren RAMs, jedoch maximal 26–31 GB (Grenze für Compressed Object Pointers). Auf einem Server mit 8 GB RAM also -Xms4g -Xmx4g in /etc/elasticsearch/jvm.options.d/heap.options. Beide Werte müssen identisch sein.

Was ist der Unterschied zwischen Port 9200 und 9300?

Port 9200 ist die HTTPS-REST-API für alle Clients (Anwendungen, Kibana, Logstash). Port 9300 ist der interne TCP-Transport-Port für die Node-zu-Node-Kommunikation im Cluster. Beide Ports müssen per UFW auf vertrauenswürdige IPs beschränkt werden – Port 9300 wird in vielen Anleitungen übersehen.

Kann Elasticsearch auf ARM-Servern betrieben werden?

Ja. Das offizielle APT-Repository unterstützt explizit sowohl amd64 als auch arm64-Architekturen. AWS Graviton, Raspberry Pi 5 und andere ARM64-Server werden somit offiziell unterstützt.

Was passiert, wenn cluster.initial_master_nodes in der Config bleibt?

Diese Einstellung ist ausschließlich für den allerersten Cluster-Start gedacht und darf danach nicht mehr in der Konfiguration stehen. Im Single-Node-Betrieb mit discovery.type: single-node ist sie ohnehin irrelevant und kann entfernt werden.

Fazit

Die native Elasticsearch-9-Installation auf Ubuntu oder Debian ist dank des offiziellen APT-Repositories und der automatischen Security-Konfiguration beim Erststart weniger komplex als ihr Ruf. Der entscheidende Vorteil gegenüber Docker: direkter Zugriff auf systemd-Logs, volle Kontrolle über JVM-Ressourcen und kein Container-Netzwerk-Overhead. Die drei Pflicht-Maßnahmen für den Produktionsbetrieb – network.host auf interne IP beschränken, JVM-Heap korrekt dimensionieren und UFW-Regeln für Ports 9200 und 9300 setzen – sind schnell umgesetzt und eliminieren die häufigsten Angriffsvektoren. Elasticsearch 9.x setzt Security by Default konsequent um; die eigentliche Arbeit liegt in der richtigen Dimensionierung und Netzwerk-Isolation, nicht mehr in der manuellen TLS-Verdrahtung.

Weiterführende Anleitungen und Quellen

1. VPS absichern und härten: UFW, SSH-Keys und Fail2Ban – Basis-Härtung für jeden Linux-Server
2. PostgreSQL nativ installieren und absichern (Ubuntu/Debian, ohne Docker) – natives Datenbank-Setup im selben Cluster-Stil
3. MongoDB nativ installieren und absichern (Ubuntu/Debian, ohne Docker) – weiteres NoSQL-Pendant zur nativen Elasticsearch-Anleitung
4. Linux-Server absichern: UFW-Firewall und Fail2Ban – ergänzende Absicherungsmaßnahmen
5. Elasticsearch: Install with Debian Package (offizielle Elastic-Dokumentation)
6. Elasticsearch: Security mit automatischer Konfiguration (offizielle Elastic-Dokumentation)