Windowsセキュリティ・ワンポイントレッスン第3回 ソフトウェア制限ポリシーによるマルウェア対策 Windows OSにはマルウェア対策に有効なさまざまな機能が実装されています。そのような機能の一つであるにもかかわらず、あまり一般に利用されていないのが「ソフトウェア制限ポリシー」です。今回はWindowsの標準機能である「ソフトウェア制限ポリシー」を使用したマルウェア感染対策について解説します。 ソフトウェア制限ポリシーとはソフトウェア制限ポリシー（SRP：Software Restriction Policies）とは、Windows XP以降に導入された「ソフトウェアの実行を制限する機能」のことです（各ホームエディションは除く）。 例えばみなさんが組織のシステム管理者だったとしましょう。組織内のエンドユーザが自分のWindows PC上に好き勝手なソフトウェアを入れて動かすことができてしまうと、困ってしまいますよね。ゲームソフトを入れて遊ぶくらいならまだましですが、場合によってはライセンス違反につながったり、コンピュータウイルスの感染を引き起こしたり、また不正アクセスツールを社内ネットワーク上で実行することも考えられます。 エンドユーザにそのようなことをさせない、つまりシステム管理者が許可したソフトウェア以外は起動することをシステム的に制限してしまうのがこのソフトウェア制限ポリシーという機能です[1]。
ソフトウェア制限ポリシーでは、以下の4種類の方法で制限をかけることが可能です。
マルウェア感染対策としての有効性ウイルスなどのマルウェアの感染経路は多種多様ですが、その主要な一つとして不正なプログラムファイル（EXEやDLL、スクリプトファイル等）の実行があげられます。ユーザが意図的にそのプログラムを実行する場合（トロイの木馬）もあれば、意図せず勝手に実行してしまう場合（システムの脆弱性を利用）もあるでしょう。 つい先日のことですが、ほとんどのWindows OSに影響する「Windowsシェルの脆弱性[2]」が報告されました。この脆弱性は、不正に細工されたショートカットファイル(LNKやPIF)をエクスプローラなどで参照することにより、任意のDLLファイルが自動的にロードされてしまうというものです。現時点（2010年7月）ではセキュリティ更新プログラムはまだ提供されておらず、いわゆるゼロデイ攻撃としてこの脆弱性を利用したマルウェアが出回っています[3]。
この脆弱性によるマルウェア感染は、USBメモリのみならず、共有フォルダ（WebDAV等）、Webアクセス、Officeドキュメント経由などの可能性も指摘されていますが、いずれにせよこの脆弱性を利用した攻撃が成功するポイントは、不正なDLLファイルがエクスプローラ等によってロードされる点にあります（DLLがロードされた時点で自動的に内部の不正コードが実行するため）。 外部からやってきた不正な実行ファイルが、何らかの脆弱性あるいはユーザの操作により起動してしまうことでマルウェアに感染するケースは、この他にも以下のような例があげられます。
ただしソフトウェア制限ポリシーができることは、許可されていないプログラムファイルの起動（あるいはDLLファイルのロード）の防止に限られます。例えば文書ファイルや画像ファイルを利用したバッファオーバーフロー攻撃など、起動を許可されたプログラムに不正なプログラムコードを送り込んで実行させるような攻撃は防ぐことができません。 ソフトウェア制限ポリシーの設定例ソフトウェア制限ポリシーは、ドメイン環境下ではグループポリシーでドメインメンバーに展開することができますし、スタンドアローン環境下でもローカルセキュリティポリシーで設定することが可能です。 以下に、Windows 7のスタンドアローン環境での設定例を示します。
ソフトウェア制限ポリシーの使用上の注意点どのようなセキュリティ機能についてもいえることですが、ソフトウェア制限ポリシーは万能ではありません。設定や運用に不備があると有効性が限定されたり、利便性が著しく損なわれたりします。ここではソフトウェア制限ポリシーを使用する上での注意点をいくつか述べたいと思います。 計画性を持って十分にテストしてから展開するソフトウェア制限ポリシーを導入する際には、ユーザに対しどのようなソフトウェアの実行を許すかについて、あらかじめ明確にしてポリシー設計する必要があります。ユーザが使用するPC環境の標準化を行い、アプリケーションソフトのインストール先や、ログオンスクリプトの設置場所などの統一化を図ることが、効率的なポリシー展開には欠かせないでしょう。 また事前に十分テストを行い、不具合が発生するソフトウェアがないかどうか、ユーザの利便性が適切に確保されているかどうかを確かめることも重要です。ソフトウェア制限ポリシーには詳細なログを記録する機能があります。このログを見ればどのプロセスが何を起動しようとして成功／失敗したという情報がわかりますので、テストする際には非常に有効な手段となります[4]。 利用者は一般ユーザとしてログオンするシステムの利用者は、基本的に一般ユーザ権限でログオンしてシステムを使用することが求められます。利用者に管理者権限でのログオンを許した場合、ソフトウェア制限ポリシーの設定が変更されてしまうかも知れません。また管理者権限でログオンすれば、パスの規則を回避することは極めて容易です。 「パスの規則」の思わぬ落とし穴（その1）ソフトウェア制限ポリシーのパスの規則は、「実行が許可されたフォルダやファイルには利用者は書き込めない」ということが前提になっています。パスの規則で実行を許可したフォルダの配下に利用者が書き込める場所があった場合、利用者は規則を回避するためそこに実行させたいプログラムファイルをコピーして起動させることが考えられます。 例えばパスの規則で「C:\Windows」以下の実行を許可したとしましょう。「C:\Windows」の下は基本的には一般ユーザはファイルを作成できないようなアクセス許可の設定がされているのですが、一部のフォルダ（「C:\Windows\Temp」等）は一般ユーザでもファイルの作成や実行ができてしまいます。このようなフォルダについては、個別にパスの規則を設定し、ソフトウェアの実行を制限させる必要があります。 また「C:\Program Files」配下についても、インストールされたアプリケーションによっては一般ユーザに書き込み許可を与えたフォルダを作成する場合があるので注意が必要です。このような場合はフォルダのアクセス許可の設定を見直した方が良いかも知れません。 「パスの規則」の思わぬ落とし穴（その2）さらにパスの規則では、特定の拡張子を許可する設定を追加した場合、実行可能ファイルを当該拡張子に変更すると起動できてしまうという問題があります。 例えばショートカット（拡張子「LNK」）の実行を許可するために「*.lnk」 ⇒ 「制限しない」というパスの規則を追加したとします。これで確かにショートカットは問題なく動作するようになりますが、ユーザが持ち込んだ実行ファイル（拡張子「EXE」）の拡張子をLNKに変更すると、その実行ファイルも起動可能になってしまいます。 元来ソフトウェア制限ポリシーは、拡張子が変更されていてもファイル自体が実行ファイルであれば拡張子にかかわらず正しく判断するように作られています。しかしパスの規則で特定の拡張子を許可した場合、まず拡張子で判断し、「制限しない」になっているため実行を許してしまうのでしょうね。 ソフトウェア制限ポリシーを厳密に運用することは、特に大きな組織ではいろいろと難しい点も多いと考えられます。しかしWindowsの標準機能を用いたプロアクティブなマルウェア対策として、非常に優れた効果を発揮することは間違いありません。多層防御の一つとして、ぜひ導入を検討していただければと思います。 Windows 7以降、ソフトウェア制限ポリシーの後継機能としてアプリケーション制御ポリシー（AppLocker）が追加されました（UltimateおよびEnterpriseエディション）。AppLockerはソフトウェア制限ポリシーをさらに強化し、より使いやすくしたものです。AppLockerについてはまたの機会に紹介しましょう。
[1] Windows XPセキュリティガイド
第6章 Windows XPクライアントのソフトウェア制限ポリシー
http://technet.microsoft.com/ja-jp/library/dd347746.aspx
[2] マイクロソフト セキュリティ アドバイザリ（2286198）
Windowsシェルの脆弱性により、リモートでコードが実行される
http://www.microsoft.com/japan/technet/security/advisory/2286198.mspx
[3] Preempting a Major Issue Due to the LNK Vulnerability - Raising Infocon to Yellow
http://isc.sans.edu/diary.html?storyid=9190
[4] ソフトウェア制限ポリシーを使用したアプリケーションのロックダウン
http://technet.microsoft.com/ja-jp/magazine/2008.06.srp.aspx
2010年7月執筆 |
