Ollama API Accessed from External Network

Detects when the Ollama LLM server accepts connections from external IP addresses. Ollama lacks built-in authentication, so exposed instances allow unauthenticated model theft, prompt injection, and resource hijacking.

Elastic rule (View on GitHub)

  1[metadata]
  2creation_date = "2026/01/09"
  3integration = ["endpoint"]
  4maturity = "production"
  5updated_date = "2026/01/09"
  6
  7[rule]
  8author = ["Elastic"]
  9description = """
 10Detects when the Ollama LLM server accepts connections from external IP addresses. Ollama lacks built-in authentication,
 11so exposed instances allow unauthenticated model theft, prompt injection, and resource hijacking.
 12"""
 13from = "now-9m"
 14index = ["logs-endpoint.events.network-*"]
 15language = "eql"
 16license = "Elastic License v2"
 17name = "Ollama API Accessed from External Network"
 18note = """## Triage and analysis
 19
 20### Investigating Ollama API Accessed from External Network
 21
 22This rule detects when Ollama accepts connections from external IP addresses. Ollama binds to localhost:11434 by default but can be exposed via OLLAMA_HOST. Since Ollama lacks authentication, exposed instances allow unauthenticated model theft, prompt injection, and resource hijacking.
 23
 24### Possible investigation steps
 25
 26- Check the OLLAMA_HOST environment variable to determine if external exposure was intentional.
 27- Review the source IP address to identify if it's a known attacker, scanner, or miscategorized internal system.
 28- Examine Ollama logs for suspicious API calls to /api/pull, /api/push, or /api/generate.
 29- Check ~/.ollama/models/ for unexpected model downloads that may indicate model poisoning.
 30- Review network traffic for data exfiltration following the connection.
 31- Look for child processes spawned by Ollama that may indicate exploitation.
 32
 33### False positive analysis
 34
 35- Internal networks not properly classified in CIDR ranges may trigger false positives.
 36- Load balancers or reverse proxies accessing Ollama from external-facing IPs within trusted infrastructure.
 37- Legitimate remote access through VPN or authenticated proxy (add proxy IPs to exclusions).
 38
 39### Response and remediation
 40
 41- Restrict access immediately by setting OLLAMA_HOST=127.0.0.1:11434 or applying firewall rules.
 42- If exploitation is suspected, stop Ollama and audit ~/.ollama/models/ for unauthorized models.
 43- Review Ollama and system logs for signs of compromise.
 44- Consider running Ollama in a container with network isolation.
 45"""
 46references = [
 47    "https://www.greynoise.io/blog/threat-actors-actively-targeting-llms",
 48    "https://atlas.mitre.org/techniques/AML.T0040",
 49    "https://atlas.mitre.org/techniques/AML.T0044",
 50]
 51risk_score = 47
 52rule_id = "d8f2a1b3-c4e5-6789-abcd-ef0123456789"
 53severity = "medium"
 54tags = [
 55    "Domain: Endpoint",
 56    "OS: Linux",
 57    "OS: macOS",
 58    "OS: Windows",
 59    "Use Case: Threat Detection",
 60    "Tactic: Initial Access",
 61    "Data Source: Elastic Defend",
 62    "Resources: Investigation Guide",
 63    "Domain: LLM",
 64    "Mitre Atlas: T0040",
 65    "Mitre Atlas: T0044",
 66]
 67timestamp_override = "event.ingested"
 68type = "eql"
 69
 70query = '''
 71network where event.action == "connection_accepted" and
 72  process.name in ("ollama", "ollama.exe") and
 73  destination.port == 11434 and
 74  source.ip != null and source.ip != "0.0.0.0" and
 75  not cidrmatch(source.ip, 
 76    "10.0.0.0/8", 
 77    "127.0.0.0/8", 
 78    "169.254.0.0/16", 
 79    "172.16.0.0/12", 
 80    "192.168.0.0/16",
 81    "100.64.0.0/10",
 82    "::1",
 83    "fe80::/10",
 84    "fc00::/7",
 85    "ff00::/8"
 86  )
 87'''
 88
 89
 90[[rule.threat]]
 91framework = "MITRE ATT&CK"
 92[[rule.threat.technique]]
 93id = "T1190"
 94name = "Exploit Public-Facing Application"
 95reference = "https://attack.mitre.org/techniques/T1190/"
 96
 97
 98[rule.threat.tactic]
 99id = "TA0001"
100name = "Initial Access"
101reference = "https://attack.mitre.org/tactics/TA0001/"

Triage and analysis

Investigating Ollama API Accessed from External Network

This rule detects when Ollama accepts connections from external IP addresses. Ollama binds to localhost:11434 by default but can be exposed via OLLAMA_HOST. Since Ollama lacks authentication, exposed instances allow unauthenticated model theft, prompt injection, and resource hijacking.

Possible investigation steps

  • Check the OLLAMA_HOST environment variable to determine if external exposure was intentional.
  • Review the source IP address to identify if it's a known attacker, scanner, or miscategorized internal system.
  • Examine Ollama logs for suspicious API calls to /api/pull, /api/push, or /api/generate.
  • Check ~/.ollama/models/ for unexpected model downloads that may indicate model poisoning.
  • Review network traffic for data exfiltration following the connection.
  • Look for child processes spawned by Ollama that may indicate exploitation.

False positive analysis

  • Internal networks not properly classified in CIDR ranges may trigger false positives.
  • Load balancers or reverse proxies accessing Ollama from external-facing IPs within trusted infrastructure.
  • Legitimate remote access through VPN or authenticated proxy (add proxy IPs to exclusions).

Response and remediation

  • Restrict access immediately by setting OLLAMA_HOST=127.0.0.1:11434 or applying firewall rules.
  • If exploitation is suspected, stop Ollama and audit ~/.ollama/models/ for unauthorized models.
  • Review Ollama and system logs for signs of compromise.
  • Consider running Ollama in a container with network isolation.

References

Related rules

to-top