Thirdware Inc. | is it secure enough?

is it secure enough?

１月下旬頃、linux-netメーリングリストに上のようなサブジェクトのメールが投稿されました。「IPマスカレード、ipfwadmによるパケットフィルタリング、tcp wrapperのルールを設定したゲートウェイでメールサーバ、NFS、Webサーバ、FTPサーバなども同時に動かしているが、これでセキュアと言えるだろうか」という質問でした。

何人かからアドバイスがありましたので、取捨選択して紹介したいと思います。いわゆる「オールインワン・サーバ」を運用される方の参考になればと思います。

まず、「何を許すか、何を禁じるか」というポリシーを定めるべきです。ipfwadmのinput、output、forwardの3つのルールを明確に定め、それを設定する必要があります。
ネットワークインタフェースごとに、入ってきてはならないIPアドレスがあります。内部ネットワークのアドレスを起点とするパケットや、自分自身のグローバルアドレスを起点とするパケットが、インターネット側のインタフェースから入ってきてはなりません。これをルールに明記しなさい。
システムのログを毎日点検して、侵入の企てを検出しなさい。必要ならファイアウォールのルールを調整すべきでしょう。
「よい」パスワードを使っているかチェックしなさい。またパスワードを他人に教えるなど、人的な面のセキュリティにも気を配りなさい。
cronジョブで定期的にtripwireによるチェックを実施し、覚えのないファイルの書き換えがあったかどうか調べなさい。
最新のカーネルを、必須のオプションだけを指定してコンパイルして使いなさい。
カーネルモジュールはできるだけ使わない方がいいでしょう。
sendmailよりもqmailを使う方がいいでしょう。
ログ、メールスプールなど、外部からのアクセスで影響を受けるファイル類は、独立したパーティションに置く方がいいでしょう。
メールスプール、FTPのアップロード、ニューススプールなど、外部からのアクセスで作られるファイルがあれば、ディスクのクォータ(quota)制限を考慮しなさい。悪意ある誰かがファイルシステムをパンパンに膨れ上がらせるかもしれないので。
NFS、NISはセキュリティ上の弱点となりかねないので、可能な限り使わない方がいいです。
ファイアウォールとして動かすマシン上に一般ユーザのアカウントは置くべきではありません。メールサーバその他で一般ユーザの情報が必要なら、/etc/passwd以外のところに置く方法を考えなさい。

セキュリティ上の弱点を探すのにsatanが役立つでしょう。次の発言以降、若干の掛け合いになります。

ファイアウォール上で他のサーバは動かさない方がいいでしょう。誰かがたとえばsendmailのホールを悪用してroot権限を手にいれたら、ファイアウォールは意味を失います。ファイアウォールはあくまでその目的のためだけのマシン上で動かすべきです。
(上の意見に対して)現実の制約として、1台でファイアウォールとサーバを動かさなければならないこともあるので、原理原則だけでなく、問題点をもっと具体的に示してほしい。たとえばいったいどのような具体的な問題点がsendmailにあるのか、など。
「安全なファイアウォール」は存在しません。ある種のパケットの通過を禁止したとしても、sendmailを含むプログラムのバグやもっと賢い人の巧妙な手口によって、侵入される可能性がつねにあるからです。ファイアウォールマシンで他のサーバも動かしておくと、当然それらの運用管理のために他のユーザが出入りするでしょう。未熟、無知、過失、理由は何であれ、ファイアウォール機能やサーバ機能を変更したり停止してしまうかもしれません。これらのスキを衝いてクラッカーがシェルへのアクセスを獲得したら、後は言うまでもないでしょう。
外部からアクセスできる sendmailなどに問題があるのは事実です。/bin/loginも同様。しかし予算の制約で1台しか使えない場合には、仕方がないでしょう。この場合にとくに注意すべきことは、まず外部からのログインは禁止すべきです。またメールサーバに限らずすべてのプログラムを慎重に選んで設定すべきです。これらをやった上でファイアウォールを動かすなら、当然ファイアウォールなしで動かすよりずっと優れています。

不正侵入等で受ける被害(他者に迷惑をかけることによる信用低下も含む)、復旧に要するコストや手間との兼ね合いによって、セキュリティ対策を実施するわけです。

これまでのファイアウォールやネットワークセキュリティの本には、まず例外なく、ファイアウォール上で他のサーバプログラムは動かしてはならないと書いてあります。原則としてこれは正しいのですが、予算、人手、設置場所などに制約がある場合は、これは参考にしかなりません。中途半端と言われようと、きわめて現実的な対策を考えなければならないわけです。

列挙した中の最後の意見は、技術的な具体性が足りませんが、オールインワン的なサーバを構築する上で、現実的な対処だと思います。

【Linux Japan Vol.7 掲載記事を加筆修正】

前へ戻る次へ