←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.224s | 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. harrall ◴[03 Sep 25 18:49 UTC] No.45119171[source]▶
Tell that to the kids at my high school in 2004 screwing with all the unprotected services across the whole school district-wide network.

Or the worms that scan for vulnerable services and install persistent threats.

If you want to remove the password on a service, that’s your choice. The default should have a password though and then people can decide.

replies(1): >>45124832 #
2. dns_snek ◴[04 Sep 25 08:02 UTC] No.45124832[source]▶
Decide what? Slapping a simple, naive login screen on top of a service that was never designed to fend off attacks from untrusted networks doesn't fix the actual issue, which is the fact that an administrator exercised bad judgement and made it accessible to untrusted networks.