「チームで使っているOllamaサーバーへのアクセス制限をどこから設定すればいいかわからない」
そんな悩みを抱えるインフラエンジニア・サーバー管理者は多いはずです。この記事では、OllamaをLinuxサーバーで運用する際に必要なセキュリティ設定を体系的に解説します。バインドアドレスの制限からufw・iptablesによるポートフィルタリング、Dockerネットワーク隔離、journaldによるアクセスログ取得、Fail2banによる異常アクセス自動ブロックまで、多層防御の考え方で段階的に強化する手順を網羅します。
この記事のポイント
・OLLAMA_HOST=127.0.0.1:11434をsystemd override.confに設定するだけで外部バインドを即座に防止できる
・ufw allow from 192.168.1.0/24 to any port 11434でLAN内IPのみに絞り込める
・Docker Composeのexpose+internal networkでホストの11434公開を不要にできる
・Fail2banのOllama用filterとjailを組み合わせて過剰リクエストIPを自動ブロックできる
でも安心してください。プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
Ollamaをそのまま公開するセキュリティリスクを把握する
Ollamaはデフォルトで0.0.0.0:11434 にバインドします。つまりサーバーに到達できるIPアドレスならば、誰でもOllamaのREST APIを直接呼べる状態になります。認証機構はOllama自身には存在しません。具体的なリスクは3つあります。1つ目は無断利用です。GPU・CPUリソースを第三者に消費されます。2つ目はデータ流出です。社内ドキュメントをプロンプトに含めている場合、外部から推論結果を抜き取られるリスクがあります。3つ目はサーバー過負荷です。大量リクエストを受け続けるとサービス品質が低下します。
機密データを守るためにローカルLLMを選んだにもかかわらず、アクセス制限を忘れてネットワーク境界に晒すのは本末転倒です。社内でOllamaを選ぶ経緯や情シス側の判断基準については 「社内でChatGPTが使えないときの代替手段|機密データを守るローカルLLMという選択肢」 も参考になります。
以降ではネットワーク層・サービス層・コンテナ層の3層でセキュリティを重ねる多層防御の考え方で手順を解説します。
OLLAMA_HOSTで外部バインドを無効化する手順
最も手軽かつ効果が高い設定です。Ollamaのバインドアドレスを制御する環境変数OLLAMA_HOST をローカルホストに限定します。
1. systemdサービスの環境変数を設定する
Ollamaをsystemdサービスとして動かしている場合は、drop-inファイルで設定します。# drop-inファイルを作成 $ sudo systemctl edit ollama
[Service] Environment="OLLAMA_HOST=127.0.0.1:11434"
2. サービスを再起動してバインドアドレスを確認する
$ sudo systemctl daemon-reload $ sudo systemctl restart ollama # バインドアドレスを確認 $ ss -tlnp | grep 11434 LISTEN 0 128 127.0.0.1:11434 0.0.0.0:* users:(("ollama",pid=1234,fd=3,...))
127.0.0.1:11434 になっていれば外部からのアクセスは遮断されています。0.0.0.0 のままの場合は設定が反映されていないので sudo systemctl cat ollama で読み込まれているoverride.confの内容を確認してください。チームメンバーからのアクセスが必要な場合は
OLLAMA_HOST=0.0.0.0:11434 のままにして、後述のufwルールで許可IPを絞るアプローチを取ります。OllamaのインストールとsystemdによるAutostart設定については 「Ubuntu ServerでローカルLLMを構築する方法|Ollamaで機密データを外に出さず業務AIを動かす完全ガイド」 を参照してください。
ufwでOllamaポートのアクセス元IPを制限する手順
OLLAMA_HOSTを0.0.0.0 で動かしてチームに公開しつつ、許可IPだけに絞る方法です。Ubuntuのファイアウォール管理ツールufwを使います。
1. ufwのデフォルト設定を確認する
$ sudo ufw status verbose Status: active To Action From -- ------ ---- 22/tcp ALLOW IN Anywhere
sudo ufw enable を実行してください。順序を逆にするとリモート接続が切断されます。
2. 許可するIPアドレス・サブネットのみポート11434を開ける
# 社内LAN(192.168.1.0/24)からのみ11434を許可 $ sudo ufw allow from 192.168.1.0/24 to any port 11434 proto tcp # 特定の1台のみ許可する場合 $ sudo ufw allow from 192.168.1.50 to any port 11434 proto tcp # 11434への残りの全アクセスをブロック(許可ルールより後に追加すること) $ sudo ufw deny 11434 $ sudo ufw status numbered | grep 11434 [ 2] 11434/tcp ALLOW IN 192.168.1.0/24 [ 5] 11434 DENY IN Anywhere
3. 設定を疎通テストで確認する
# 許可されていないIPからの疎通テスト(別ホスト or VPN外から) $ curl --connect-timeout 5 http://サーバーIP:11434/api/tags curl: (7) Failed to connect to サーバーIP port 11434: Connection refused # 許可されているLAN内IPからの疎通テスト $ curl -s http://サーバーIP:11434/api/tags | python3 -c "import sys,json; d=json.load(sys.stdin); print(d['models'][0]['name'])" llama3.3:70b-instruct-q4_0
DockerネットワークでOllamaを内部コンテナ専用に隔離する手順
OllamaをDockerコンテナで動かしている場合は、ネットワーク隔離でホストのポート公開そのものを不要にします。ufwと組み合わせるより根本的な対策です。1. ポートをpublishせずinternalネットワークに置く
Docker Composeのports: "11434:11434" を書くとDockerがホストのポートを開きます。同一Compose内で完結する構成なら ports を書かず expose だけにすることで、ホストには11434が開かなくなります。
# compose.yml(ポートを外部に公開しない隔離設定) services: ollama: image: ollama/ollama:latest expose: - "11434" # 同一ネットワーク内のみ有効(ホストには開かない) networks: - internal_net restart: unless-stopped app: image: myapp:latest environment: - OLLAMA_BASE_URL=http://ollama:11434 networks: - internal_net ports: - "8080:8080" # アプリのみホストに公開 networks: internal_net: driver: bridge
expose はコンテナ間のみ有効で、ホストには11434が開きません。ports との違いを理解しておくことが重要です。
2. ホストのポートが開いていないことを確認する
# ホスト上で11434が開いていないことを確認 $ ss -tlnp | grep 11434 (出力なし) # コンテナ間では疎通できることを確認 $ docker exec app curl -s http://ollama:11434/api/tags | python3 -c \ "import sys,json; d=json.load(sys.stdin); print(d['models'][0]['name'])" llama3.3:70b-instruct-q4_0
3. Dockerのiptablesがufwをバイパスするケースに注意する
ports: "11434:11434" を残したままufwで11434をDENYにしても、DockerがiptablesのFORWARDチェーンに直接ルールを書き込むため、ufwのルールより先に評価されます。Dockerコンテナで動かす場合は、ports を書かない方式(上記)を優先してください。どうしても ports が必要な場合はufwの DOCKER-USER チェーンにルールを追加する方法を検討してください。
journaldとrsyslogでOllamaのアクセスをログに残す手順
どのIPから何時にAPIが呼ばれたかを記録します。Ollama自身はアクセスログを出力しないため、journaldのサービスログを活用します。1. OllamaのjournaldログにAPIリクエストが記録されているか確認する
$ sudo journalctl -u ollama -f --no-pager | grep -E "POST|GET" Sep 13 10:23:14 server ollama[1234]: time="2026-09-13T10:23:14+09:00" level=info msg="request" method=POST path=/api/chat Sep 13 10:23:22 server ollama[1234]: time="2026-09-13T10:23:22+09:00" level=info msg="request" method=POST path=/api/generate
2. rsyslogでログをファイルに転送する
# rsyslog設定ファイルを作成 $ sudo tee /etc/rsyslog.d/50-ollama.conf << 'EOF' :programname, isequal, "ollama" /var/log/ollama/access.log & stop EOF $ sudo mkdir -p /var/log/ollama $ sudo chmod 755 /var/log/ollama $ sudo systemctl restart rsyslog # 動作確認(Ollamaに1リクエスト送ってから確認) $ tail -5 /var/log/ollama/access.log Sep 13 10:25:01 server ollama[1234]: time="..." level=info msg="request" method=POST path=/api/generate
3. ログローテーションを設定する
$ sudo tee /etc/logrotate.d/ollama << 'EOF' /var/log/ollama/access.log { daily rotate 30 compress missingok notifempty postrotate systemctl reload rsyslog endscript } EOF
Fail2banでOllamaへの過剰アクセスを自動ブロックする手順
Fail2banは不審なログパターンを検知して自動的にiptablesブロックを掛けるツールです。Ollamaへの大量リクエストを送ってきたIPを一定時間自動でブロックします。1. Fail2banをインストールして有効化する
$ sudo apt update && sudo apt install -y fail2ban $ sudo systemctl enable --now fail2ban $ sudo fail2ban-client status Status |- Number of jail: 1 `- Jail list: sshd
2. Ollama用のフィルター定義ファイルを作成する
$ sudo tee /etc/fail2ban/filter.d/ollama.conf << 'EOF' [Definition] failregex = ^.*msg="request" method=POST path=/api/generate.*$ ^.*msg="request" method=POST path=/api/chat.*$ ignoreregex = datepattern = {^LN-BEG}time="%%Y-%%m-%%dT%%H:%%M:%%S EOF
3. Ollama用のjailを設定して有効化する
$ sudo tee /etc/fail2ban/jail.d/ollama.conf << 'EOF' [ollama] enabled = true filter = ollama logpath = /var/log/ollama/access.log maxretry = 100 findtime = 60 bantime = 3600 port = 11434 action = iptables-multiport[name=ollama, port="11434", protocol=tcp] EOF $ sudo systemctl restart fail2ban # jailが有効になったか確認 $ sudo fail2ban-client status ollama Status for the jail: ollama |- Filter | |- Currently failed: 0 | |- Total failed: 0 `- Actions |- Currently banned: 0 `- Banned IP list:
maxretry=30 でも十分です。モデルの種類によってリクエスト頻度の特性も異なります。大きいモデルは1リクエストが長いのでmaxretryの到達が遅く、軽量モデルは速いのでブロックされやすくなります。モデルの特性については 「ローカルLLMのモデルを比較する方法|Llama3.3・Mistral・Gemma・Phi-4をUbuntuで使い分けるポイント」 が参考になります。
セキュリティ設定のよくあるミスと対処法
1. ufw有効化の順序ミスでSSHが切断される
ufwを有効化する前にsudo ufw allow 22/tcp でSSHを許可していないと、リモート接続が切断されます。必ずSSH許可を先に追加してから ufw enable を実行してください。クラウドVMの場合はコンソールアクセスで復旧できますが、手間がかかります。作業前に確認する習慣をつけてください。
2. DockerのportsがufwのDENYルールをバイパスする
ports: "11434:11434" と書くとDockerが直接iptablesのNATテーブルにルールを書き込みます。ufwが管理するINPUTチェーンより先に評価されるため、ufwで11434をDENYにしても有効にならないケースがあります。Dockerコンテナで動かす場合は前述の expose +内部ネットワーク方式を使うのが確実です。
3. OLLAMA_HOSTをDockerコンテナ内で127.0.0.1に設定してしまう
DockerコンテナのenvironmentにOLLAMA_HOST=127.0.0.1:11434 を設定すると、コンテナ内のループバックアドレスに限定されます。他のコンテナからHTTP://ollama:11434 でアクセスしようとしてもConnection refusedになります。Dockerコンテナ版では OLLAMA_HOST を設定せず(デフォルト 0.0.0.0:11434)、ネットワーク隔離でアクセス制限を実装するのが正解です。
4. Fail2banのフィルターregexが一致しない
Ollamaのバージョンアップでログフォーマットが変わると、フィルターが機能しなくなります。sudo fail2ban-client set ollama unbanip 0.0.0.0 でテストし、sudo fail2ban-regex /var/log/ollama/access.log /etc/fail2ban/filter.d/ollama.conf でマッチ件数を確認してください。
まとめ
OllamaのLinuxサーバーセキュリティ強化手順をまとめます。| 対策レイヤー | 設定内容 | 効果 |
|---|---|---|
| サービス層 | OLLAMA_HOST=127.0.0.1:11434(override.conf) | 外部IPからのAPI直接アクセスを遮断 |
| ネットワーク層 | ufw allow from 192.168.1.0/24 to any port 11434 | 許可サブネット以外のアクセスをブロック |
| コンテナ層 | expose + internal network(portsなし) | ホストポートを開かずコンテナ間のみ疎通 |
| ログ層 | rsyslog → /var/log/ollama/access.log | 不審なアクセスの事後追跡が可能 |
| 自動ブロック層 | fail2ban-client status ollama(maxretry=100/60s) | 過剰リクエストIPを1時間ブロック |
設定は1度入れてしまえばほぼメンテナンスフリーで動きます。まず
OLLAMA_HOST=127.0.0.1:11434 だけでも設定しておくことを強く推奨します。
ローカルLLMのセキュア運用を2日間のハンズオンで学ぶ
「ufw・Docker隔離・Fail2banを実際のLinux環境で試したい」という方向けに、実機GPU環境で手を動かしながら習得したい方向けに、「ローカルAIマスターセミナー」を開催しています。
少人数(最大8名)ZOOMハンズオン形式で実施しています。
・Ubuntu ServerでローカルLLMを構築する方法|Ollamaで機密データを外に出さず業務AIを動かす完全ガイド
・社内でChatGPTが使えないときの代替手段|機密データを守るローカルLLMという選択肢
・ローカルLLMのモデルを比較する方法|Llama3.3・Mistral・Gemma・Phi-4をUbuntuで使い分けるポイント
3,100名以上が実践した「型」を無料で公開中
プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
その「型」を図解60Pにまとめた入門マニュアルを、完全無料でプレゼントしています。
姓・名・メールの3つだけ/30秒/解除は3秒 / 詳細はこちら
- 前のページへ:OllamaとChromaDBでローカルベクターデータベースを構築する方法|社内ドキュメントの意味検索基盤をLinuxサーバーに設定する手順
- この記事の属するカテゴリ:ローカルLLMへ戻る

無料メルマガで学習を続ける
Linuxの実践スキルをメールで毎週お届け。
登録は30秒、解除もいつでも可。
登録無料・いつでも解除できます