LLMjacking 2026: So härten Sie Ihren selbst gehosteten LLM-Endpunkt richtig ab

Wer sein Sprachmodell selbst betreibt, hat den Datenschutz im Griff: Kein Prompt verlässt das Haus, keine AVV-Diskussion mit einem US-Anbieter, keine Modellabschaltung durch Dritte. Genau deshalb empfehlen wir On-Premise-Betrieb für alles, was Geschäftsgeheimnisse oder personenbezogene Daten berührt. Nur: Datenschutz ist nicht Sicherheit. Ein selbst gehosteter Inferenz-Server ist eine ganz normale Netzwerkkomponente – und die meisten davon stehen heute deutlich schlechter geschützt im Netz als ein zehn Jahre alter Fileserver.

Der Angriffstyp, der daraus entstanden ist, heißt LLMjacking. Er braucht keine Zero-Day-Lücke, kein Reverse Engineering und keine besonderen Fähigkeiten. Er braucht nur einen Port, der antwortet. Dieser Artikel zeigt, was 2026 tatsächlich gemessen wurde, wie Sie Ihre eigene Exposition in zehn Minuten prüfen und welche Konfiguration bei Ollama und vLLM wirklich schützt – inklusive einer Fallgrube, die selbst erfahrene Admins übersehen.

Was LLMjacking ist

LLMjacking bezeichnet die unbefugte Nutzung fremder KI-Inferenzkapazität. Der Angreifer bricht nicht ein, um Daten zu stehlen – er meldet sich einfach an einem Endpunkt an, der niemanden nach Legitimation fragt, und rechnet auf Ihrer Hardware oder auf Ihrem Anbieterkonto. Der Begriff stammt aus einer Sysdig-Untersuchung vom Mai 2024, hat sich seither aber vom Kuriosum zum organisierten Geschäftsmodell entwickelt.

Kein CVE nötig

Das ist der entscheidende Unterschied zu klassischen Exploits: Die dokumentierten LLMjacking-Kampagnen nutzen keine Schwachstelle im technischen Sinne. Sie nutzen Fehlkonfiguration. Der beobachtete Verkehr besteht aus Liveness-Checks, Modell-Fingerprinting und Enumerationsaufrufen – bei Ollama typischerweise GET /api/tags, bei OpenAI-kompatiblen APIs GET /v1/models. Zenity Labs bestätigte in seiner Untersuchung „Scanning for AI" (30. Juni 2026) unabhängig: reine Recon-Aufrufe ohne Exploit-Payload.

Eine Einschränkung gehört dazu: „Kein CVE" gilt für den LLM-Recon-Traffic, nicht für die Akteure insgesamt. GreyNoise beobachtete parallel Kampagnen, bei denen dieselben Quell-IPs über 200 verschiedene CVEs durchprobierten. Wer Ihren Ollama-Port findet, testet mit hoher Wahrscheinlichkeit auch alles andere.

Dreistufig: Scanner, Validator, Marktplatz

Die Arbeitsteilung ist industriell. Stufe eins sind verteilte Scanner-Bots, die das Internet nach LLM- und MCP-Endpunkten absuchen. Stufe zwei ist eine Validator-Infrastruktur, die prüft, ob der Zugriff funktioniert und welche Modelle verfügbar sind. Stufe drei ist ein Marktplatz, der den validierten Zugang weiterverkauft.

Gestohlene KI-Compute als Offensiv-Infrastruktur

Bis 2025 war LLMjacking primär ein Kostenproblem. Das hat sich geändert. Die Cloud Security Alliance veröffentlichte am 20. Juni 2026 die Research Note „LLMjacking Evolved: Stolen AI Compute as Offensive Infrastructure" – Vorläufer war die Note „LLMjacking: AI Model Hijacking Reaches Black Market Scale" vom 15. März 2026. Kernbefund: Am 12. Juni 2026 dokumentierte Sysdig den ersten bestätigten Fall, in dem ein fehlkonfigurierter Ollama-Modellserver als Reasoning-Engine für eine mehrstufige, VAPT-artige Angriffskette diente. Ihr Modell denkt dann für den Angreifer – und Ihr Log zeigt Ihre IP als Quelle.

