TCPラッパーとxinetd
社内でxinetdについて話題になったので、復習を兼ねて簡単にTCPラッパーとxinetdについて調べてみました。参考にしたのは、Red Hat Enterprise Linux 4 ドキュメントですが、Red Hat系のLinuxであれば同じと思っていいはずです。
全体図
ネットワークサービスへのアクセス制御は、この図に描かれているように、Firewall → TCP Wrappers (→ xinetd)の順で接続要求を受理するかどうかの制御を行います。
その図を見るだけで、おおよそのアクセス制御の流れを把握することができると思います。
TCP Wrapper
TCPラッパーパッケージはデフォルトでインストールされており、アクセス制御はホストアクセスファイル(/etc/hosts.allowおよび/etc/hosts.deny)に記述します。
よくこんな感じで記述したりします。
# cat /etc/hosts.allow
sshd: 192.168.1. 192.168.2. : allow
# cat /etc/hosts.deny
ALL:ALL@ALL
上記の例では、192.168.1. および 192.168.2. のネットワークからのみsshでの接続を許可しています。
TCPラッパーによるアクセス制御は、ホストアクセスファイルを元に判定します。その後、syslogdがログを書き込みます。
TCPラッパーの利点は以下の通り。普段、あまり意識しないぐらい当たり前のことをやってくれてます。
- クライアントホストとラップしたネットワークサービス間の透視度
- 複数プロトコルの中央管理
ちなみにホストアクセスファイルの設定内容は、もっと色々なことができるようなので、色々な設定で試してみるとよさそうです。
xinetd
xinetdデーモンの役割としては、
xinetd デーモンは、 FTP、 IMAP、Telnetを含む人気のあるネットワークサービスのサブセットへのアクセスを制御するTCPラップしたスーパーサービスです。これは、アクセス制御、強化ロギング、結合、方向転換、リソース活用 制御などの為にサービス特有の設定オプションを提供します。クライアントホストが、xinetdで制御されたネットワークサービスへ接続を試みると、スーパーサーバーは要求を受けて、すべてのTCP ラッパーアクセス制御規則をチェックします。アクセスが許可される場合、xinetdはそのサービス用の自身のアクセス規則の元で接続が許可されることを確認し、サービスがその割り当て以上のリソースを消費していないことや、定義された規則に違反していないことも確認します。その後、要求されたサービスのインスタンスを開始し、その接続の制御を通過させます。接続が確立されると、xinetdはこれ以上、クライアントホストとサーバー間の通信には干渉しません。
ということになります。
以上から分かることとしては、
- xinetdがアクセス許可をされた場合に各サービスのインスタンスを開始するので、デーモンのように無駄にリソースを消費することがない
- xinetd経由で各サービスへ接続するので、頻繁に接続要求が行われるサービスでは使うべきではない(例: httpやsmtpなど)
- xinetdでもアクセス制限、ロギング、リソース制御などを行うことができる
といった感じです。
sshやftpなどは少なくとも頻繁に接続するような類のサービスではないので、デーモンではなく、xinetdデーモンからサービスのインスタンスを開始させるようにします。
あと、初めて知ったんですが、リソース管理もxinetdでできるみたいです。オプションは詳しく調べて、動作確認を行う必要がありますが、DoS攻撃からの保護を行う1つの方法になりえます。
あとは例としてsshで少し考えてみます。仮にopensshに脆弱性が発見された場合、sshdデーモンを動かしている場合に比べ、xinetd経由にしてるほうが、(xinetdにも脆弱性がなければ)攻撃を受けにくいのではないかなと思います。(脆弱性の内容によってはどちらでも変わらないかもしれませんが)
以上を踏まえてやっぱり頻繁に接続要求のないサービス(ssh, ftpなど)は、xinetd経由でサービス起動させるようにするべきですね、と再確認にいたりました。
