OllamaのセキュリティをLinuxで強化する方法|iptables・Dockerネットワーク隔離・Fail2banでローカルLLMサーバーを保護する手順

宮崎智広 この記事の監修:宮崎智広(Linux実務・教育歴20年以上・受講者3,100名超)
HOMELinux技術 リナックスマスター.JP(Linuxマスター.JP)ローカルLLM > OllamaのセキュリティをLinuxで強化する方法|iptables・Dockerネットワーク隔離・Fail2banでローカルLLMサーバーを保護する手順
「OllamaをUbuntuに立てたが、デフォルトの11434ポートが外部からアクセスできてしまう」
「チームで使っている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のセキュリティをLinuxで強化する方法|iptables・Dockerネットワーク隔離・Fail2banでローカルLLMサーバーを保護する手順

「このままじゃマズい」と感じていませんか?
参考書を開く気力もない、同年代に取り残される不安——
でも安心してください。プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
姓・名・メールの3つだけ/30秒/解除は3秒 / 詳細はこちら

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

ufwが有効でSSH(22)が許可されていることを確認します。ufwが無効の場合はSSH許可ルールを先に追加してから 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

ufwはルール番号の昇順で評価します。許可ルール(ALLOW)を先に追加してから拒否ルール(DENY)を追加することで、LAN内のみ通してそれ以外を落とす構成になります。

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

許可IPからは応答があり、それ以外は弾かれていることを確認できます。

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

ホストに出力がなく、コンテナ間のみで通信できていることが確認できます。外部からのスキャンにも11434が見えなくなります。

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

30日分のログが自動的に圧縮・ローテーションされます。インシデント発生時に遡って調査できる体制が整います。

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

Ollamaのjournaldログフォーマットに合わせてregexを定義します。ログフォーマットが変わった場合はこのファイルだけ修正すれば済みます。

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:

60秒間に100リクエスト以上あったIPを1時間ブロックします。値はサーバーの利用実態に合わせて調整してください。個人利用や小規模チームなら 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時間ブロック
Ollamaはデフォルトで認証なしのAPIサーバーとして動く設計です。社内LAN内でしか使わない場合でも、誰かがポートフォワーディングを設定して意図せず外部露出させてしまうケースがあります。OLLAMA_HOSTの制限・ufw・Dockerネットワーク隔離・Fail2banを組み合わせた多層防御で「気づいたときには手遅れ」を防ぐのが現実的な運用です。

設定は1度入れてしまえばほぼメンテナンスフリーで動きます。まず OLLAMA_HOST=127.0.0.1:11434 だけでも設定しておくことを強く推奨します。

ローカルLLMのセキュア運用を2日間のハンズオンで学ぶ

「ufw・Docker隔離・Fail2banを実際のLinux環境で試したい」という方向けに、実機GPU環境で手を動かしながら習得したい方向けに、「ローカルAIマスターセミナー」を開催しています。
少人数(最大8名)ZOOMハンズオン形式で実施しています。

>> ローカルAIマスターセミナーの詳細を確認する
ローカルLLMの構築・運用に関する関連記事もあわせて参考にしてください。

Ubuntu ServerでローカルLLMを構築する方法|Ollamaで機密データを外に出さず業務AIを動かす完全ガイド
社内でChatGPTが使えないときの代替手段|機密データを守るローカルLLMという選択肢
ローカルLLMのモデルを比較する方法|Llama3.3・Mistral・Gemma・Phi-4をUbuntuで使い分けるポイント

無料メルマガで学習を続ける

Linuxの実践スキルをメールで毎週お届け。
登録は30秒、解除もいつでも可。

登録無料・いつでも解除できます

暗記不要・1時間後にはサーバーが動く

3,100名以上が実践した「型」を無料で公開中

プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
その「型」を図解60Pにまとめた入門マニュアルを、完全無料でプレゼントしています。

姓・名・メールの3つだけ/30秒/解除は3秒 / 詳細はこちら

Linux無料マニュアル(図解60P) 名前とメールで30秒登録
宮崎 智広

この記事を書いた人

宮崎 智広(みやざき ともひろ)

株式会社イーネットマーキュリー代表。現役のLinuxサーバー管理者として20年以上の実務経験を持ち、これまでに累計3,100名以上のエンジニアを指導してきたLinux教育のプロフェッショナル。「現場で本当に使える技術」を体系的に伝えることをモットーに、実践型のLinuxセミナーの開催や無料マニュアルの配布を通じてLinux人材の育成に取り組んでいる。

趣味は、キャンプにカメラ、トラウト釣り。好きな食べ物は、ラーメンにお酒。休肝日が作れない、酒量を減らせないのが悩み。最近、ドラマ「フライトエンジェル」を観て涙腺が崩壊しました。