Die Zahlenlage 2026

Die kursierende Zahl „175.000 offene Ollama-Server" ist korrekt, wird aber fast immer falsch gelesen. Sie stammt aus einer im Januar 2026 berichteten Untersuchung und bezeichnet 175.000 eindeutige Hosts in 130 Ländern, kumuliert über 293 Beobachtungstage aus 7,23 Millionen Einzelbeobachtungen. Es ist keine Momentaufnahme. Wer die Zahl ohne diesen Zusatz zitiert, bekommt sie im Gespräch mit der IT-Leitung um die Ohren gehauen.

Die Momentaufnahmen liegen niedriger – und sind trotzdem alarmierend. LeakIX zählte am 23. Februar 2026 exakt 12.269 öffentlich erreichbare Ollama-Instanzen, sämtlich ohne jede Authentifizierung. Deutschland liegt auf Platz vier. Cisco Talos fand per Shodan im September 2025 noch 1.139 exponierte Instanzen; dieselbe Abfrage ergab im April 2026 über 25.000. Der Anstieg ist die eigentliche Geschichte, nicht die einzelne Gesamtzahl.

Land	Offene Ollama-Instanzen	Hoster (gesamt)	Instanzen
USA	1.829	AWS	1.686
China	1.712	Hetzner	1.004
Frankreich	1.425	OVH	773
Deutschland	1.364	Contabo	634
Südkorea	453	Gesamt (Scan)	12.269

Quelle: LeakIX-Momentaufnahme vom 23.02.2026. Rund 1.000 dieser Instanzen liefen auf Versionen, die für CVE-2024-37032 anfällig sind.

Operation Bizarre Bazaar

Pillar Security veröffentlichte am 28./29. Januar 2026 die Analyse der ersten LLMjacking-Kampagne, die einem konkreten Akteur zugeordnet werden konnte. Über 35.000 Angriffs-Sessions auf Honeypots in rund 40 Tagen (Dezember 2025 bis Januar 2026), im Schnitt 972 Angriffe pro Tag. Akteur: „Hecker", alias Sakuya beziehungsweise LiveGamer101, mit Infrastruktur-Überschneidungen zum Dienst nexeonai.com.

Der Marktplatz läuft unter der Marke „silver.inc" und verkauft Zugang zu über 30 LLMs mit 40 bis 60 Prozent Rabatt gegenüber den Listenpreisen der legitimen Anbieter. Beworben wird über Telegram und Discord, bezahlt in Kryptowährung oder per PayPal, gehostet auf Bulletproof-Infrastruktur in den Niederlanden. Zielsysteme: unauthentifizierte Ollama-Endpunkte auf Port 11434, OpenAI-kompatible APIs auf Port 8000, offen erreichbare MCP-Server, Dev- und Staging-Umgebungen mit öffentlicher IP sowie ungeschützte Produktions-Chatbots auf 80/443. Bis Ende Januar 2026 entfielen bereits 60 Prozent des Angriffsvolumens auf MCP-Recon.

Die härteste Zahl der gesamten Untersuchung: Neu öffentlich sichtbare Endpunkte wurden im Schnitt binnen zwei bis acht Stunden nach ihrem Auftauchen validiert und weiterverwertet. Ein „nur mal kurz zum Testen" freigegebener Port ist noch am selben Arbeitstag Ware.

Was das kostet

