セキュリティを強化する7つの便利なHTTPヘッダ
Webアプリケーションの開発・展開を行っている人々にとって、セキュリティ確保は大きな関心事の1つだといえます。そのためのベストプラクティスやフレームワーク、ガイドラインを提供しているのがOWASP（Open Web Application Security Project）です。OWASPのWikiサイト（OWASP.org）には、Webアプリケーションのセキュリティ確保のための様々な情報がありますが、それらの中でも即効性の高いのが「便利なHTTPヘッダのリスト（List of useful HTTP headers）」だといえるでしょう。 このページには、アプリケーションのHTTPレスポンスに追加することで、事実上無料でセキュリティを強化できるHTTPヘッダが7種類掲載されています。 これらの中でまず活用したいのが、以下の2つのHTTPヘッダです。 X-XSS-Protection 最近のWebブラウザには、クロスサイトスクリプティング（XSS）に対するフィルタ機能が装備されています。「X-XSS-Protection」はこのフィルタ機能を強制的に有効にするというものです。通常であればXSSフィルタはデフォルトで有効に設定されているはずですが、ユーザがこの設定を無効にした場合には、このHTTPヘッダがXSSの防止に役立ちます。 X-Content-Type-Options Webブラウザは本来、サーバから送られてきたHTTPレスポンスに記述されている「Content-Type」に基づいて、HTTPレスポンスをどのように処理するのかを決定します。 例えば「Content-Type:text/plain」であれば、Webブラウザはこれをテキストとして扱い、レスポンスの中にスクリプト記述があってもスクリプトとしては実行しません。しかしWebブラウザの中には、HTTPレスポンス全体を検査（sniffing）してコンテンツ タイプを判断し、「Content-Type」を無視した動作を行うものも存在します。このような実装はWebアプリケーション開発者の意図しない動作を引き起こし、セキュリティ上の問題につながると指摘されてきました。このsniffingを防止するのが「X-Content-Type-Options」です。「X-Content-Type-Options : nosniff」とすることでsniffingをやめさせ、「Content-Type」に合致しない動作を回避できます。 また以下のヘッダもセキュリティ強化に役立ちますが、実際に利用した際に問題が発生しないかどうか、慎重に検討する必要があります。 Public-Key-Pins Webブラウザに、特定の暗号鍵と特定のWebサーバとの紐付（pinning）を行わせます。これによって偽造証明書を検出しやすくなるため、偽造証明書による中間者攻撃の回避に役立ちます。 Strict-Transport-Security Webブラウザに対し、現在接続しているドメインへの次回以降のアクセスにおいて、HTTPSの使用を強制します。これも中間者攻撃の回避に役立ちます。 X-Frame-Options / Frame-Options またはの内部にページを表示しないように指定できます。これによってクリックジャッキングを防止できるようになります。クリックジャッキングとは、一見無害なページの上に＜iframe＞等の透過レイヤーによって悪意のあるページを「見えないように表示」させ、ユーザが意図していないボタンクリック等を引き起こすという攻撃です。ただしこのHTTPオプションによって＜frame＞＜iframe＞の機能が制限されるため、これらの機能を活用しているアプリケーションは正常に動作しない可能性があります。 Content-Security-Policy / X-Content-Security-Policy / X-Webkit-CSP ロード可能なスクリプトを制限する、インライン記述のスクリプトの実行を禁止する、等のポリシーを設定し、それをWebブラウザに強制させます。XSSを含む幅広い攻撃の防止に役立ちます。 Content-Security-Policy-Report-Only 1つ上のCSPと同様ですが、ポリシーを強制せず、ポリシー違反が起きた時のレポーティングのみを行います。 HTTPヘッダをWebアプリケーションに自動追加する方法 これらのHTTPヘッダを全てのWebアプリケーションに追加するのは大変な作業ですが、F5が2015年5月に発表した「F5 LineRate」を利用すれば簡単になります。F5 LineRateは安価なソフトウェア型ロードバランサであり、プロキシとして機能するバーチャルサーバにスクリプトを追加することで、様々な機能を実装できます。 例えば上記ヘッダのうち、「X-Frame-Options」「X-XSS-Protection」「X-Content-Type-Options」を自動的に追加するスクリプトは、以下のように記述できます。 "use strict"; var vsm = require("lrs/virtualServerModule"), virtualServerName = "myVirtualServer"; vsm.on("exist", virtualServerName, function(vs) { vs.on("request", insertUsefulHeaders); }); function insertUsefulHeaders(servReq, servResp, cliReq) { cliReq.on("response", function(cliResp) { cliResp.bindHeaders(servResp); servResp.setHeader("X-Frame-Options", "deny"); servResp.setHeader("X-XSS-Protection", "1; mode=block"); servResp.setHeader("X-Content-Type-Options: nosniff"); cliResp.fastPipe(servResp); }); servReq.bindHeaders(cliReq); servReq.fastPipe(cliReq); } スクリプトの行数はわずか20行。追加されるヘッダ記述の容量も100バイト程度しかありません。これによってアプリケーションのセキュリティは、大幅に強化されるはずです。 なお、F5 LineRateのStarter Editionは、無料でダウンロードして試すことができます。ぜひ無料ライセンスを取得し、その威力を体感してください。
Big-IPとADFSパート1 - ADFSファームの負荷分散
企業がクラウドへの移行を進める様子は、かつて開拓者たちが次々に幌馬車を仕立てて西への道を辿ったことを思い起こさせます。今クラウドに移行している企業はもはや開拓者とは呼べないかも知れませんが。クラウドへの集団移民が起こっているとまでは言えないものの、Office 365をはじめとしたクラウドベースのサービスを導入する企業が増えてきていることは事実です。 このような状況において、社外にあるリソースへのシームレスな、あるいは少なくとも比較的シームレスなアクセスを提供できるでしょうか？この回答のひとつにフェデレーションがあり、マイクロソフトを使っている企業ならADFS（Active Directory Federation Services）をその最新のソリューションとして利用することが可能です。この場合、ADFSサーバはセキュリティトークン サービスとして機能し、ディレクトリによって承認されるクライアントのシングルサインオン（SSO）を社外のリソースにも拡大します。クラウドベースのアプリケーションやフェデレーションの普及と歩調を合わせ、ADFSの役割も重要になってきています。以下にADFSサーバファームとADFS Proxyサーバファーム（社内に置いたADFSファームに外部からアクセスする場合に推奨）の典型的な展開シナリオを示しています。 警告：ADFSサーバファームを利用できない場合、フェデレーションによるリソースへのアクセスには制約が加わります。ハイアベイラビリティ、パフォーマンス、および拡張性を確保するためには、F5 Big-IPをLTM（Local Traffic Manager）と共に展開し、ADFSとADFS Proxyサーバファームの負荷分散を行います。F5のBig-IPは負荷分散とアプリケーション配信のための非常に優れた手段のひとつです。 それでは次に技術面を説明します。このブログのパート1では、ADFSとADFS Proxyサーバファームの負荷分散を目的とした、Big-IPのLTMモジュール（英語）の展開とコンフィグレーション設定について説明します。パート2ではBig-IPのAPM（英語）（Access Policy Manager）を利用することにより、この展開作業をはるかに簡素化し、改善できることを示します。 社内ADFSサーバファームの負荷分散 前提事項および製品展開のための資料 - この展開シナリオではADFSサーバファームがインストールされ、該当するクレームプロバイダやリライングパーティとの間の信頼関係を含むコンフィグレーション設定が展開ガイド（英語）に基づいて行われていることを前提としています。また読者にはBIG-IP LTMモジュールの管理に関する一般的な知識があることを想定しています。詳細やアドバイスが必要な場合はF5のサポートサイトASKF5（英語）を参照してください。下図はADFSサーバファームの負荷をBig-IPによって分散する場合の典型的な（ただし簡略化された）プロセスフローを示しています。 クライアントがADFS対応の外部リソースへのアクセスを試みます。 クライアントはそのリソースのフェデレーションサービスにリダイレクトされます。 クライアントは社内のフェデレーションサービスにリダイレクトされます（リソースのフェデレーションサービスが信頼できるパートナーとして設定されていることが前提）。 ADFSサーバがアクティブディレクトリに対してクライアントを認証します。 ADFSサーバは、署名済みのセキュリティトークンとリソースパートナーへのクレームセットを含む認証クッキーをクライアントに提供します。 クライアントはリソースパートナーのフェデレーションサービスに接続し、そこでトークンとクレームが検証されます。該当する場合にはリソースパートナーが新しいセキュリティトークンをクライアントに提供します。 クライアントは新しい認証クッキーをそれに含まれるセキュリティトークンと共にリソースに提示してアクセスを行います。 仮想サーバとプールメンバー - 仮想サーバ（VIP）はポート443（https）を監視するよう設定されます。Big-IP SSLブリッジング（解読と再暗号化）に使用される場合、Big-IPと関連して作成されるクライアントSSLプロファイルに外部向けのSSLとそれに伴う秘密鍵をインストールしておく必要があります。ただし後に説明するように、SSLブリッジングはこのタイプの展開では好ましい手段ではありません。その代わりとしてSSLトンネリング（パススルー）が利用されます。 ADFSはTransport Layer SecurityとSecure Sockets Layer（TLS/SSL）を必要とします。したがってプールのメンバーはポート443（https）を監視するよう設定されます。 負荷分散の手法 - 「Least Connections（メンバー）」方式を使用します。 プールモニター - ADFSサービスとウェブサイト自体が応答していることを確認するため、カスタマイズしたモニターを使用することができます。このモニターはADFSフェデレーションサービスが応答していることを保証します。またこのモニターは間隔とタイムアウト設定を高めて使用します。このカスタムhttpsモニターには、サービスのステータスを確認するためドメインの証明書を必要とします。この代わりとして標準的なhttpsモニターを使用することも可能です。 パーシステンス - このADFSシナリオでは、クライアントはセキュリティトークンの要求と受領のため、ADFSサーバとの間に単一のTCP接続を確立します。したがってパーシステンス プロファイルの指定は不要です。 SSLトンネリング（この方法を推奨） - SSLトンネリングを使用した場合、暗号化されたトラフィックがクライアントからエンドポイントであるファームのメンバーに直接流れます。またSSLプロファイルは使用せず、SSL証明書をBig-IPにインストールする必要もありません。この場合にはパケット分析または変更（例：圧縮、ウェブアクセラレーション）またはその両方を必要とするBig-IPプロファイルは意味を持ちません。さらにパフォーマンスを高めるためにはFast L4仮想サーバが使用します。 ADFS Proxyサーバファームの負荷分散 前提事項および製品展開のための資料 - この展開シナリオではADFS Proxyサーバファーム（英語）がインストールされ、該当するクレームプロバイダやリライングパーティとの間の信頼関係を含め、展開ガイド(英語)に基づくコンフィグレーション設定が適宜行われていることを前提としています。また読者にはBIG-IP LTMモジュールの管理に関して一般的な知識があることを想定しています。詳細やガイドが必要な場合はF5のサポートサイトASKF5（英語）を参照してください。 先のセクションでは、社内のADFSサーバファームを対象とした負荷分散の設定を行いました。このシナリオは社内ユーザにフェデレーション化されたSSOアクセスを提供する場合に機能します。しかし社外（つまりリモート環境）にいるユーザがフェデレーション化されたリソースにアクセスしようとする場合には対応できません。この場合にはADFS Proxyサーバが役立ちます。ADFS Proxyサーバを使用することにより、社外のユーザは社内のフェデレーションに対応したリソースに加え、Microsoft Office 365などのパートナーリソースにもアクセスすることができます。 クライアントがADFS対応の社外リソースへのアクセスを試みます。 クライアントはそのリソースのフェデレーションサービスにリダイレクトされます。 クライアントは社内のフェデレーションサービスにリダイレクトされます（リソースのフェデレーションサービスが信頼できるパートナーとして設定されていることが前提）。 ADFSProxyサーバはクライアントにカスタマイズ可能なサインオンページを表示します。 ADFSProxyは承認のためエンドユーザの証明書をADFSサーバに提示します。 ADFSサーバはそのクライアントをアクティブディレクトリについて認証します。 ADFSサーバはクライアントに対し、署名済みのセキュリティトークンとリソースパートナーへのクレームセットを含む認証クッキーを（ADFSProxyサーバ経由で）クライアントに提供します。 クライアントはリソースパートナーのフェデレーションサービスに接続し、そこでトークンとクレームが検証されます。該当する場合にはリソースパートナーが新しいセキュリティトークンをクライアントに提供します。 クライアントは新しい認証クッキーをそれに含まれるセキュリティトークンと共にリソースに提示してアクセスを行います。 仮想サーバとプールメンバー - 仮想サーバ（VIP）はポート443（https）を監視するよう設定されます。Big-IP SSLブリッジング（暗号化解除と再暗号化）に使用される場合、Big-IPと関連して作成されるクライアントSSLプロファイルに、パブリック側を向いたSSLとそれに伴う秘密鍵をインストールしておく必要があります。 ADFSはTransport Layer SecurityとSecure Sockets Layer（TLS/SSL）を必要とします。したがってプールのメンバーはポート443（https）を監視するよう設定されます。 負荷分散手法 - 「Least Connections（メンバー）」方式を使用します。 プールモニター - ADFSサービスとウェブサイト自体が応答していることを確認するため、ADFSProxyプールにはカスタマイズしたモニターを関連付けます。このモニターは間隔とタイムアウト設定を高めて使用します。 「SSLトンネルを使うべきか否か」 SSLトンネリングを使用した場合、暗号化されたトラフィックがクライアントからエンドポイントであるファームのメンバーに直接流れます。またSSLプロファイルは使用せず、SSL証明書をBig-IPにインストールする必要もありません。ただしトンネリングを使用する場合、HTTP圧縮やウェブアクセラレーションなどを含む高度な最適化は行えません。クライアントの接続性やADFSサインオンページのカスタマイズなどの状況によっては、ADFSProxy展開にこのようなHTTP最適化が貢献する場合もあります。以下に2種類の選択肢（SSLトンネリングとSSLブリッジング）を比較します。 SSLトンネリング - この場合にはパケット分析または変更（例：圧縮、ウェブアクセラレーション）またはその両方を必要とするBig-IPプロファイルは意味を持ちません。さらにパフォーマンスを高めるためにはFast L4仮想サーバを使用します。SSLトンネリングを使用した場合の、Fast L4 Big-IP仮想サーバのコンフィグレーション例を下図に示します。 SSLブリッジング - SSLブリッジングを使用した場合、トラフィックは暗号化を解除され、次いでBig-IPデバイスにて再暗号化されます。これにより、接続の中のクライアントに対応する部分とプールメンバーに対応する部分の両方においてトラフィックにさらに機能を適用することが可能になります。SSLブリッジングを使用した場合の、標準的なBig-IP仮想サーバのコンフィグレーション例を下図に示します。 標準的な仮想サーバのプロファイル - ADFSProxy仮想サーバのプロファイルのリストを下表に示しています。 プロファイルのタイプ コメント パーシステンス 仮想サーバにはデフォルトのクッキーパーシステンスプロファイルを関連付け SSLクライアント パブリック側を向いたSSLとそれに伴う秘密鍵をBig-IPにインストール。 これによりBig-IPでのトラフィックのSSL終端が容易に SSLサーバ 仮想サーバにはデフォルトの「serverssl」プロファイルを関連付け プロトコル tcp-lan-optimizedプロファイルを仮想サーバのサーバ側に関連付け tcp-wan-optimized プロファイルを仮想サーバのサーバ側に関連付け OneConnect 仮想サーバにはデフォルトのoneconnectプロファイルを関連付け HTTP 仮想サーバにはデフォルトのHTTPプロファイルを関連付け HTTP圧縮 wan-optimized-compressionプロファイルを仮想サーバに関連付け ウェブアクセラレーション optimized-cachingプロファイルを仮想サーバに関連付け これでパート1は終了です。この文の草稿を読んでコメントを提供してくれた、Insightの子会社であるEnsynch（英語）のケビン ジェイムズ、デイビッド ランデル、およびルツ ミューラー ヒッパーに対し、マイクロソフトのグローバルパートナーシップを担当するF5ビジネス開発チームと共に心から感謝を捧げます。 Big-IPとADFSパート2「APM - ADFSProxyに代わる選択肢」をお楽しみにお待ちください。
BIG-IP APMとPassLogicを連携させて端末固有情報の登録を自動化する方法
Technorati タグ: APM,BIG-IP,iRules SSLVPN利用基盤の構築においてクライアント証明書を用いずにデバイスの制限を簡易な運用で実現できる仕組みを検討されており、下記のような要件があったとします。 ・SSLVPNを利用したい ・リスト型攻撃によるアカウント乗っ取りを防ぐ目的でワンタイムパスワードを利用したい ・メールを受信する形のワンタイムパスワードはそもそもメールを受信するシステムへのログインに使用するなど、メールが受信できない環境でのログインができないため今回は検討対象外 ・ユーザーに許可したデバイス以外からのアクセスは禁止したい ・デバイス登録のためにデバイス固有情報を1台1台調べて登録する作業は防ぎたい ・デバイスの特定のためにクライアント証明書による認証はSSLを終端するタイプのProxy経由でのアクセスもあることと、運用管理がより煩雑になるため行いたくない ・1ユーザーが使用するデバイスはひとり1台ではなくMac, Windows, Linux, iOS, Androidがあり最大5台(うちiOS/Androidは最大2台) ・ユーザーに紐づけるデバイスではなく、あらかじめ登録してある共有用デバイス (PC, Windows, iOS, Android)からのログインは無条件に認めたい ・ジェイルブレイクされたiOS端末、Android端末の登録は許可しない BIG-IP Access Policy Manager (以下APM)とパスロジ社のPassLogic Enterprise Edition 2.3.0(以下PassLogic)、そして本記事で紹介するAPMのAccess ProfileとiRulesでPassLogicのAPIと連携することでこれらの要件を満たすことができます。 システム要件 PassLogic Enterprise Edition 2.3.0 BIG-IP Access Policy Manager (APM) v12.0 HF1 このiRulesでは、Sideband Connectionを使用してAPMセッション変数のPassLogicのRADIUS Attribute登録を実現しています。 Technorati タグ: Japan 本設定サンプルでは、各OSで取得可能なデバイス固有情報 ・(任意の)NICのMACアドレス (Windows, Mac, Linux) session.machine_info.last.net_adapter.list.[0].mac_address ・マザーボードのシリアル番号 (Windowsのみ) session.machine_info.last.motherboard.sn ・(任意の)ハードディスクドライブのシリアル番号 (Windowsのみ) session.machine_info.last.hdd.list.[0].sn 詳しくは About Machine Info https://support.f5.com/kb/en-us/products/big-ip_apm/manuals/product/apm-visual-policy-editor-12-0-0/4.html も合わせてご参照ください。 ・iOSのUDID session.client.unique_id 詳しくは Support for using the BIG-IP Edge Client to check identifying information from Apple iOS client devices https://support.f5.com/kb/en-us/solutions/public/12000/700/sol12749.html も合わせてご参照ください。 ・AndroidのUnique ID session.client.unique_id 詳しくは Overview of session variable support for BIG-IP Edge Client for Android devices https://support.f5.com/kb/en-us/solutions/public/13000/700/sol13731.html も合わせてご参照ください。 APMでは下記のようなポリシーを作成し、Access ProfileからiRulesイベントを呼び出します。 iRulesではAPMセッション変数を使用してPassLogicのRADIUS Attributeへ情報を登録します。 when RULE_INIT { # Set the IP:Port of PassLogic Enterprise Edition set static::passlogicip "192.168.10.201" set static::passlogicport 7080 } when ACCESS_POLICY_AGENT_EVENT { # Check Shared Device (Required to set HW Info to DataGroup SharedDevices HWInfo:=DeviceKind) if { [ACCESS::policy agent_id] eq "IsSharedDevice" } { set uname [ACCESS::session data get session.logon.last.username] set hwinfo [ACCESS::session data get session.passlogic.hwinfo] set devkind0 [ACCESS::session data get session.passlogic.devicekind] if { [class match -value $hwinfo eq SharedDevices] eq $devkind0 } { log local0. "User $uname is accessed with shared device kind=$devkind ($hwinfo)" ACCESS::session data set session.isshareddevice "yes" } else { log local0. "User $uname is accessed with non-shared device kind=$devkind0 ($hwinfo)" ACCESS::session data set session.isshareddevice "no" } } # Device HW Information will be registed to PassLogic RADIUS Attribute if { [ACCESS::policy agent_id] eq "RegistHWInfoToPassLogic" } { # Get APM session variables set uname [ACCESS::session data get session.logon.last.username] set dom [ACCESS::session data get session.logon.last.domain] set rattr [ACCESS::session data get session.passlogic.attr] set devkind [ACCESS::session data get session.passlogic.devicekind] set hwinfo [ACCESS::session data get session.passlogic.hwinfo] set rewrite9 [ACCESS::session data get session.passlogi.setrewrite9] set newattr "" log local0. "username = $uname device=$devkind hw=$hwinfo" log local0. "Old Attribute = $rattr" if { $rewrite9 eq "yes" } { log local0. "Rewrite not device kind ($devkind) but any device (9)" set devkind 9 } # flag for change attribute set addd 0 foreach i [split $rattr |] { if { $i eq $devkind } { if { $addd == 0 } { # Generate new attribute data for regist new device set tstr $newattr set newattr "$tstr$hwinfo|" set addd 1 } else { set tstr $newattr set newattr "$tstr$i|" } } else { set tstr $newattr set newattr "$tstr$i|" } } if { $addd == 1 } { log local0. "New DeviceID ($hwinfo) for user $uname will be registered to PassLogic. New RADIUS Attribute=$newattr" set conn [connect -timeout 3000 -idle 30 -status conn_status $static::passlogicip $static::passlogicport ] log local0. "Connect returns: <$conn> and conn status: <$conn_status> " set conn_info [connect info -idle -status $conn] log local0. "Connect info: <$conn_info>" set data "GET /passlogic/api/admin?mode=useredit&uid=$uname&domain=$dom&attribute1=$newattr HTTP/1.0\r\n\r\n" set send_info [send -timeout 3000 -status send_status $conn $data] log local0. "Sent <$send_info> bytes and send status: <$send_status>" set recv_data [recv -timeout 3000 -status recv_status 1024 $conn] log local0. "Recv data: <$recv_data> and recv status: <$recv_status>" close $conn log local0. "Closed; conn info: <[connect info -status $conn]>" log local0. "PassLogic response is correct." if { $recv_data contains "PassLogic" } { set ret [string range [findstr $recv_data " " 0 " "] 6 10] log local0. "Result Code = $ret" ACCESS::session data set session.passlogic.result $ret switch $ret { "50300"{ ACCESS::session data set session.passlogic.error "PassLogic Error: err Invalid input data." log local0. "PassLogic Error: err Invalid input data." } "50301"{ ACCESS::session data set session.passlogic.error "PassLogic Error: err The user does not exist." log local0. "PassLogic Error: err The user does not exist." } "50302"{ ACCESS::session data set session.passlogic.error "PassLogic Error: err Update parameter is required." log local0. "PassLogic Error: err Update parameter is required." } "50400"{ ACCESS::session data set session.passlogic.error "PassLogic Information: notice User information has updated successfully. New DeviceID ($hwinfo) for user $uname was registered." log local0. "PassLogic Information: notice User information has updated successfully. New DeviceID ($hwinfo) for user $uname was registered." } "50499"{ ACCESS::session data set session.passlogic.error "PassLogic Error: crit System error occurred." log local0. "PassLogic Error: crit System error occurred." } } } } else { ACCESS::session data set session.passlogic.result "NG" } } } 詳しい設定手順やAccess Profile、iRulesサンプルは下記よりダウンロードできます。 https://f5.com/Portals/1/PDF/JAPAN/devcentral/PassLogic230_APM12_AP_iRule_v1.zipProtecting Beyond DNS Flood & DDoS
The recent slate of cyber-attacks involving DNS and NTP systems has again prompted questions about the comprehensiveness of DNS infrastructure’s security protection. Besides mitigating volumetric attacks such as DNS flood & DDoS, many organizations have realized the need for a more comprehensive DNS security protection, which helps in preventing DNS-related security frauds and non-volumetric based attacks such as amplification and cache poisoning attacks. On DNS Amplification & DNS Reflection Attacks You might concur that increasing DNS performance with adequate DNS rate limiting mechanism is probably one of the best approaches to tackle the problem of overwhelming DNS traffic and DNS DoS attacks. However, this does not address the issue of DNS Amplification and DNS reflection attacks, which has been made popular through the Spamhaus-Cyberbunker attack incident. In this incident, CyberBunker took the advantage of open DNS resolvers to launch DNS amplification attacks, causing Spamhaus to be unreachable at times. DNS amplification and reflection attacks are typically sent to DNS servers as legitimate DNS request, in hope to receive large data size responses. The huge data size responses will eventually use up all the available bandwidth causing congestion to genuine DNS queries and responses. As such, DNS query rate limiting mechanism and higher QPS performance will not be able to counter the attack since the attacks typically come in small numbers of DNS requests. One of the ways to limit such attacks is to filter the request based on query type. Typically, DNS amplification and reflection attacks will request for ‘TXT’ or ‘ANY’ Query Type which tends to return responses with significant data size. By applying bandwidth rate limit to these query type request and large-data-size query responses, we will be able to prevent bandwidth congestion caused by these attacks. Worried about the complexity of the bandwidth rate limiting solution? Well, it only takes less than 10 lines of iRules (shown as below) on F5 DNS platform to get this enforced and implemented. when DNS_REQUEST { if { ([DNS::question type] eq "TXT") } { rateclass dns_rate_shape } } when DNS_RESPONSE { if { ([DNS::len] value > 512) } { rateclass dns_rate_shape } } Diagram 1: DNS Reflection attacks blocking genuine users from accessing LDNS server. Cache Poisoning Attacks DNSSEC is poised as the eventual and ultimate solution to counter DNS cache poisoning attacks. Though the adoption rate of DNSSEC is encouraging, it takes all parties to deploy DNSSEC signing and validation to fully protect against cache poisoning. While waiting for DNSSEC adoption rate to mature, is there any interim solution to reduce or prevent cache poisoning attacks? Based on DNS RFC standards, name servers are required to treat domain names request with case-insensitivity. In other words, the names www.foo.com and WWW.FOO.COM should resolve to the same IP address. However, most name servers will preserve the original case when echoing back the domain name in the response. Hence, by randomly varying the case of characters in domain names queried, we will be able to add entropy to requests. With this verification mechanism, the name server response must match the exact upper and lower case of every character in the name string; for instance, wWw.f5.CoM or WwW.f5.COm, which significantly reduces the success rate of cache poisoning attacks. With F5’s DNS solution, this mechanism can be enabled with just a check box on the management pane. The packet capture of the query case randomization process by F5 DNS is shown as below. As depicted in the diagram, for queries to www.google.com, F5 Cache DNS will randomize the character case of the query prior sending the query to Google’s authoritative DNS server. This greatly reduces the chances of unsolicited queries matching the domain name and DNS request transaction ID, which causes the poisoning of cached DNS records. Diagram 2: Character case randomizer in F5 DNS solution dramatically reduces the possibilities of DNS cache poisoning attacks DNS is among the hoariest of internet services that is still widely used today. Its usage continues to grow due to its simplicity and proliferation of smart devices. Hence, it is truly important that proper solution design and architecture approach are being put in place to protect the infrastructure. After all, the protection investment might be only a fraction of what you are paying for during an attack.
BIG-IP ASMで対応するOWASP Top 10 - 2017年版
この投稿は、F5ネットワークスのシニア・ソリューション・デベロッパーであるPeter Silva のブログ投稿「The OWASP Top 10 - 2017 vs. BIG-IP ASM 」を元に、日本向けに再構成したものです。 OWASP Top 10の2017年正式版がリリースされましたので、BIG-IP ASMのWAF機能でどのくらい対応できるか概要を紹介したいと思います。 まず最初に、2013年版と2017年版の比較です。いくつかの新規項目の追加と、既存項目の統合が行われています。 では、BIG-IP ASMの対応状況を見ていきましょう。 Vulnerability BIG-IP ASM Controls A1 Injection Flaws インジェクション Attack signatures Meta character restrictions Parameter value length restrictions A2 Broken Authentication and Session Management 認証とセッション管理の不備 Brute Force protection Credentials Stuffing protection Login Enforcement Session tracking HTTP cookie tampering protection Session hijacking protection A3 Sensitive Data Exposure 機密データの露出 Data Guard Attack signatures (“Predictable Resource Location” and “Information Leakage”) A4 XML External Entities (XXE) XML外部実体参照(XXE) Attack signatures (“Other Application Attacks” - XXE) XML content profile (Disallow DTD) (Subset of API protection) A5 Broken Access Control アクセス制御の不備 File types Allowed/disallowed URLs Login Enforcement Session tracking Attack signatures (“Directory traversal”) A6 Security Misconfiguration セキュリティ設定のミス Attack Signatures DAST integration Allowed Methods HTML5 Cross-Domain Request Enforcement A7 Cross-site Scripting (XSS) クロスサイトスクリプティング(XSS) Attack signatures (“Cross Site Scripting (XSS)”) Parameter meta characters HttpOnly cookie attribute enforcement Parameter type definitions (such as integer) A8 Insecure Deserialization 安全でないデシリアライゼーション Attack Signatures (“Server Side Code Injection”) A9 Using components with known vulnerabilities 既知の脆弱性を持つコンポーネントの使用 Attack Signatures DAST integration A10 Insufficient Logging and Monitoring 不十分なロギングおよび監視 Request/response logging Attack alarm/block logging On-device logging and external logging to SIEM system Event Correlation 新規に追加された「A4: XML外部実体参照（XXE）」の項目についても、すでにシグネチャで対応しています。 200018018 External entity injection attempt 200018030 XML External Entity (XXE) injection attempt (Content) また、XXE攻撃は、XMLプロファイルによって汎用的な防御も可能です。 （DTDsを無効にして、"Malformed XML data"バイオレーションを有効にします） また「A8:安全でないデシリアライゼーション」の対応策として、こちらも多くのシグネチャがすでに提供されています。 これらシグネチャの多くは、下記のように“serialization” や“serialized object” といった名前が含まれています。 200004188 PHP object serialization injection attempt (Parameter) 200003425 Java Base64 serialized object - java/lang/Runtime (Parameter) 200004282 Node.js Serialized Object Remote Code Execution (Parameter) 以上、OWASP Top10 2017年版のリリースにともなう、BIG-IP ASMのWAF機能の対応状況のご紹介でした。 関連リンク： What’s New In The OWASP Top 10 And How TO Use It BIG-IP ASM Operations GuideBig-IPとADFSパート2 - APM - ADFS Proxyに代わる選択肢
このパートではADC（Application Delivery Controller）について説明します。先のパート1ではBig-IPの優れた負荷分散機能を使って社内ADFSファームと境界部ADFSProxyファームの両方を展開することにより、ハイアベイラビリティと拡張性を確保しました。しかしBig-IPはこれ以外にもさまざまな方法でアプリケーションデリバリに貢献します。このパート2ではADFSProxyレイヤの代わりとしてAccess Policy Manager（APM） モジュールを使用します。この手法の事例として、最も一般的な使用ケースであるウェブベースのMicrosoft Office 365（英語）アプリケーションとフェデレーション化を行い、このアプリケーションへのシングルサインオンを可能にするためADFSを展開する場合を考えてみます。 このADFSProxyサーバの目的は、インターネットからアクセスできないADFSサーバへの要求を受領し、それを転送することです。パート1で述べたように、ハイアベイラビリティを実現するには少なくとも2台のプロキシサーバに加えて負荷分散ソリューション（もちろんF5 Big-IP）が必要です。F5のアプライアンスにAPMを実装することにより、これらのサーバが不要になるだけでなく、境界部で事前承認を行い、またクライアントサイドでのチェックなど高度な機能（アンチウィルスのバリデーション、ファイアウォールの検証など）の導入によりおそらくよりセキュリティを強化した展開が実現します。 前提事項および製品展開のための資料 - この展開シナリオでは、読者にBIG-IP LTMモジュールの管理に関する一般的な知識と、APMモジュールに関する基本的な理解があることを想定しています。詳細やガイドが必要な場合はF5のサポートサイトASKF5（英語）を参照してください。下図は社内外のクライアントがADFS経由でOffice 365にアクセスする場合の典型的なプロセスフローを示しています（受動的制御、「ウェブベース」のアクセス）。 両方のクライアントがOffice 365リソースへのアクセスを試みます。 両方のクライアントがそのリソースのフェデレーションサービスにリダイレクトされます（注：このステップはMicrosoft Outlookなどのアクティブクライアントの場合には省略されることがあります）。 両方のクライアントは社内のフェデレーションサービスにリダイレクトされます。 ADFSサーバがアクティブディレクトリに対してクライアントを認証します。 ・社内クライアントはADFSサーバファームのメンバーに直接負荷分散されます。 ・社外のクライアントは： - APMのカスタマイズ可能なサインオンページ経由でActive Directoryに対し事前認証されます。 - 認証されたユーザはADFSサーバファームのメンバーにリダイレクトされます。 ADFSサーバは、署名済みのセキュリティトークンとリソースパートナーへのクレームセットを含む認証クッキーをクライアントに提供します。 クライアントはMicrosoft Federation Gatewayに接続し、そこでトークンとクレームが検証されます。Microsoft Federation Gatewayが新しいセキュリティトークンをクライアントに提供します。 クライアントは新しい認証クッキーをそれに含まれるセキュリティトークンと共にOffice 365リソースに提示してアクセスを行います。 仮想サーバとプールメンバー - （社内と社外の）すべてのユーザは同じBig-IPを経由してADFSサーバファームにアクセスしますが、その要件とそれ以降のユーザエクスペリエンスはそれぞれ異なります。社内の認証されたユーザはADFSサーバファームに直接負荷分散されますが、社外ユーザは（APM経由で事前承認を得た後にADFSファームのメンバーへのアクセスを許可されます。このため2つの仮想サーバが使用され、その1つは社内アクセスに、もう1つは社外からのアクセス専用となります。社内と社外の仮想サーバには、いずれも同じ社内ADFSサーバファームプールが関連付けられます。 社内の仮想サーバ - 社内ADFSファームの仮想サーバ設定については本シリーズのパート1をご覧ください。 社外の仮想サーバ - 社外の仮想サーバのコンフィグレーション設定は、本シリーズのパート1に記載した仮想サーバの場合と同様です。これに加え、APM Access Profile（下記設定のハイライト部分を参照）が仮想サーバに割り当てられます。 APMのコンフィグレーション設定 - 社外ユーザが社内のADFSファームへのアクセスを許可されるのに先立ち、以下のAccess Policy Manager（APM）コンフィグレーションが作成され、社外向けの仮想サーバに関連付けられます。先に述べたように、APMモジュールは事前承認に加え、クライアントサイドでのチェックやシングルサインオン（SSO）など高度な機能も提供します。もちろんこれらはさまざまな機能のほんの一部に過ぎません。ASKF5（英語）にはクライアントサイドのチェックに関する詳細が記載されています。 AAAサーバ - ADFSアクセスプロファイルはActive Directory AAAサーバを使用します。 アクセスポリシー - ADFSアクセスプロファイルには以下のアクセスポリシーが関連付けられています。 ログオンページの表示に先立ち、クライアントマシンにアップデート済みのアンチウィルスソフトウェアが存在するかチェックします。クライアントにアンチウィルスソフトウェアが存在しないか、あるいはウィルス定義が（30日以内に）アップデートされていない場合、ユーザはリダイレクトされます。 オンプレミスとOffice365 ExchangeユーザのいずれにもシングルURLのOWAアクセスを提供するため、ADクエリとシンプルなiRulesが使用されます。 SSO のコンフィグレーション - ADFSアクセスポータルは複数の認証ドメインについてNTLM v1 SSO プロファイルを使用します（下図参照）。複数のSSO ドメインを使用することにより、クライアントは一度認証するだけでExchange OnlineやSharePoint Onlineなどホストされたアプリケーションと、オンプレミスでホストされたアプリケーションの両方にアクセスすることができます。これをさらに促進するには同じSSOコンフィグレーションを使う複数の仮想サーバ（ADFS、Exchange、SharePoint）を展開します。 接続プロファイル - デフォルトの接続プロファイルをベースとする接続プロファイルが社外仮想サーバに関連付けられます。 たくさんの情報が含まれていましたがいかがでしたでしょうか。これがAPMや負荷分散以外にBig-IPを使って行えるさまざまなことについて、さらに理解を深めるきっかけとなったことを期待しています。DevCentralとは
ようこそ DevCentral は、F5 コミュニティが問題を解決するために協力し、答えを見つけ出す場所です。ここには、マーケティング資料や宣伝文句はなく、営業担当者もいません。DevCentral にあるのは、コードや構成、そして成長を続けるコミュニティで、F5 の製品を使った優れたソリューションの構築に情熱を注ぐ 18 万人超のメンバーで構成されています。 コーディングはとりたて IT プロの好奇心をくすぐりますが、DevCentral では iRules、iControl、iApps、tmsh など F5 の拡張技術の最新情報を見つけることができます。高度な設計や構成に関する広範な情報からカスタマイズされたモニタの情報まで、DevCentral には F5 の最先端のあらゆるノウハウが蓄積され、求めている情報が見つかるものと思われます。 他のメンバーと積極的に交流し、経験や関心や知識を共有します。基本的な疑問から極めて難解な問題まで、DevCentral では高い確率で解決策が見つかります。 F5 の新規ユーザこのボタンは優れた開発への特急券です。ここをクリックすれば、新開発に必要な情報が手に入ります。 利用を開始する際には、以下の各種コンテンツを確認します。 F5 のエキスパートによる記事 世の中には専門分野に精通し、その知識について語ってくれる人がいます。何百本もの記事には、問題を今すぐ解決するための技術的なヒントから、業界の現状を掌握できる傑出したブログまで、思いつく限りの内容が詳しく説明されています。F5 のエキスパートが、何が機能して何が機能せず、何が可能か、そして時には何が面白いかを書き連ねています。 膨大な API ドキュメントを秘蔵 この巨大な貯蔵庫には、 iRules、iControl、iApps の正式ドキュメントのほか、tmsh や設計および構成の高度な技法など、確固たる情報が保管されています。また、メンバーが協力してコードの投稿やブラウズ、再利用に取り組むコードシェアも開設されています。 何でもありの Q&A Q&A は DevCentral におけるディスカッションの中枢です。質問するもよし、答えを探すもよし、アイデアを議論するものよし......、思い悩んだら何でも相談します。何万件にものぼるユーザの投稿は広範に及んでいます。このコミュニテイでは多数のユーザによって活発な議論が交わされているため、質問を投稿した後待ちぼうけになることがありません。 ダウンロード可能な豊富な情報 DevCentral では体裁の整った各種ドキュメントもダウンロードできます。テンプレート、スクリプトエディタ、クイックスタートガイド、iApp、そして不動の人気を誇る iRules Editor など、極めて便利なツールが揃っています。 エキスパートによるエキスパートのためのビデオ DevCentral や業界のホットな情報をビデオやポッドキャストでお伝えします。ユーザの訪問インタビューや技術的なチュートリアルでも、「今週の一押し投稿」を掘り下げる DevCentral Podcast でも、ユーザにとって関心の高い内容をエキスパートがエキスパートに伝達します。 今後のイベント たまにはコンピュータから離れてみるのもいいものです。世界の各地で、コミュニティの座談会、インタビュー、ユーザグループ ミーティングが開催されており、他にも多数の企画が実施されています。イベントカレンダーのリストをご覧ください。IoTのセキュリティリスク Top 10 とそれらへの対応方法
このブログでもすでに何度か触れていますが、Webアプリケーションのセキュリティ向上を目的としたプロジェクトとして、OWASP（Open Web Application Security Project）というものがあります。OWASPはWebアプリケーションのセキュリティリスクに対し、全世界の個人や企業、その他の組織が適切な情報に基づく判断を行えるよう、セキュリティを取り巻く状況の可視化や、ベストプラクティスやフレームワークの紹介等を行っています。 OWASPはこの活動の一環として、最もクリティカルとされる10種類のセキュルティリスクを「OWASP Top 10 リスト」としてまとめています。このリストにはそれぞれのリスクについての説明の他、脆弱性の事例、攻撃の事例、回避手段に関するガイド、関連情報へのリンクが記載されています。これは優れたリストであり、セキュリティ関連ベンダーが「自社製品やサービスがどのようなタイプの攻撃を軽減できるのか」を示す際にも、引用されることが少なくありません。 OWASPではこれまでにもWebアプリケーションに関した「Top 10 Most Critical Web Application Security Risks」を公開していましたが、IoT（Internet of Things：モノのインターネット）に関しても同様の「OWASP Internet of Things (IoT) Top 10」(英語のみ)を作成し、公開しています。 IoTとは、身の回りにある様々なモノ、例えば冷蔵庫やトースターといった家電製品、寒暖計等のセンサー類、自動車等が、インターネットに接続されて互いにデータを送受信する世界を意味しています。このような家電製品や日用品によるインターネットアクセス実現に関心を持つベンダーを支援することが、「OWASP Internet of Things (IoT) Top 10」の目的です。このリストではIoT対応の機器やサービスのセキュリティリスクのうち、上位10項目を順に取り上げ、それぞれについての対応策を紹介しています。 ここでは2014年度の「OWASP Internet of Things Top 10」に含まれる項目を紹介すると共に、OWASPが示す対応策についてもまとめて掲載しておきます。 1 Insecure Web Interface（セキュリティが確保されていないWebインターフェイス） Webインターフェイスのセキュリティを確保するには： 最初のアカウント設定時に、パスワードをデフォルトのものから変更するよう、必ずユーザに要求してください。できればユーザ名も変更できるのが理想的です。 十分に堅牢なパスワード再設定メカニズムを実装してください。またパスワード再設定メカニズムや新規ユーザページなどから、正規アカウントの情報が特定できないようにしてください。 ウェブインターフェイスに、XSS（クロスサイトスクリプティング）やSQLインジェクション、CSRF（クロスサイトリクエストフォージェリ）への脆弱性が存在しないことを確認して下さい。 内部ネットワーク/外部ネットワークに関わらず、アカウント情報がネットワークトラフィックに露出しないようにしてください。 脆弱なパスワードは許可しないでください。またログインに3～5回失敗した場合には、そのアカウントをロックアウト（一時的に使用不可能に）してください。 2 Insufficient Authentication/Authorization（不十分な認証） 十分な強度を備えた認証を実現するには： 「1234」などの簡単なものではなく、推測されにくい強力なパスワードを要求してください。 アカウント情報がプレーンテキストで伝送されていないことを確認してください。 パスワードの複雑度設定や使用履歴の確認、有効期限設定等、パスワード制御に関する必要機能を実装してください。また新規ユーザの場合には、必ずパスワード変更を強制してください。 漏洩によって重大な問題を引き起こす機密性の高い情報にアクセスする場合には、ユーザの再認証を要求してください。 インターフェイスがユーザのロール（役割）に応じて分離可能であることを確認してください。例えばアドミニストレータは全ての機能にアクセスできる一方で、一般ユーザはアクセス可能な機能を制限する、といった対応が必要です。 ユーザが本来持っている権限を超えた権限を取得できる「特権昇格（privilege escalation）」が行えないことを確認してください。 必要であれば、よりきめ細かいアクセス制御を導入してください。 アカウント情報が適切に保護されていることを確認してください。 必要に応じて二要素認証（ニ段階認証）を実装してください。 パスワード再設定メカニズムが安全であることを確認してください。 パスワード制御の設定に関しては複数の選択肢を用意してください。 3 Insecure Network Services（セキュリティが確保されていないネットワークサービス） ネットワークサービスのセキュリティを確保するには： 使用機器が開いているポートを、ポートスキャナで確認してください。開いているポートについては、DoS攻撃やバッファオーバフロー、ファジング攻撃への脆弱性や、UDPサービス関連の脆弱性等をテストした上で、必要最小限のポートのみを開けてください。 提供サービスにバッファオーバフローやファジング攻撃、DoS攻撃などへの脆弱性が存在しないことを確認してください。 ネットワークポートやサービスが、UPnP等によってインターネットから直接アクセスできる状態になっていないことを確認してください。 4 Lack of Transport Encryption（暗号化されていないトランスポート） トランスポートに十分な暗号化を行うには： 各種デバイスやその上で動くモバイルアプリケーション、クラウド接続のトラフィックについて、情報がプレーンテキストで送られていないことを確認してください。ネットワーク上で情報をやり取りする場合には、SSLやTLSなどのプロトコルを使って暗号化してください。 使用しているSSLやTLSが最新であり、かつ正しく実装されていることを確認してください。 SSLやTLSが使用できない場合には、他の業界標準の暗号化技術を活用し、伝送路におけるデータ保護を行ってください。 一般に推奨され認められている暗号化プロトコルのみが使用されていることを確認してください。 5 Privacy Concerns（プライバシーに関する懸念） プライバシーに関する懸念を最小限に抑えるには： 各種デバイスやその上で動くモバイルアプリケーション、クラウドインターフェイスが、それらの機能にとって必要最小限の情報のみ収集していることを確認してください。 収集するデータは、機密保持の必要性が比較的低いもののみに制限してください。 適切に暗号化されていない個人情報を、ストレージ等に保存あるいはネットワークで伝送すると、読み取られる危険があります。収集した全てのデータは、適切な暗号化によって保護してください。 収集した情報は、個人を特定できない状態にしてください。 収集した個人データには、承認を受けた者のみがアクセスできるようにしてください。 収集したデータには、保持期限を設定してください。 製品機能やサービスの提供等に必要と想定される範囲を超えるデータを収集する場合には、エンドユーザにそれに関する「通知と選択肢」を提供する必要があります。 6 Insecure Cloud Interface（セキュリティが確保されていないクラウドインターフェイス） クラウドインターフェイスのセキュリティを確保するには： 最初のアカウント設定時に、パスワードをデフォルトのものから変更するよう、必ずユーザに要求してください。できればユーザ名も変更できるのが理想的です。 ログインに3～5回失敗した場合には、そのアカウントをロックアウト（一時的に使用不可能に）してください。 パスワード再設定メカニズムや新規ユーザページなどから、正規アカウントの情報が特定できないようにしてください。 クラウドインターフェイスに、XSS（クロスサイトスクリプティング）やSQLインジェクション、CSRF（クロスサイトリクエストフォージェリ）への脆弱性が存在しないことを確認して下さい。これは、全てのクラウドインターフェイス（APIインターフェイスとクラウドベースのWebインターフェイス）について検証する必要があります。 アカウント情報がインターネットに露出していないことを確認して下さい。 もし可能であれば、二要素認証（ニ段階認証）を実装してください。 7 Insecure Mobile Interface（セキュリティが確保されていないモバイルインターフェイス） モバイルインターフェイスのセキュリティを確保するには： 最初のアカウント設定時に、パスワードをデフォルトのものから変更するよう、必ずユーザに要求してください。できればユーザ名も変更できるのが理想的です。 パスワード再設定メカニズム等の機能を使用することで、ユーザアカウントが列挙表示されないことを確認してください。 ログインに3～5回失敗した場合には、そのアカウントをロックアウト（一時的に使用不可能に）してください。 パスワード再設定メカニズムや新規ユーザページなどから、正規アカウントの情報が特定できないようにしてください。 アカウント情報がワイヤレスネットワーク上で盗聴できないことを確認してください。 もし可能であれば、二要素認証（二段階認証）を実装してください。 8 Insufficient Security Configurability（不十分なセキュリティ設定） 不十分なセキュリティ設定を改善するには： 機器の管理インターフェイスを見直し、より強力なパスワードの使用を必須としてください。 管理ユーザと通常のユーザを分離する仕組みを導入してください。 保管と伝送の両方の状態においてデータを暗号化してください。 セキュリティ関連のイベントをログとして残す機能を導入してください。 セキュリティ関連のイベントが発生した際に、アラートや通知をエンドユーザに送信する仕組みを導入してください。 9 Insecure Software/Firmware（セキュリティが確保されていないソフトウェア/ファームウェア） ソフトウェア/ファームウェアのセキュリティを確保するには： 最も重要なことは、機器自体がアップデート機能を実装しており、定期的にアップデート可能であることです。まず使用機器がこの条件を満たしていることを確認してください。 アップデートファイル中の重要な情報が、バイナリエディタ等を使用することで可読状態にならないことを確認してください。 アップデートファイルが、一般に認められたアルゴリズムを使用し、正しく暗号化されていることを確認してください。 アップデートファイルが、暗号化された接続によって送信されていることを確認してください。 アップデート用サーバに脆弱性がなく、適切に設定され、セキュアな状態であることを確認してください。 アップデートファイルが、アップロード/適用される前に正しく署名され、その内容が検証されていることを確認してください。 10 Poor Physical Security（物理的セキュリティの脆弱さ） 物理的セキュリティを強化するには： 機器類が容易に分解できない状態になっていることを確認してください。 データ保存用のメディアが容易に取り出せない状態になっていることを確認してください。 保管時のデータが暗号化されていることを確認してください。 USBなどの外部ポートを使って不正に機器にアクセスできないことを確認してください。 運用に本当に必要な外部ポートのみが装備されていることを確認してください。 管理機能がローカルなアクセスのみに制限できることを確認してください。 ここでは各項目に関する対応策を掲載しましたが、OWASPのそれぞれのページでは、攻撃者が攻撃可能となる条件、攻撃手法や侵入経路、脆弱性がどのような状況で生じるのか、技術面とビジネス面へのインパクト（影響）についても解説されています。また攻撃シナリオのサンプルも掲載されています。ぜひ目を通されるようお薦めします。BIG-IPとADFSパート3 - 「ADFS、APM、およびOffice 365シッククライアント」
パート3があるという話はしていませんでした。しかしこのシリーズの内容はパート2で止めておくには面白すぎますし、実はカバーしておくべき重要なセクションがもうひとつありました。 まず、パート1と2について簡単に復習します。パート1ではADFSとADFSProxyファームの負荷分散による、ハイアベイラビリティと拡張性の確保について説明しました。パート2では、ADFSProxyレイヤの代替としてのAccess Policy Manager（APM）（英語）を取り上げました。この方法はソリューションのセキュリティと柔軟性を高めるだけでなく、インフラストラクチャの簡素化にも貢献します。 このシリーズをフォローしていただいた方なら（たぶん）覚えておられるように、パート2ではOffice 365をユースケースとして、Big-IPとAPMがどのようにOutlook Web Access（OWA）へのSSOサインオンを実現するかを示しました。しかしOutlookとLyncクライアントを含むシッククライアント（thick client - アクティブなプロトコルとアクティブなプロファイル）の場合にはもう少し状況が複雑になります。以下にこれを説明します。 パッシブプロトコル - （Outlook Web App） WS-Federationパッシブプロトコルを使うクライアントの（主としてブラウザベースの）プロセスは以下のとおりです。 クライアントがOffice 365リソースへのアクセスを試みます。 クライアントはMicrosoft Federation Gatewayにリダイレクトされます。 クライアントは社内のフェデレーションサービス（ADFS）にリダイレクトされます。 ADFSサーバはこのクライアントをアクティブディレクトリに対して認証します。 ADFSサーバはクライアントに対し署名済みのセキュリティトークンとリソースパートナーへのクレームセットを含む認証クッキーをクライアントに提供します。 クライアントはMicrosoft Federation Gatewayに接続し、そこでトークンとクレームが検証されます。Microsoft Federation Gatewayは新しいセキュリティトークンをクライアントに提供します。 クライアントは新しい認証クッキーをそれに含まれるセキュリティトークンと共にOffice 365リソースに提示してアクセスを行います。 上記のケースでは、ADFSはWS-FederationプロトコルとSAMLを使用しています。このタイプの接続は、一般にBIG-IPのAPMを使ってADFSへの接続をプロキシ化することによって大きく改善されます。 アクティブプロトコル - （OutlookおよびLyncクライアント） OutlookやLyncのようなクライアント（外部クライアント）によるやり取りは少し異なります。この場合のプロセスはアクティブプロトコル、WS-Trust、およびSOAPを使用します。 クライアントがOffice 365リソースへのアクセスを試み、認証情報を提供します。 Office 365はMicrosoft Federation Gatewayに認証を求めます。 Microsoft Federation Gatewayはクライアントに代わってADFSサービスに連絡し、認証情報を提示します。 ADFSはクライアントの認証情報をアクティブディレクトリにより認証します。 ADFSはMicrosoft Federation Gatewayにトークンを提供します。 Microsoft Federation GatewayはOffice 365にトークンを提供し、クライアントによるリソースへのアクセスを可能にします。 簡単に言えば、クライアントがADFSにトークンを要求して取得するための作業を行う代わりに、Microsoft Federation GatewayがADFSとのやり取りを直接行います。クライアントはADFSとは接続しないため、APM（またはどのプロキシサービスも）は使用できません。 ここで問題が生じます。Big-IP APMの背後でADFSを展開している場合、シッククライアント（OutlookやLync）の認証のためMicrosoft Federation Gatewayが直接アクセスを行い、かつパッシブな接続（ブラウザベースと社内のLync）については事前認証を行えるようにするにはどうすれば良いでしょうか？これはiRuleを使うことにより簡単に解決できます。 APMはiRuleをバイパス MS Federation Gatewayに直接アクセスできるよう、iRuleをひとつ作成し、それを本シリーズのパート2で作成したADFS仮想サーバに割り当てます。このiRuleはHTTP_REQUEST（英語）イベント（システムがHTTPリクエストのパーシングを行うことによって起動）を使ってURIを分析します。適切なリクエストを受領するとACCESS::disable（英語）コマンドが呼び出されてアクセスポリシーが無効になり、リクエストの通過が許可されます。サードパーティ製プロキシの要件についてはマイクロソフトが発行するガイドも参照してください。以下の基本的なiRuleを作成し、社外のADFS仮想サーバに割り当ててみてください。 1: when HTTP_REQUEST { 2: 3: # For external Lync client access all external requests to the 4: # /trust/mex URL must be routed to /trust/proxymex. Analyze and modify the URI 5: # where appropriate 6: HTTP::uri [string map {/trust/mex /trust/proxymex} [HTTP::uri]] 7: 8: # Analyze the HTTP request and disable access policy enforcement WS-Trust calls 9: if {[HTTP::uri] contains "/adfs/services/trust"} { 10: ACCESS::disable 11: } 12: 13: # OPTIONAL ---- To allow publishing of the federation service metadata 14: if {[HTTP::uri] ends_with "FederationMetadata/2007-06/FederationMetadata.xml"} { 15: ACCESS::disable 16: } 17: } 以上です。単純明快ですね。ご自分で試してみてその結果を教えてください。ここでは社外からのアクセスを取り扱っているため、外部アクセスの識別とブロックのためのADFS 2.0のサポートについては触れませんでした。この高度な機能に関心がある場合はマイクロソフトが発行するガイド（英語）を参照してください。
Security is a process
A newspaper report recently warned that many IT products and applications, including payment systems, lack adequate security. The reasons cited are that firstly, security is treated as an afterthought, and secondly, because trained practitioners are not involved in the design and implementation. F5 views security as a process. It should be managed as such. There’s an important role for the security experts who build the policies that ensure security and compliance within the organization. And, there’s an equally important role for the programmers who develop the software. But the two are quite distinct from each other. Business applications are the critical assets of an enterprise. Its security should not be just left to the software engineers to decide because they are not security professionals. Therefore, the prudent approach is to offload the burden of coding security policies from the software programmers onto credible security solutions professionals. Viewed from that perspective, security is as an end-to-end process, with policies to govern the various areas wherever there is user interaction with the enterprise – device, access, network, application and storage. Given the complexities of the different moving parts, it sometimes makes sense to combine several of the point security concerns into a converged solution. In short, this is akin to process simplification not too different from what consultants would call “BPR" in the business world. However way, you see it, from a CFO perspective, this represents immense cost savings boh operationally as well as in capital costs. For example, when it comes to application security, the trend is to build it into the application delivery controllers. ADCs are designed to natively deliver applications securely to end users. In today’s context, ADCs act as secured gatekeepers to the applications; they prevent unauthorised access and are able to add-on capabilities to mitigate complex application level attacks such as those defined by OWASP. However, the situation is growing more complex. CIOs are increasingly faced with the task of balancing the needs of a younger, empowered and demanding Gen Y workforce who want the freedom to work from their device of choice as well as the ability to switch seamlessly between their social and enterprise networks. The CIO challenge is how to protect the company’s business assets in the face of increasing and more complex threats. Add to this the desire to leverage the cloud for cost control and scale and the security considerations can potentially spiral out of control. The situation calls for innovative security solutions that can understand the behaviour of enterprise applications as well as user behaviour, and be able to enforce corporate security policies effectively with minimum impact on user experience. F5 believes that security is a trust business. Having the right process and policies trumps choosing a vendor. It is the policies and process that determine the required solution, not vice versa. For a Japanese version of this post, please go here.
