Skip to main content
一月の2026、SentinelLABSとCensysは、およそ175,000台ものインターネットに公開されているOllamaホストが約130カ国に存在することを示す調査結果を公表した。この情報の主な出典はSentinelOneの記事であり、同様の数値はThe Hacker NewsやSecurityWeekでも紹介されている。調査者らによれば、公開されているホストの半数近くがツール呼び出し機能を備えていることが判明した。これは単なるチャット機能ではなく、コード実行が可能であることを意味する。 これはOllama自体の脆弱性ではない。多くのユーザーが変更しないデフォルト設定に過ぎないのだ。

​
問題の発生メカニズム

Ollamaはデフォルトで127.0.0.1:11434ポートをリスニングするが、これはループバック専用であり外部からはアクセスできない。ネットワーク内の別デバイスやスマートフォン、別のコンピュータ、あるいは外部で稼働するコーディングエージェントからアクセスさせるには以下の対処法が一般的だ。
この環境変数を設定することでバインドアドレスがループバックから全インターフェースへと変更される。ルーターのポートフォワーディングやクラウドVMのパブリックIP、あるいは一時的なファイアウォール設定と組み合わせれば、11434ポートはローカルネットワーク内だけでなくインターネット全体からもアクセス可能になる。デフォルトでは認証機能が備わっていないため、該当ポートを発見した者は誰でも直接APIを呼び出せる。モデル一覧の取得や推論実行が可能であり、ツール呼び出し機能を備えたホストであればコード実行も引き起こせる可能性がある。 これこそがShodanやCensysといった大規模スキャンツールが探し出そうとするパターンだ。標的型攻撃は不要で、単なるポートスキャンだけで発見可能なのである。
これはOllamaの欠陥ではなく設定上の問題だ。バインドアドレスが全インターフェースに設定され、ポートが開放またはフォワーディングされ、認証機能が備わっていないという状況はOllamaに限らずあらゆるローカルモデルサーバーにも当てはまる。

​
なぜ「認証機能を追加するだけ」では不十分なのか

Putting a reverse proxy with basic auth in front of 0.0.0.0:11434 helps, but it doesn’t remove the underlying condition: the port is still listening, and something in your network path still has to be reachable from the outside for that proxy to work. Every inbound-facing component — the proxy, the firewall rule, the port forward, the TLS cert — is one more thing that has to stay correctly configured forever. Misconfigure any of them once, or roll one back during debugging, and you’re back to an open port.

​
別の選択肢としては、受信用ポートを全く用意しないという方法もある

Tokiosでは別のアプローチを採用している。モデルと並行して実行される tokios-connector は受信トラフィックを一切受け付けない。代わりに単一の送信用 wss:// 接続を https://api.tokios.com へ確立する。これはブラウザがウェブページを読み込む際に用いる方向と同じだ。Tokiosはその接続経由でリクエストをルーティングする。転送すべきポートもなければ、開放すべきファイアウォールルールもなく、0.0.0.0 にバインドされる要素も存在しない。 モデルに到達するすべてのリクエストには、スコープ付きの sk-tok-… APIキーが含まれていなければならない。Tokiosはそのキーを確認した上でようやくトンネル経由でコネクターへリクエストを転送する。このキーは特定のデプロイやモデル名パターンに紐付けて設定可能で、ローテーションや無効化、削除も可能だ。無効化されたキーは即座に認証機能を失う。 この仕組みの意味と限界を正確に述べると、送信専用のコネクターにはそもそも受信用のインターフェースが存在しない。これは接続モデル上の構造的違いであり、セキュリティ上の保証を意味するものではない。Tokiosは、本サービスを通じて公開されたモデルが悪用される可能性を完全に排除すると主張しているわけではない。APIキーの漏洩は他の場所でのパスワード漏洩と同様に依然としてリスクとなる。ここでの主眼はより機械的かつ限定的な点にある。つまりスキャナーが発見できるような受信用ポートがそもそも存在しないのだ。
現在 OLLAMA_HOST=0.0.0.0 を用いてOllamaをリモートアクセス用に運用している場合、175,000 ホスト番号の背後にあるのがまさにこの仕組みだ。モデルを再び 127.0.0.1 上に配置し、送信専用コネクター経由でアクセスするように切り替えてほしい。切り替え方法は Ollamaリモートアクセス を参照されたい。

​
実際の動作イメージ

1

デフォルト通りループバック上でOllamaを実行する

No OLLAMA_HOST override, no bind-to-all-interfaces flag.
2

コネクターをペアリングする

tokios-connector が https://api.tokios.com へ接続を試み、コンソール上で承認を求める。この手順によってマシンやルーター上にポートが開かれることは一切ない
3

どこからでもモデルを呼び出せる

有効かつスコープ付きの sk-tok-… キーを提示しなければ、リクエストはコネクターに到達できない。
キャリアグレードNAT（CGNAT）を利用しているユーザーもまさに同じ状況に直面します。この場合、ポートフォワーディングは推奨されないどころか、ルーター側に転送先となるパブリックIPが存在しないため構造的に不可能です。なぜそうなるのか、またこのアウトバウンド専用接続がどのように問題を回避するのかについては、CGNAT環境下でローカルLLMを提供する方法をご覧ください。

​
要点まとめ

The 175,000-host figure is a scan result, not a prediction about any specific server. But the pattern behind it is simple and worth remembering regardless of the exact count: inbound reachability plus no auth is the whole problem. Removing the inbound part removes an entire category of “how did they even find this” incidents, because there’s nothing listening to find.

クイックスタート

コネクターをペアリングし、モデルを登録した上で最初のリクエストを送信しましょう。

Ollamaのリモートアクセス設定

既に外部公開済みのOllamaインスタンスをループバック接続に戻し、代わりにTokios経由でアクセスする方法です。

Tokiosがリクエストをルーティングする仕組み

アウトバウンド専用アーキテクチャの全体像を確認できます。