Hier ist Präzision wichtig, weil die kursierenden Zahlen durcheinandergeraten. Pillar und SecurityWeek nennen zu Bizarre Bazaar ausdrücklich keine Dollarbeträge. Die Zahl von über 100.000 US-Dollar pro Tag stammt aus der ursprünglichen Sysdig-Forschung: Ein einzelnes gekapertes Konto konnte bei Claude 2.x rund 46.000 USD Inferenzkosten pro Tag erzeugen, bei Claude 3 Opus über 100.000 USD pro Tag. Das ist eine modellierte Kostenobergrenze bei Dauerlast auf Top-Tier-Modellen – aber sie zeigt die Dimension. Wer selbst hostet, zahlt nicht in Dollar, sondern in Strom, GPU-Lebensdauer und verdrängter Produktivlast.

Weitere Begleitzahlen aus der CSA-Note: plus 376 Prozent Credential-Diebstahl gegen KI-Dienste von Q4 2025 auf Q1 2026 und rund 113.000 Probe-Requests auf einem Kaspersky-Honeypot innerhalb eines Monats, davon 23 Prozent gezielt auf KI-Model-Serving.

Was Honeypots sehen

Zenity Labs maß vom 22. Februar bis 3. Juni 2026 rund 60.000 Liveness- und Fingerprinting-Requests von 235 Quell-IPs sowie rund 31.000 Modellkatalog-Abrufe von etwa 1.000 IPs – insgesamt über 1.400 verschiedene Quell-IPs. Wichtig für die Einordnung: Diese Summe verteilt sich auf vier Dienste – Ollama (11434), LiteLLM (4000), LangServe (8000) und OpenClaw (18789). Port 8000 steht in diesem Datensatz für LangServe; vLLM lauscht per Default zwar ebenfalls auf 8000, ist aber nicht die Quelle dieser Zahlen. Zum Automatisierungsgrad: Eine Quelle schickte identische Prompts je 2.619 Mal an acht Ollama-Modelle, eine andere rotierte 40 API-Keys über 31 LiteLLM-Modelle. Neun der zehn aktivsten Quell-IPs waren in Threat-Intel-Datenbanken bereits als bösartig geführt.

Der Exposure-Check in zehn Minuten

Schritt 1: Lokale Listener aufnehmen

Auf jedem Host, der ein Modell serviert: ss -tlnp | grep -E '11434|8000|4000|18789'. Interessant ist nicht, ob der Port offen ist, sondern auf welcher Adresse. 127.0.0.1:11434 ist unkritisch, 0.0.0.0:11434 ist es nur dann, wenn davor zuverlässig gefiltert wird. Prüfen Sie zusätzlich, ob eine Umgebungsvariable OLLAMA_HOST=0.0.0.0 gesetzt ist – etwa in einer systemd-Unit oder einem Docker-Compose-File.

Schritt 2: Die Außensicht einnehmen

Von einem Netz außerhalb Ihrer Firewall – Mobilfunk-Hotspot genügt – gegen Ihre eigene öffentliche IP: curl -s -m 5 http://IHRE-IP:11434/api/tags und curl -s -m 5 http://IHRE-IP:8000/v1/models. Kommt eine JSON-Antwort mit Modellnamen zurück, ist der Fall klar. Wiederholen Sie das für jede öffentliche IP Ihres Unternehmens, nicht nur für die des Servers – NAT-Regeln und vergessene Portweiterleitungen sind der häufigste Befund. Vergessen Sie IPv6 nicht: Container bekommen dort oft eine global routbare Adresse, während die Firewall nur v4 filtert.

Schritt 3: Suchmaschinen gegen die eigenen Bereiche

Shodan und LeakIX erlauben die Einschränkung auf eigene Netze, etwa net:203.0.113.0/24 port:11434. Das Ergebnis ist keine Prognose, sondern Historie – wenn Sie dort auftauchen, waren Sie mindestens einmal sichtbar.

Schritt 4: Logs auf Enumeration durchsehen

