【IIS7】 MSC2008 セッションより （第二話）
では 第二話。
｛IIS7.0 で強化されたセキュリティ機能の紹介｝
●IISセキュリティ対策の現状
セキュリティ更新プログラムに関してバージョンと更新プログラム数の比較表を掲載しました。それとSecuniaにおけるIISとApache単体でのAdvisory数とUnpatch%の表も一緒に載せました。
https://www.microsoft.com/japan/technet/security/current.aspx
Windows Vistaについては MS08-005: インターネット インフォメーション サービスの脆弱性により、特権の昇格が起こる (942831) 深刻度：重要 が登場しています。Windows Vista SP1 は Windows Server 2008 と同レベルなので、SP1環境については０です。
Advisory に基づいてパッチが必要なものは製品を取り扱っているところがパッチをしていくという流れになっていますが、数字を拾ってきたところ単純比較という意味ではこんな感じです。もちろん Apache については単体ではなく、アプリケーションプラットフォーム込みのものを見ないといけませんが、それは是非 ご自身でSecuniaサイトにてご覧ください。
●アーキテクチャの変更
1. モジュール化構造
Windows Server 2008と同様、IIS7.0もモジュール構造に変わっています。セキュリティの観点では「必要なもののみインストールする」ことが完全にできるようになったわけです。
ちょっとこれだとあっさりしてますが、セミナーでは既定インストール、Server Core、ASP.NET（最小）を図で入れていました。これは以前の How to インストール 投稿をご覧になって判断していただければと思います。
2. IIS関連アカウント、グループのビルトイン
IIS6では IIS_WPGというグループに実行アプリケーションプールのユーザーを含めることが必要でしたが、IUSRというNETWORK SERVICE や SYSTEM などと同じように IIS 用のビルトイングループができました。これにより IIS6.0 でやっていたことは不要になりますが、その仕掛けは次のSIDインジェクションのところで説明します。なお、IUSR_マシン名は互換性のために存在します。
3. SID インジェクション IIS_IUSRSを“注射”
インジェクションという言葉は最近よく脆弱性の説明で登場しますが、ここでのインジェクションは文字通りで使っているだけで攻撃方法のことではありません。下記のような動作のことを言います。
※インジェクション：直訳だと”注射”
a. HTTPのリクエストが来る
b. HTTP.SYSドライバがカーネルモードでこのリクエストを受け取る
c. ユーザーモードに渡し、該当アプリのワーカープロセスを起動するように促す
d. WASが起動を行うために環境情報から実行アカウントを入手する
※WAS：プロセス起動サービスの略でIIS7では独立したサービス
e. ADの場合、WASがLogonUserを使用してADからトークンを受け取る
f. WASがトークンにIIS_IUSRSグループとアプリケーションプールのSIDをインジェクションする
※IIS7ではアプリケーションプール毎にSIDがふられる
g. WASがこのトークンを使ってワーカープロセス（w3wp.exe）を起動する
h. リクエストが処理される
i. リクエストが自身のアプリケーションフォルダをアクセスする場合にはアクセスできる
j. リクエストが別のアプリケーションフォルダをアクセスする場合にはアクセスできない
この仕組みはまさホスティングを想定し、他のユーザーのディレクトリにアクセスがなされないことを構造的に実現するものです。一方で社内の環境においてもプロセスの壁とACLによって守られる新しい仕組みになっています。
4. 既定で独自アプリケーションプールの設定
この点は過去にも何度かセミナーで話しをしていますが、新しいサイトを作ろうとした時、今までは何もしなければDefaultAppPoolが選択されていました。IIS7（Windows Server 2008, Vista SP1）では App1というサイトを作ろうとすると自動編集でApp1というアプリケーションプールが新規作成されるようになっています。ただもちろんプロセス数を多くしたく無い場合には明示的に今までと同じように任意で選択することも可能です。要はデフォルトを変更しました。SIDインジェクションなどの構造を生かす上でも実はこの機能が重要なのです。
●新しいセキュリティ管理機能群
特に新しいセキュリティ機能については IIS.NET の新しい Learn のセクションから Configuring Security を参照ください。
1. リクエスト フィルタリング ルール
Windows Server 2003 で利用できる URLScan という機能を標準実装したのがこれです。IIS7では完全に標準機能になっていて、システム構成でアクセスを許したくないフォルダやファイルをURLベースで定義可能です。ただ、設定UIが無いのが玉に瑕でした。過去形で書いているのは意味があって、Administration Pack for IIS 7.0 （現在 TechPreview 版）を使用すると設定するUIがIISマネージャに増えます。
Administration Pack for IIS 7.0
※実は当日はPackの中から IIS Reports という機能をチラ見せしました。この機能はLog Parserが入ってないとLog Parserを入れてくださいといわれるので明らかに依存しているレポート機能で、SQL Reportingサービスライク（実際に使っているかは未確認なんですが）なUIで色々なレポートを表示してくれます。結構アクセス解析方面でも便利そうです。
過去の私のセッションをご覧になった方には少しインプットがあって、スキーマを見るとより確実にわかるのですが、HiddenNameSpace と過去呼んでいたものが HiddenSegments という名称に変わっています。これは過日シアトルでIIS開発チームの Thomas Deml 氏にも直に確認したので間違いありません。ここに定義されているところにアクセスにいくと404.8 エラーになる、そういう動きをするものです。
他のフィルタリングについては下記を参照ください。
https://learn.iis.net/page.aspx/143/how-to-use-request-filtering/
2. ルールベースの URL 認証
セミナーでは時間がとれずに紹介だけで終わったのですが、ここでは少し書きましょう。
詳細はここに書いてあります。
https://learn.iis.net/page.aspx/142/understanding-iis-7-url-authorization/
ACLを利用したアクセス制限は非常に手間がかかる上にさらにマシン間でコピーするのが困難です。その状況に一石を投じようというのがこの機能です。web.config にアクセス制御を取り込むことでアプリフォルダをコピーした時にこの辺りの内容もコピーできてしまう優れものです。じゃあ web.config が攻撃されたら？と思う方はちょうど上のHidden Segmentsの図を見てください。（*^_^*）
3. リモート管理と管理の委任
これも他のセミナーでは話をしてきているので、第一話で紹介したWebcastをご覧いただきたいのですが、要点は以下です。
- 今まではサイトをいじるだけの人もほぼサーバー管理者権限をあげないと設定を委任できなかった
- IIS7では「機能の委任」とIISマネージャ専用ユーザーなどの組合せにより機能が粒度を制御しつつ委任できるようになった
- リモート管理は重要な機能として取り扱われ、HTTP/HTTPSで接続する各種ツールが用意されている
- IISマネージャはVista版とWindows Server 2008版で違い、Vista版はリモート管理できないバージョン
- IIS.NETでリモート接続できる版がダウンロード可能 ここ
- コマンド管理ツールの Appcmd は Winrs.exe（設定はWinRM.exe）と併用することでリモート管理できる
これくらいでしょうか。まあこれだけ知っていれば後は実践あるのみでしょう。
次回へ続く．．．（*^_^*）
= English =
[IIS7] From my sesssion – the Microsoft Conference 2008 (Part 2)
OK here goes the second part.
{Introducing Security features powered by IIS7.0}
- How is IIS doing in the security world?
I showed a chart that shows about the number of IIS security updates for each version. Also I had one that shows the nubmer of advisories on the Secunia web site including IIS and Apache alone.
https://www.microsoft.com/japan/technet/security/current.aspx
For Windows Vista, there’s MS08-005 KB942831 Vulnerability in Internet Information Services could allow elevation of privileges Severity: Important. Windows Vista SP1 is in the same level as Windows Server 2008 so you can think of SP1 as 0.
When there’s an advisory shown, the people who make the product are responsible for patching it. Well I just picked up the numbers from the site as a fact. Regarding Apache, I know that we need to get the one’s including the application layer to compare but I didn’t do that so please go on and check your environment at the site.
- Changes in the architecture
1. Modular structure
Same as Windows Server 2008, IIS7.0 is also modular in architecture now. In terms of security, now you can really do “Install only what you need.”
This picture just shows the whole module in view but at the event I showed the combination needed when you have the default settings, what Server Core has, and the least you need for ASP.NET. If you need details on this, please look at the article at IIS.NET about modules.
2. IIS related accounts and groups are Built-In now
In IIS6, there is a group called IIS_WPG where you have to put the execution IDs of application pools. Now in IIS7, there is a built in account called IUSR just like the NETWORK SERVICE or SYSTEM group but for IIS specifically. I’ll explain how it works in the SID injection part later. IUSR_machinename is still there for compatibility.
3. SID injection – injecting IIS_IUSRS
インジェクションという言葉は最近よく脆弱性の説明で登場しますが、ここでのインジェクションは文字通りで使っているだけで攻撃方法のことではありません。下記のような動作のことを言います。
※インジェクション：直訳だと”注射”
a. HTTPのリクエストが来る
b. HTTP.SYSドライバがカーネルモードでこのリクエストを受け取る
c. ユーザーモードに渡し、該当アプリのワーカープロセスを起動するように促す
d. WASが起動を行うために環境情報から実行アカウントを入手する
※WAS：プロセス起動サービスの略でIIS7では独立したサービス
e. ADの場合、WASがLogonUserを使用してADからトークンを受け取る
f. WASがトークンにIIS_IUSRSグループとアプリケーションプールのSIDをインジェクションする
※IIS7ではアプリケーションプール毎にSIDがふられる
g. WASがこのトークンを使ってワーカープロセス（w3wp.exe）を起動する
h. リクエストが処理される
i. リクエストが自身のアプリケーションフォルダをアクセスする場合にはアクセスできる
j. リクエストが別のアプリケーションフォルダをアクセスする場合にはアクセスできない
この仕組みはまさホスティングを想定し、他のユーザーのディレクトリにアクセスがなされないことを構造的に実現するものです。一方で社内の環境においてもプロセスの壁とACLによって守られる新しい仕組みになっています。
4. 既定で独自アプリケーションプールの設定
この点は過去にも何度かセミナーで話しをしていますが、新しいサイトを作ろうとした時、今までは何もしなければDefaultAppPoolが選択されていました。IIS7（Windows Server 2008, Vista SP1）では App1というサイトを作ろうとすると自動編集でApp1というアプリケーションプールが新規作成されるようになっています。ただもちろんプロセス数を多くしたく無い場合には明示的に今までと同じように任意で選択することも可能です。要はデフォルトを変更しました。SIDインジェクションなどの構造を生かす上でも実はこの機能が重要なのです。
●新しいセキュリティ管理機能群
特に新しいセキュリティ機能については IIS.NET の新しい Learn のセクションから Configuring Security を参照ください。
1. リクエスト フィルタリング ルール
Windows Server 2003 で利用できる URLScan という機能を標準実装したのがこれです。IIS7では完全に標準機能になっていて、システム構成でアクセスを許したくないフォルダやファイルをURLベースで定義可能です。ただ、設定UIが無いのが玉に瑕でした。過去形で書いているのは意味があって、Administration Pack for IIS 7.0 （現在 TechPreview 版）を使用すると設定するUIがIISマネージャに増えます。
Administration Pack for IIS 7.0
※実は当日はPackの中から IIS Reports という機能をチラ見せしました。この機能はLog Parserが入ってないとLog Parserを入れてくださいといわれるので明らかに依存しているレポート機能で、SQL Reportingサービスライク（実際に使っているかは未確認なんですが）なUIで色々なレポートを表示してくれます。結構アクセス解析方面でも便利そうです。
過去の私のセッションをご覧になった方には少しインプットがあって、スキーマを見るとより確実にわかるのですが、HiddenNameSpace と過去呼んでいたものが HiddenSegments という名称に変わっています。これは過日シアトルでIIS開発チームの Thomas Deml 氏にも直に確認したので間違いありません。ここに定義されているところにアクセスにいくと404.8 エラーになる、そういう動きをするものです。
他のフィルタリングについては下記を参照ください。
https://learn.iis.net/page.aspx/143/how-to-use-request-filtering/
2. ルールベースの URL 認証
セミナーでは時間がとれずに紹介だけで終わったのですが、ここでは少し書きましょう。
詳細はここに書いてあります。
https://learn.iis.net/page.aspx/142/understanding-iis-7-url-authorization/
ACLを利用したアクセス制限は非常に手間がかかる上にさらにマシン間でコピーするのが困難です。その状況に一石を投じようというのがこの機能です。web.config にアクセス制御を取り込むことでアプリフォルダをコピーした時にこの辺りの内容もコピーできてしまう優れものです。じゃあ web.config が攻撃されたら？と思う方はちょうど上のHidden Segmentsの図を見てください。（*^_^*）
3. リモート管理と管理の委任
これも他のセミナーでは話をしてきているので、第一話で紹介したWebcastをご覧いただきたいのですが、要点は以下です。
- 今まではサイトをいじるだけの人もほぼサーバー管理者権限をあげないと設定を委任できなかった
- IIS7では「機能の委任」とIISマネージャ専用ユーザーなどの組合せにより機能が粒度を制御しつつ委任できるようになった
- リモート管理は重要な機能として取り扱われ、HTTP/HTTPSで接続する各種ツールが用意されている
- IISマネージャはVista版とWindows Server 2008版で違い、Vista版はリモート管理できないバージョン
- IIS.NETでリモート接続できる版がダウンロード可能 ここ
- コマンド管理ツールの Appcmd は Winrs.exe（設定はWinRM.exe）と併用することでリモート管理できる
これくらいでしょうか。まあこれだけ知っていれば後は実践あるのみでしょう。
次回へ続く．．．（*^_^*）