←back to thread

Finding thousands of exposed Ollama instances using Shodan

(blogs.cisco.com)
166 points rldjbpin | 2 comments | 03 Sep 25 08:18 UTC | HN request time: 0.429s | source
Show context
alexandru_m ◴[03 Sep 25 10:25 UTC] No.45114142[source]▶
Apparently, protecting the API is not planned: https://github.com/ollama/ollama/issues/849

For my own purposes I either restrict ollama's ports in the firewall, or I put some proxy in front of it that blocks access of some header with some predefined api key is not present. Kind of clunky, but it works.

replies(5): >>45114147 #>>45114943 #>>45114992 #>>45117832 #>>45120566 #
omneity ◴[03 Sep 25 12:33 UTC] No.45114943[source]▶
Yeah it’s a pretty crazy decision to be honest. Flashbacks to MongoDB and ElasticSearch’s early days.

Fortunately it’s an easy fix. Just front it with nginx or caddy and expect a bearer token (that would be your api key)

replies(2): >>45118733 #>>45120587 #
TomK32 ◴[03 Sep 25 18:03 UTC] No.45118733[source]▶
Early MongoDB adapter here who still likes it. If your internal services are accessible from outside you are doing it wrong. Neither MongoDB nor ES or ollama are services that my applications would access through a public IP and whenever a dev asks me for access to the DB from the comfort of their home office I tell them what VPN to log into.

Even if those services had some access protection, I simply must assume that the service has some security leak that allows unauthorized access and the first line of defense against that is not having it on the public internet.

replies(3): >>45118847 #>>45119171 #>>45119450 #
1. cortesoft ◴[03 Sep 25 18:15 UTC] No.45118847[source]▶
On the flipside, you can also argue that if you are relying on network access to protect your internal services, you are doing it wrong. If the only thing you need to take over a service is access to its internal network, you are setting yourself up to be owned.
replies(1): >>45124884 #
2. dns_snek ◴[04 Sep 25 08:11 UTC] No.45124884[source]▶
Yes but nobody is stopping you from adding your own proxy which enforces any type of authentication you like, and in my opinion that's the more sensible approach here anyway.

I don't think it's sensible to expect every project like Ollama to ship their own half-broken authentication and especially anything resembling a "zero trust" implementation. You can easily front Ollama with a reverse proxy which does those things if you'd like. Each component should do one thing well.

I trust Nginx to verify client certificates correctly so I can be confident that only traffic from trusted users is able to reach whatever insecure POS is hiding behind it.