Securing Your Ollama Server: What Happens When AI Gets Exposed to the Internet

In 2025, Cisco researchers published a study finding thousands of Ollama instances publicly accessible on the internet with no authentication, serving models to anyone who sent a request. If you’re running an Ollama server – for development, AI-assisted pentesting, or a local AI stack – understanding these risks and hardening it isn’t optional.

How Ollama Exposes Itself by Default

By default on Linux and Mac, Ollama binds to 0.0.0.0:11434. On a machine with a public IP, this means the Ollama API is accessible from anywhere. The real problems occur when: the machine has a public IP, UFW/iptables isn’t configured, or the machine is inside a corporate network reachable by other employees.

# Check if Ollama is listening on a public interface
ss -tlnp | grep 11434
# Should show 127.0.0.1:11434 (safe)
# Bad: 0.0.0.0:11434 (exposed on all interfaces)

# Test from an external machine
curl http://YOUR_IP:11434/api/tags
# If this returns model data, you're exposed

What an Attacker Can Do with an Exposed API

Model Extraction

# Attacker lists your models
curl http://TARGET:11434/api/tags

# Downloads model blobs (costs you bandwidth, may expose fine-tuned models)

Resource Hijacking

Inference is computationally expensive. An attacker hammering your exposed Ollama instance with requests causes your CPU/GPU to run at 100% – effectively a resource exhaustion DoS attack.

Loading Remote Models

On some configurations, an attacker may be able to load a model of their choosing onto your machine – potentially one containing backdoored weights.

Shodan Discovery

Finding exposed Ollama instances is trivial for anyone with a Shodan account. The query port:11434 "ollama" returns results in seconds. Check if your own IP appears.

Hardening: Bind to Localhost Only

# Edit the systemd service file
sudo systemctl edit ollama

# Add in the override file:
[Service]
Environment="OLLAMA_HOST=127.0.0.1"

# Restart
sudo systemctl restart ollama

# Verify
ss -tlnp | grep 11434
# Should now show 127.0.0.1:11434

Firewall Rules

# UFW
sudo ufw deny 11434
sudo ufw allow from 192.168.0.0/24 to any port 11434  # Allow local network only
sudo ufw enable

# iptables
sudo iptables -A INPUT -p tcp --dport 11434 -j DROP
sudo iptables -I INPUT -p tcp --dport 11434 -s 127.0.0.1 -j ACCEPT

Reverse Proxy with Authentication

If you genuinely need Ollama accessible from other machines, put it behind Nginx with authentication:

server {
    listen 443 ssl;
    server_name your-domain.com;
    
    ssl_certificate /etc/letsencrypt/live/your-domain.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/your-domain.com/privkey.pem;
    
    auth_basic "Ollama API";
    auth_basic_user_file /etc/nginx/.htpasswd;
    
    location / {
        proxy_pass http://127.0.0.1:11434;
        proxy_set_header Host $host;
    }
}

# Create credentials
htpasswd -c /etc/nginx/.htpasswd your_username

Docker Network Isolation

# Run Ollama with no port exposure to host
docker run -d 
  --name ollama 
  --network internal_net 
  --gpus all 
  ollama/ollama

# Only containers on internal_net can reach Ollama
# Nothing external can connect directly

Detecting Compromise

# Check Ollama access logs for external IPs
journalctl -u ollama | grep -v "127.0.0.1"
# Any non-localhost IPs = external access happened

# Check for unexpected models
curl http://localhost:11434/api/tags
# Any models you didn't pull?

# Monitor resource usage
htop
# Sustained high CPU/GPU when you're not running inference = suspicious

Conclusion

The fix is simple: ss -tlnp | grep 11434. If it’s not on 127.0.0.1, fix it. Then add a firewall rule as belt-and-suspenders. The compute required to run these models is too valuable to donate to strangers, and the models themselves may contain sensitive fine-tuning data you don’t want extracted.