TCP Wrapper をいまだに使っている組織に感じる懸念 – hosts.allow / hosts.deny を現在のアクセス制御として見る

TCP Wrapper という仕組みがありました。/etc/hosts.allow と /etc/hosts.deny を使用し、接続元 IP アドレスやサービス名を条件として、接続を許可または拒否する仕組みです。

現在では、主要な Linux 環境やミドルウェアで TCP Wrapper を前提にした構成は一般的ではなくなっています。接続元 IP アドレス、宛先ポート、プロトコルといった L3・L4 の制御はホストファイアウォールへ寄せ、サービス固有の認証や認可はミドルウェアやアプリケーションで扱う設計が読みやすくなっています。

では、2026 年現在も TCP Wrapper を使い続けている組織をどう評価するべきでしょうか。単に古い技術を使っているという理由だけで否定する必要はありません。TCP Wrapper には、当時として明確な役割がありました。しかし、その制約を理解せず、現在も主要なアクセス制御として扱っているのであれば、かなり危うい状態です。

TCP Wrapper は何を共通化した仕組みだったのか

TCP Wrapper は、ネットワーク機器のファイアウォールのように通信経路上ですべてのパケットを制御する仕組みではありません。対応するサービスの前段、またはサービス内部のライブラリーとして動作し、接続元情報をもとに接続可否を判断します。

位置付けとしては、OS が TCP 接続を受け付けた後、ミドルウェア本体へ処理が渡る前に、tcpd または libwrap が hosts.allow と hosts.deny を参照する仕組みです。各ミドルウェアが個別に持っていた接続元 IP アドレスによる入口制御を、共通の設定ファイルへ外出ししたものと考えると分かりやすくなります。

TCP Wrapper が担当するのは、基本的には「この接続元から、このサービスへの接続を許可するか」という判断です。接続後の認証、ユーザーごとの権限、操作可能なリソース、プロトコル上の認可は、引き続きミドルウェア自身が担当します。つまり TCP Wrapper は、アクセス制御全体を外部化した仕組みではなく、接続受付時の粗い制御を共通化した仕組みでした。

古いから駄目なのではない

技術を評価するときに、「古いから駄目」「新しいから優れている」とだけ判断するのは雑です。TCP Wrapper は、その時代の要求に対しては合理的な仕組みでした。複数のサービスに対して接続元 IP アドレスによる制御を共通の設定ファイルで管理できる点には、明確な利点がありました。

個々のサービスに同じような ACL を記述するより、ポリシーを集約できるため、当時としては運用上の意味もありました。古い OS、専用アプライアンス、更新が難しい組み込み製品などでは、現在も設定が残っていること自体はあり得ます。

問題は、TCP Wrapper が存在することではありません。現在の環境で使い続ける合理性があるか、対象サービスが本当に対応しているか、実際に制御が有効であることを検証しているかです。ここを確認せず、設定ファイルがあることだけを根拠に「接続元制限はできている」と考えるなら、そこに強い懸念があります。

現在はファイアウォールが担当する領域である

接続元 IP アドレス、宛先ポート、プロトコルといった条件によるアクセス制御は、現在ではホストファイアウォールで扱う方が自然です。Linux では nftables や firewalld がその役割を担います。Ubuntu のセキュリティ文書でも、Linux の Netfilter におけるパケットフィルターとして iptables と nftables が整理され、nftables が iptables の後継として説明されています。

現代的な責務分担は、次のように整理できます。

制御対象	主な実装先	理由
接続元 IP アドレス	nftables、firewalld	ネットワーク層で一貫して判定できるため
宛先ポート、プロトコル	nftables、firewalld	サービス実装に依存せず入口で制御できるため
プロセス単位の通信制約	systemd、コンテナ実行基盤	プロセスやワークロード単位の境界を扱うため
SSH ユーザーと接続元の組み合わせ	sshd	SSH の認証条件として扱う必要があるため
HTTP パスや証明書による制御	Web サーバー、リバースプロキシー	HTTP の意味を理解する層で判定するため
ユーザー権限や操作権限	ミドルウェア、アプリケーション	認証後の主体と操作内容を扱うため

ネットワーク情報だけで判断できる制御はファイアウォールへ配置し、プロトコルやユーザーの意味を理解する必要がある制御はミドルウェア側へ配置します。この方が、各層の責任が明確になります。

TCP Wrapper を使い続けることの問題

TCP Wrapper の最大の問題は、すべての通信に対して一律に効く仕組みではないことです。対象のサービスが tcpd 経由で起動されるか、libwrap に対応している必要があります。そのため、同じホスト上でも、あるサービスには設定が有効で、別のサービスにはまったく効かないという状態が起こります。

さらに厄介なのは、設定の存在と実効性が一致しないことです。/etc/hosts.allow や /etc/hosts.deny に設定が存在していても、それだけではアクセス制御が有効であるとは判断できません。対象サービスが TCP Wrapper に対応しているか、現在のバイナリーが libwrap を参照しているか、起動方式が変更されていないかを確認する必要があります。

