| « BUFFALO Wi-Fi Gamers 無線LANアクセスポイント WCA-G | LAMPのPをPHPからPerl/Python/Rubyに替えるだけではセキュリティは向上しない証拠 » |
LAMPセキュリティを向上させる方法
LAMPはLinux, Apache, MySQLとPHPまたはPerl, Pythonを利用したWebシステムの総称として利用されている用語です。
特にLinux/Apache/MySQL/PHPはよく見かけるシステム構成です。ホスティングサービスを提供する会社でこの構成をサポートしていない会社を探すのが難しいくらいではないかと思います。広く使われていますが、「十分に安全な状態」と言える状況で運用されているケースはほとんどありません。
関連エントリ
LAMPのPをPHPからPerl/Python/Rubyに替えるだけではセキュリティは向上しない証拠
誤解を招く記事 - LAMPセキュリティを強化する4つの方法
...
脆弱性情報を収集する
全てのソフトウェアにセキュリティ上の問題が含まれている、と考えて間違いありません。利用しているソフトウェアの脆弱性情報を収集し、脆弱性がシステムに影響するか、影響する場合どの程度のリスクが予測できるか評価する事が重要です。
例えば、コミュニティ版のMySQLは有償版で提供されているセキュリティパッチが含まれていません。コミュニティ版を利用しているなら、システムに影響があるかどうか評価しなければなりません。
Apacheにも脆弱性が発見されています。明らかに脆弱性があるバージョンを利用しているサイトもありますが、脆弱性が発見されたモジュールをロードしていないのであれば、多少古いApacheを使っていても安全でしょう。
LAMPの脆弱性情報も重要ですが、LAMP上で動作しているアプリケーションの脆弱性情報の収集も書かせません。利用しているアプリケーション全ての脆弱性情報に注意する必要があります。
バージョンアップを行う
脆弱性が無いバージョンにバージョンアップするのはセキュリティ対策の基本中の基本です。
しかし、共有型のホスティングサービスはタイムリーなバージョンアップは期待できません。バージョンアップを行うと、バグフィックスやセキュリティ向上の為の仕様変更により、今まで動作していたアプリケーションが期待通りに動作しなくなる可能性があるからです。動作しなくなるとクレームになるためアップグレードは時々しか行われません。
バージョンアップにはライブラリやフレームワークのバージョンアップも含まれます。ほとんどのホスティングサービスではライブラリ/フレームワークはインストールされたままである場合が多いと思われます。
- Linux/Apache/MySQL/PostgreSQL/PHP/Perl/Python/Rubyなどのインフラ
- フレームワーク/ライブラリ
- アプリケーション
全ての既知の脆弱性がシステムに影響しないように管理しなければなりません。
脆弱性が報告されていなくてもバージョンアップが可能な場合、バージョンアップを行う方が良いです。バージョンアップを行っておくと脆弱性が報告された時にシステムにとって必須の脆弱にだけは直ぐに対処する事が容易になります。
仮想プライベートサーバ以上のサービスを利用する
適切にバージョンアップを行うにはソフトウェアを自前で管理するしかありません。共有型のサービスでは適切なバージョン管理は期待できません。仮想プライベートサーバ以上のでなければ安全に運用できません。
共有型サービスの場合、バージョンアップ以外にもファイルのセキュリティなど十分なセキュリティを維持することが難しいです。
利用可能なセキュリティ対策を利用する
例えば、Perl等にはtaintモードがあります。taintモードはセキュリティ対策として完全ではありませんが、安全性向上に有用です。taintモードを有効にしてもプログラムの実行やパフォーマンスに問題ない場合は有効にすると良いでしょう。
PHPにはopen_basedir設定でPHPが開けるディレクトリを制限する機能があります。この機能も完全ではありませんが、スクリプト実行の脆弱性がある場合、ログを監視する事で被害が発生する前に脆弱性を検出する事が可能となる場合もあります。
エラーを厳格に処理することもセキュリティ対策として有用です。アプリケーションが厳格なエラーチェックを行っても動作に支障が無いのであれば、可能な限り多くのエラー情報を有効にすると良いでしょう。
SELinuxは管理が面倒と思われるかもしれませんが、既にポリシーがありtargetedモードで運用するならそれほど難しい設定なしに利用できます。
iptablesによるパケットフィルタリングは必須です。Webサーバポートなど必要なポートにのみアクセスを許可します。FTP, SSHのポートへ接続できるIPアドレスを指定できるのであれば指定すると安全性が向上します。
Linuxサーバの安全性を確保する
クラッカーにログインを許してしまうと、Linuxカーネルのローカル権限昇格脆弱性を利用してroot権限を取得されてしまう事は少なくありません。root権限を取得しカーネルレベルで動作するマルウェアをインストールする攻撃も一般的です。
リスクを可能な限り少なくするために、サーバには不要なプログラム・サービスをインストールすべきではありません。可能であればSSHとWebサーバのポート以外は閉じておくべきです。サーバにはGUIもインストールする必要はありません。Xサーバもインストールしないようにします。
Apacheのモジュールにも時々脆弱性が発見されます。デフォルトでは多くのモジュールがロードされているので不要なモジュールはロードしないようにします。PHPのモジュールも同じように不必要なモジュールはロードしないようにします。
FTPとSSHサーバのパスワードをブルートフォース方式（ユーザ名とパスワードを推測して侵入を試みる）でクラックする攻撃は非常に一般的で。FTPは可能であれば利用しないようにします。SSHは公開鍵認証のみ利用可能に設定します。秘密鍵には必ず推測が難しいパスフレーズを設定します。
sudoでsuの実行を制限したり、sudoでシェル類も実行できないよう設定します。rootのパスワードは非常に難しいパスワードを設定します。アカウントの共有は行わず、ユーザが簡単なパスワードパスワードを設定していないかパスワードクラッカーを利用して定期的に確認するようにします。パスワードの安全性確認は、FTPやSSHでパスワード認証を有効にしている場合は特に重要です。
エラーログを監視する
エラーログの監視は適切にバージョンアップを行う事と同じくらい重要です。攻撃が行われる場合、少なからず試行錯誤することが多いです。例えば、ディレクトリ遷移攻撃でファイルを不正に参照しようとすると、エラーが何度か発生します。ブラインドSQLインジェクションでデータベースの解析を行うと大量のSQLエラーが発生します。攻撃されても、エラーログを監視していると実際に被害が発生する前に対応できる場合もあります。
仮想ホストを利用する
実際にサービスを提供するシステムに仮想ホストを利用すると、バージョンアップのテストが容易になります。仮想ホストのコピーを作り新しいバージョンをテストする事が可能になります。大規模なシステムならテスト環境が完備されていますが、LAMPでOSSアプリを動かしているサイトで十分なテスト環境が整備されているケースはあまり多くないと思います。
仮想ホストを利用するには仮想プライベートサーバでなく、ホスト丸ごとかりる必要があります。
脆弱性が頻繁に発見されるアプリケーションを利用しない
このアドバイスは微妙です。脆弱性が報告されていないアプリケーションに問題が無いのではなく、セキュリティ研究者が調査していないだけの場合が多いからです。JSPWiki(JavaベースのWiki), Plone(PythonベースのCMS)等はセキュリティ研究者が調査していなかった為、最近致命的なセキュリティ問題が修正されています。脆弱性をレポートしているセキュリティ研究者がアプリケーション全体を監査する事はほとんどありません。この為、既に脆弱性が報告されているから安全とは言えない事が多いです。
しかし、あまりに頻繁にセキュリティ上の問題がレポートされるアプリケーションはアーキテクチャ上の欠陥がある場合が多いです。頻繁にセキュリティ問題が発見されるアプリケーションの利用は控えるべきです。
システム管理用のアプリケーションには十分なセキュリティ対策が施されていないアプリケーションが少なくありません。システム管理用のアプリケーションを利用する場合、HTTPのDigest認証と一緒に利用する方が良いでしょう。
パッケージを利用する
運用中のサーバには開発ツールをインストールするのはあまり好ましくありません。例えば、コマンドインジェクションに脆弱なWebアプリケーションがあり、サーバにコンパイラ等がインストールされているとカーネルのローカル権限昇格脆弱性を利用し、root権限を奪われる可能性が高くなります。パッケージを利用するとコンパイラなどの開発ツールをインストールしなくても、LAMPをインストールできます。よくメンテナンスが行き届いているディストリビューションならソースからインストールするよりタイムリーにアップデートが可能です。
色々な事情で自前でビルドしたい場合でもパッケージをカスタマイズして利用すれば比較的簡単に必要なバイナリをビルドできます。ディストリビューションのバージョンがサポートするプログラムのバージョンが古くても、互換性のあるディストリビューションから新しいバージョンのプログラムのパッケージをインポートすることも難しくはありません。
デマを信じない
「言語を替えるとセキュリティが向上する」といった趣旨の議論があります。基本的な機能が同等な言語であれば、言語を替えるだけでセキュリティが向上する事はありません。
言語を替えると、脆弱性が無いバージョンにバージョンアップした時と同じ様に、一時的にセキュリティ状態が向上します。しかし、インストールした後にバージョンアップしなければ同じ事です。
アプリを自分で作る場合はフレームワークを必ず利用する
PerlでもPHPで、サンプルスクリプトのコピー&ペーストで作られているようなサイトは100％と言ってよいくらい脆弱性があります。自分でアプリケーションを作る場合、Webアプリケーションフレームワークを利用すべきです。Webアプリケーションフレームワークを利用したからといって自動的に安全なWebアプリケーションは作れるようになりませんが、CGIインターフェースを直接利用するのと比べればはるかに容易に安全なアプリケーションが作れます。安全なアプリケーションの作り方は別途に習得する必要があります。Webアプリセキュリティ対策入門などを参考にしていただければと思います。
フレームワークを利用しても、しなくても、最も重要なセキュリティ対策は厳格な入力のバリデーションです。その次は、デフォルトで全ての出力をエスケープすることです。
既成のアプリケーションを選定する場合、入力バリデーションと出力エスケープがどのようになっているか確認するのは非常に良い選択方法だと思います。
このエントリがポストされているのは 3月 23rd, 2008 07:29:38 and is filed under Security, PHP
永続的リンク
4 コメント
「脆弱性が頻繁に発見されるアプリケーションを利用しない」と「デマを信じない」は矛盾するのでは?と思った方がいるかも知れません。「PHPは脆弱性がたくさん報告されてるでは?」と思われた方も少なくないかも知れません。http://gihyo.jp/dev/serial/01/php-security/0004
に簡単に原因をまとめています。
言語の本体部分の脆弱性はそれほど多くありません。最近ではprintf系関数のフォーマット文字列攻撃が可能であった事くらいが思いつきます。これも厳密にはstandardと呼ばれるビルドオプションで無効にできないモジュール関数ですが、standardモジュールはPHP本体といって構わないでしょう。standardモジュールに含まれる関数でhtmlentities/htmlspecialchars関数に対する不正な文字エンコーディングを利用した攻撃にたいする脆弱性も最近修正(
PHP5.2.5)されています。これも本体といって差し支えないかも知れませんが、他の言語ではこの種の関数は「言語本体」には分類されない関数でしょう。
# 他の言語はエンコーディング攻撃は大丈夫なのか?
# と心配になります。Ruby 1.9はかなり厳格にエンコー
# ディングを取り扱っているので大丈夫そうな気がし
# ますが誰も調べていないような気が...
モジュール関数で多く報告されるsafe_mode, open_basedir関係のセキュリティ報告はフェイルセーフ機能に対する報告です。Javaのように全ての機能が完全にSandbox化できる場合もありますが、スクリプト系言語のVMレベルで同じ機能を実装した、同じような不具合が多数報告されると予測できます。
モジュール関係では意図的なコードでメモリに直接アクセスできる場合もセキュリティ問題、として報告されています。これはPHPが共有環境のWebサーバモジュールとして利用されている事が多いので、直接メモリが参照できる事例のほとんどがセキュリティ問題として報告されています。この基準を他の言語のモジュールに当てはめるとかなりの数の「脆弱性」が発見できると思います。
PHP本体のセキュリティ上の最大の問題はPHPのリリースポリシーです。「PHPはセキュリティ的にダメだね」と言いたい場合、ここが最大の攻撃箇所かと思います。
http://michilu.com/django/doc-ja/fastcgi/Django を動作させる構成として 現在推奨されている のは， Apache と mod_python の組合せですが，多くの人々が共有ホスティングサービスを使っており，そこでは FastCGI や SCGI, AJP といったプロトコルしか選択肢がない場合もあります．また，構成によっては， FastCGI は mod_python よりも安全であり，パフォーマンスの点で mod_python をしのぐ場合もあります．
pythonではmod_pythonよりFCGIが多いようですね。mod_pythonではPHPより低いセキュリティしか期待できませんから当然です。
詳しい解説参考になります。こまかいところですが一点だけ。
> 秘密鍵には必ず推測が難しいパスフレーズを設定します。
これはサーバの堅牢化というよりも管理用クライアントの問題になるわけで、それを言いはじめると「管理用クライアントの安全性も大事だよ。」という話をしなければいけないような？
上記引用文の意図は「その端末で変なサイトにアクセスしたり／端末自体が盗難されたりして、秘密鍵を盗られたら大変なことになるよ。」という話でしょうか？
セキュリティはシステム全体で維持しなければならないので、クライアントや物理的なセキュリティ対策、ユーザの教育は非常に重要だと考えています。> これはサーバの堅牢化というよりも管理用クライアントの問題になるわけで、
> それを言いはじめると「管理用クライアントの安全性も大事だよ。」という
> 話をしなければいけないような？
はい。おっしゃる通りで、クライアントの安全性は非常に重要だと考えています。非常に重要ですがまとめて書くのは難しいです。せめてSSHのパスフレーズくらいは難しい文字列にした方がよいとだけ書いています。私がクラッカーならクラックに成功したPCにはSSH秘密鍵がシステム上に無いか調べ、アクセス履歴等から侵入可能なシステムがないか確かめる可能性は高いです。
クライアントサーバ型のシステムではサーバ側の安全性を確保しても、クライアントにキーロガー（最近ではスクリーンショットや画面の動画も当たり前になって、スクリーンロガーになってますが）などでパスフレーズが分かってしまう可能性もありますが....
私は秘密鍵をできるだけ使い回さないようにしていますが、多くの方が秘密鍵を使い回していると思います。自分のPC, 会社のPC, 会社のサーバなどなど... パスフレーズ無しだと自分だけの秘密鍵と言えない状態の秘密鍵も少なく無いのでは、と心配しています。
後非常に気になっているのはWebアカウントのパスワードの使い回しです。私は同じパスワードは二度と使いませんが、多くの方は複数のアカウントでパスワードを使い回していると考えられるので非常に気になっています。
この投稿へのコメント