Suchen Sie in Reverse-Proxy- und Anwendungslogs der letzten 90 Tage nach /api/tags, /api/ps, /v1/models, /v1/completions und /v1/embeddings von Quell-IPs, die nicht zu Ihren Clients gehören. Zur Größenordnung: HoneyLabs zählte im Mai 2026 auf Port 11434 wöchentlich 50 bis 80 verschiedene Quell-IPs, Spitze 85 in der Woche des 8. März – 1.242 Treffer im 30-Tage-Fenster, davon 129 auf /api/tags von 31 IPs. Auf OpenAI-kompatiblen Pfaden: 306 Treffer auf /v1/models von 46 IPs aus 12 ASNs, 168 auf /v1/embeddings, 166 auf /v1/completions.

Schritt 5: Versionsstand prüfen

Notieren Sie die laufende Ollama- und vLLM-Version. Rund 1.000 der 12.269 im Februar 2026 gefundenen Ollama-Instanzen liefen noch auf Ständen, die für CVE-2024-37032 anfällig sind. Prüfen Sie außerdem CVE-2026-7482 („Bleeding Llama", CVSS 9.1, offengelegt am 10. Mai 2026, behoben in Ollama 0.17.1) – ein Out-of-Bounds-Read im GGUF-Modellparser, unauthentifiziert ausnutzbar über /api/create mit Abholung geleakter Heap-Inhalte über /api/push. Zum Offenlegungszeitpunkt wurden über 300.000 aus dem Internet erreichbare Ollama-Server auf Versionen vor 0.17.1 gezählt.

Netzarchitektur: Der Endpunkt gehört nie ins Internet

Alle folgenden Maßnahmen sind Ergänzungen. Die eigentliche Entscheidung ist die Topologie. Ein Inferenz-Server hat keinen Grund, aus dem Internet direkt erreichbar zu sein – auch dann nicht, wenn externe Nutzer ihn verwenden sollen.

Eigenes VLAN ohne direkte Erreichbarkeit

Der GPU-Server gehört in ein eigenes Segment mit eigener Firewall-Policy. Eingehend erlaubt: ausschließlich der Reverse Proxy beziehungsweise das API-Gateway, auf genau einem Port. Alles andere wird verworfen. Das gilt auch für Management-Zugänge – SSH und IPMI über ein separates Admin-VLAN, nicht über dasselbe Interface.

Besonders wichtig bei vLLM: Die offizielle Dokumentation weist ausdrücklich darauf hin, dass sämtliche Kommunikation zwischen den Knoten einer Multi-Node-Installation standardmäßig unverschlüsselt und unauthentifiziert ist. Dieses Netz muss physisch oder logisch isoliert sein. Wer einen Tensor-Parallel-Cluster über ein geteiltes Rechenzentrums-VLAN spannt, hat faktisch eine offene Backdoor gebaut.

Zugriff ausschließlich über Proxy oder Gateway

Vor dem Modell steht nginx, Traefik, Envoy oder ein API-Gateway. Diese Schicht erledigt TLS-Terminierung, Authentifizierung, Rate Limiting, Request-Größenbegrenzung und Logging – alles Dinge, die weder Ollama noch vLLM selbst mitbringen. Entscheidend ist dabei das Prinzip Allowlist statt Blocklist: Der Proxy reicht nur die Pfade durch, die Ihre Anwendung tatsächlich braucht. Alles andere endet mit 404.

Deny-by-default beim ausgehenden Verkehr

Der oft übersehene Teil. Ein kompromittierter Inferenz-Server ist nur dann als Offensiv-Infrastruktur brauchbar, wenn er ins Internet hinaus telefonieren darf. Egress auf Deny-by-default setzen und nur explizit benötigte Ziele freigeben: interner Paketspiegel, interne Registry, interner NTP- und DNS-Server. Modelle werden auf einem separaten Staging-Host gezogen und ins Segment kopiert, nicht direkt vom Produktionsserver aus dem Internet gepullt. Das begrenzt gleichzeitig das Risiko manipulierter Modell-Artefakte.

Authentifizierung, mTLS und Rate Limiting

Kein unauthentifizierter Zugriff – auch nicht intern

Ollama bindet per Default auf 127.0.0.1:11434 und besitzt keinerlei eingebaute Authentifizierung. Das Setzen von OLLAMA_HOST=0.0.0.0 ohne vorgelagerte Firewall oder Proxy legt die komplette REST-API offen – inklusive /api/tags für die Modell-Enumeration sowie /api/pull, /api/push und /api/create. Letztere erlauben nicht nur Nutzung, sondern Manipulation des Modellbestands.

Interne Erreichbarkeit ist kein Ersatz für Authentifizierung. Ein per Phishing kompromittierter Laptop im selben Subnetz hat exakt dieselben Rechte wie Ihr Anwendungsserver.

Die vLLM-Falle: --api-key schützt nur /v1

Das ist der Punkt, an dem viele Härtungsanleitungen schlicht falsch sind. Der Schalter --api-key in vLLM schützt ausschließlich die OpenAI-kompatiblen Endpunkte unter dem Präfix /v1. Ungeschützt bleiben unter anderem:

• /invocations – der SageMaker-kompatible Pfad, funktional äquivalent zu einer Completion-Anfrage
• /pooling, /classify, /generative_scoring – vollwertige Inferenz-Pfade
• /pause, /abort_requests, /update_weights – Steuerendpunkte, mit denen sich der Dienst stoppen oder das geladene Modell austauschen lässt

Ein Angreifer umgeht die Authentifizierung also schlicht dadurch, dass er Nicht-/v1-Pfade aufruft. Die vLLM-Dokumentation sagt das wörtlich: nicht ausschließlich auf --api-key verlassen. Die dort empfohlene Lösung ist ein Reverse Proxy, der per Allowlist explizit nur die gewollten Endpunkte durchreicht. In nginx-Notation heißt das: location = /v1/chat/completions und location = /v1/models erlauben, ein abschließendes location / { return 404; } für alles Übrige.

mTLS oder OIDC statt statischer Schlüssel

Ein statischer API-Key ist das absolute Minimum, nicht der Zielzustand. Solche Schlüssel landen in Git-Repositories, in Jupyter-Notebooks, in Konfigurationsdateien auf Notebooks und werden praktisch nie rotiert. Besser sind kurzlebige Token aus einem Authorization Server – Keycloak, Authentik oder Entra ID – mit Laufzeiten im Minuten- bis Stundenbereich und einem Scope pro Anwendung. Für Service-zu-Service-Kommunikation ist gegenseitiges TLS die sauberste Variante: Der Proxy akzeptiert nur Clients mit gültigem Zertifikat aus Ihrer internen CA. Ein gestohlenes Token nützt dann ohne passenden privaten Schlüssel nichts.

Rate Limits und Kontingente pro Client

Weder Ollama noch vLLM bringen Rate Limiting mit. Es muss im Reverse Proxy oder Gateway erfolgen – limit_req und limit_conn in nginx, das RateLimit-Middleware in Traefik, ein Ratelimit-Filter in Envoy. Sinnvoll sind drei Ebenen: Requests pro Sekunde und Client, gleichzeitige Verbindungen pro Client sowie ein Token- oder Minutenkontingent pro Tag. Letzteres ist die eigentliche Kostenbremse: Selbst wenn jemand gültige Credentials erbeutet, endet der Missbrauch nach dem Tageskontingent statt nach der Stromrechnung. Ergänzend gehört eine harte Begrenzung der Request-Größe (client_max_body_size) und der max_tokens dazu – sonst genügt ein einzelner Riesen-Prompt, um die GPU zu blockieren.

Monitoring: Missbrauch sichtbar machen

Härtung verhindert den Erstzugriff. Monitoring verhindert, dass ein trotzdem gelungener Zugriff monatelang unbemerkt bleibt. Dieser Teil gehört zu einem geordneten LLMOps-Betrieb und ist ohne großen Aufwand nachrüstbar – die Daten fallen ohnehin im Proxy an.

Basislinie pro Client und Tageszeit

Erfassen Sie je Client-ID Requests pro Stunde, Prompt- und Completion-Tokens, verwendete Modelle und durchschnittliche Antwortlänge. Nach zwei Wochen haben Sie ein belastbares Normalprofil. Ein Fachabteilungs-Assistent hat eine klare Arbeitszeitkurve; ein Batch-Job hat ein klares Zeitfenster. Beides ist gut prognostizierbar – und genau deshalb sind Abweichungen aussagekräftig.

Alarme, die sich lohnen

• Neue Client-ID: Jede zuvor unbekannte Kennung erzeugt eine Meldung. In einer sauber verwalteten Umgebung passiert das selten genug für einen manuellen Blick.
• Modellwechsel: Wenn ein Client, der seit Monaten nur ein 8B-Modell nutzt, plötzlich das größte verfügbare Modell anspricht, ist das ein Signal.
• Nachtlast: Token-Verbrauch zwischen 22:00 und 06:00 Uhr, der 20 Prozent des Tagesdurchschnitts überschreitet, ohne dass ein geplanter Batch-Job läuft.
• Enumerationsmuster: Mehr als drei Aufrufe auf /api/tags oder /v1/models pro Stunde von derselben Quelle. Legitime Clients fragen den Modellkatalog beim Start ab, nicht permanent.
• Identische Prompts in Serie: Der Zenity-Datensatz zeigt Quellen mit 2.619 identischen Prompts pro Modell. Ein Hash über den Prompt-Text macht solche Muster trivial erkennbar.
• Geblockter Egress: Jeder ausgehende Verbindungsversuch vom Inferenz-Segment, den die Firewall verwirft, ist ein Alarm erster Güte.

In das bestehende Security-Monitoring einbinden

Die Proxy-Access-Logs gehören in dasselbe SIEM wie Firewall- und Endpoint-Logs, nicht in eine separate KI-Insel. Reichern Sie die Log-Zeilen um Client-ID, Modellname und Token-Zahlen an – ohne Prompt-Inhalte, um nicht selbst ein Datenschutzproblem zu erzeugen. Ein anonymisierter Hash des Prompts reicht für die Mustererkennung völlig aus. Ergänzen Sie GeoIP-Anreicherung und einen Abgleich gegen Threat-Intel-Feeds: Neun der zehn aktivsten Quell-IPs im Zenity-Datensatz waren dort bereits gelistet.

Hardening-Checkliste zum Abarbeiten

Sofort – heute, in dieser Reihenfolge

1. Externe Erreichbarkeit von Port 11434, 8000, 4000 und 18789 schließen; Portweiterleitungen im Router prüfen und löschen.
2. OLLAMA_HOST auf 127.0.0.1 zurücksetzen oder auf eine reine Proxy-Bind-Adresse begrenzen.
3. Authentifizierung im Reverse Proxy aktivieren – notfalls zunächst als statischer Key, sofort geplante Ablösung durch Token oder mTLS.
4. Bei vLLM: Allowlist im Proxy setzen, damit /invocations, /pause und /update_weights von außen nicht erreichbar sind.
5. Ollama auf mindestens 0.17.1 aktualisieren (CVE-2026-7482).
6. Logs der letzten 90 Tage auf Enumerationsaufrufe durchsehen; bei Treffern Incident-Prozess starten.

Kurzfristig – die nächsten vier Wochen

1. Inferenz-Server in ein eigenes VLAN verschieben, eingehend nur vom Gateway erreichbar.
2. Egress auf Deny-by-default; Modell-Downloads über internen Spiegel.
3. Rate Limits, Verbindungslimits und Tageskontingente pro Client konfigurieren.
4. Zentrales Logging mit Client-ID, Modell und Token-Zahlen; Basislinie über zwei Wochen aufbauen.
5. Multi-Node-Kommunikation bei vLLM in ein isoliertes Netz verlegen.
6. Guardrails und Prompt-Filter vorschalten, damit ein gültiger Zugang nicht automatisch beliebige Nutzung bedeutet.

Dauerhaft – in den Regelbetrieb überführen

1. Festes monatliches Patch-Fenster für Ollama, vLLM, Proxy und die umliegenden KI-Komponenten.
2. Quartalsweiser Zugangsreview: Welche Client-IDs existieren, wer nutzt sie, welche können weg?
3. Token-Rotation automatisieren; statische Keys vollständig ablösen.
4. Jährlicher Pentest mit ausdrücklichem KI-Scope – nicht nur Netz und Web, sondern auch Prompt-Ebene und Endpunkt-Enumeration.
5. Exposure-Check aus Abschnitt drei als wiederkehrende Aufgabe, mindestens quartalsweise.

Der Aufwand für die Sofortmaßnahmen liegt bei den meisten Installationen unter einem Personentag. Gemessen an zwei bis acht Stunden bis zur Validierung eines neu exponierten Endpunkts ist das die mit Abstand günstigste Sicherheitsinvestition, die Sie 2026 tätigen können. Wenn Sie den Umbau nicht selbst stemmen wollen, begleiten wir ihn im Rahmen unserer KI-Sicherheitsberatung – von der Bestandsaufnahme bis zur abgenommenen Zielarchitektur.

Quellen & Primärbelege

Alle Zahlen, Fristen und Produktangaben in diesem Beitrag wurden vor der Veröffentlichung gegen die folgenden Primaerquellen geprüft.

1. pillar.security operation bizarre bazaar first attributed llmjacking campaign with commercial ma
2. securityweek.com llms hijacked monetized in operation bizarre bazaar
3. bleepingcomputer.com hackers hijack exposed llm endpoints in bizarre bazaar operation
4. labs.zenity.io scanning for ai live campaigns mapping the internet s exposed llm backends
5. honeylabs.net ai scanning may 2026
6. labs.cloudsecurityalliance.org csa research note llmjacking evolved offensive agentic 20260
7. labs.cloudsecurityalliance.org CSA research note llmjacking black market ai model hijacking 20260315 csa styled
8. blog.leakix.net ollama exposed
9. thehackernews.com researchers find 175000 publicly
10. indusface.com exposed llm infrastructure risks
11. securityboulevard.com exposed llm infrastructure how attackers find and exploit misconfigured ai deplo
12. vLLM-Dokumentation security

Häufig gestellte Fragen zu LLMjacking und Endpunkt-Härtung

Ist mein Ollama-Server angreifbar, wenn er nur im Firmennetz läuft?

Deutlich weniger, aber nicht sicher. Ohne Authentifizierung kann jedes Gerät im selben Netz - auch ein kompromittierter Client - beliebig Anfragen stellen. Aktivieren Sie Authentifizierung auch intern.

Wie erkenne ich, ob mein Endpunkt bereits missbraucht wird?

Achten Sie auf ungewöhnlichen Token-Verbrauch außerhalb der Arbeitszeiten, unbekannte Client-Kennungen und Modell-Enumerationsaufrufe in den Logs. Eine Basislinie pro Client macht Abweichungen sofort sichtbar.

Reicht ein API-Key als Schutz?

Als Minimum ja, als Zielzustand nein. Statische Schlüssel landen in Repositories und Konfigurationsdateien. Besser sind kurzlebige Token über einen Authorization Server, ergänzt um mTLS und Rate Limits pro Client.

Wer haftet, wenn Angreifer meine GPU-Kapazität für Angriffe nutzen?

Betrieblich und rechtlich bleibt der Betreiber in der Verantwortung: Die Ressourcen, die Protokolle und die ausgehenden Verbindungen sind Ihre. Deshalb gehören Egress-Kontrolle und Logging zur Grundausstattung.