設定ファイルは残っているが誰も参照していない、という状態はセキュリティ設定として危険です。管理者が「制御している」と思っている一方で、実際には通信が制限されていない可能性があるためです。

アクセス制御の正本が分からなくなる点も問題です。nftables にも制御があり、hosts.allow にも制御があり、ミドルウェアにも ACL がある状態では、どれが正しい設定なのか、どこを変更すべきなのか、どの層で拒否されたのかを説明しにくくなります。アクセス制御は、多く配置すれば強くなるわけではありません。各制御点の目的と責任分界が定義されていなければ、むしろ運用の確実性を下げます。

OS 更改で防御だけが消える可能性がある

現在の主要な Linux 環境では、TCP Wrapper を前提としない方向へ移行してきました。Arch Linux は 2011 年に tcp_wrappers サポートを落とす方針を示し、その理由として、上流の更新停止と、各アプリケーションにおける libwrap 対応の一貫性のなさを挙げています。Fedora でも TCP Wrapper の非推奨化が整理され、接続フィルタリングはネットワークレベルのファイアウォール、またはアプリケーション固有の制御で扱うべきだと説明されています。

この流れを考えると、古い環境では動作していた設定が、OS やミドルウェアの更改後に機能しなくなる可能性があります。移行時に必要なのは、設定ファイルをそのままコピーすることではありません。現在の設計意図を確認し、同等の制御を適切な仕組みへ移すことです。

TCP Wrapper の設定だけを残したまま新しい環境へ移行すると、見かけ上は設定が維持されていても、実際の防御だけが消える場合があります。これは単なる互換性の問題ではなく、設計意図を設定ファイルに閉じ込めたまま棚卸ししていないことの問題です。

本当に問題なのは組織の管理状態である

TCP Wrapper が存在すること自体よりも、その状態を組織がどのように管理しているかが重要です。特に懸念が強いのは、現在も有効か確認していない、対象サービスが対応しているか把握していない、ファイアウォールとの責任分界が決まっていない、設定変更後の疎通試験を実施していない、OS 更改時に設定の有効性を確認していない、といった状態です。

このような場合、問題は TCP Wrapper という技術ではありません。構成の実効性を検証せず、過去の設計を形式的に維持している組織運用に問題があります。TCP Wrapper は、その問題を発見するための観測点に過ぎません。

状態	評価
設定ファイルだけが残っている	構成棚卸しが不足している可能性が高い
有効かどうか把握していない	強い懸念がある
レガシー製品で補助的に利用している	制約を理解していれば許容できる場合がある
外側のファイアウォールでも制御している	リスクは限定されるが、責任分界の確認は必要
TCP Wrapper を唯一のアクセス制御としている	現在の設計として不適切
移行計画を持って維持している	暫定措置として理解できる
新規環境でも積極的に採用している	選択理由を説明するのは難しい

既存環境で確認すべきこと

既存環境で TCP Wrapper を発見した場合、まず対象サービスが本当に TCP Wrapper に対応しているかを確認します。次に、現在のバイナリーが libwrap を参照しているか、hosts.allow と hosts.deny が実際に評価されているかを確認します。

その上で、ホストファイアウォールに同等の制御があるか、アクセス制御の正本はどこか、設定変更後に許可と拒否の試験を行っているか、OS やミドルウェアはサポート期間内か、廃止または移行の計画があるかを見ます。これらに明確に回答できるのであれば、少なくとも管理された状態です。

反対に、回答できず、設定ファイルがあることだけを根拠に安全だと考えている場合は危険です。特に、TCP Wrapper を唯一の接続元制限として扱っている場合は、現在のホストファイアウォールやミドルウェア設定へ設計意図を移し、試験できる状態にする必要があります。

まとめ

TCP Wrapper は、古いから問題なのではありません。当時は、複数のミドルウェアに共通する接続元制御を外部化する、合理的な仕組みでした。

しかし現在では、単純な L3・L4 アクセス制御はホストファイアウォールへ移し、サービス固有の制御は各ミドルウェアへ配置する方が、責任分界、適用範囲、検証可能性、保守性の面で優れています。

現在も TCP Wrapper を主要なセキュリティ制御として使い続けている組織に懸念があるのは、古い技術を使っているからではありません。実際に制御が有効か分かりにくく、サービスごとに適用範囲が異なり、ファイアウォールやミドルウェアとの責任分界が曖昧になりやすく、OS 更改時に無効化されても気付きにくいからです。

TCP Wrapper を発見した際に確認すべきなのは、古い技術が残っているという事実ではありません。その制御が現在も有効なのか、どの層の責任として管理されているのか、どの仕組みへ移行する計画があるのかです。それが説明できない場合、TCP Wrapper は単なるレガシー設定ではなく、組織の構成管理や設計統制の弱さを示す兆候になります。

参考資料

• Arch Linux – Dropping tcp_wrappers support
• Fedora Project Wiki – Deprecate TCP wrappers
• Ubuntu security documentation – Firewall
• Red Hat Documentation – Getting started with nftables
• firewalld documentation

関連記事