BIG-IP Forward Proxy構成 ～ 導入の心得 ～/BIG-IP_Forward_Proxy

筆者のブログにもBIG-IP Forward Proxy関連の内容をまとめております。

BIG-IP Forward Proxyの作成資料一覧 - My Home NW Lab
https://myhomenwlab.hatenablog.com/entry/big-ip_forwad_proxy

Transcript

1. BIG-IPの Forward Proxy構成 ～ 導入の心得 ～ 初版作成日: 2021年02月12日 作成者: MyHomeNWLab
2. 筆者情報 • Name • MyHomeNWLab • Blog • https://myhomenwlab.hatenablog.com/ • Twitter • https://twitter.com/MyHomeNWLab • 座右の銘 • 仕事で触れないなら、自宅に導入して遊べばいいじゃない。 2 興味の赴くまま、技術を食い散らかします。
3. 本資料に関して • F5 Networks社のBIG-IPを、L3 ExplicitのForward Proxy構成で導入する際に必要 となる情報をまとめました。 • Proxyはカタカナ表記でプロキシ, プロクシ, プロキシー, プロクシーと表記される場合もあります が、本資料はその揺らぎを避けるために意図的に英語表記のProxyにしています。 • BIG-IPのバージョンは v15.1.1 系の情報を元にしています。 • SSL Orchestratorのバージョンは v15.1.0-7.5.2 系の情報を元にしています。 • v15.1.0- と記載がありますが、 v15.1.1 系向けのバージョンです。 3
4. 執筆意図 • BIG-IPのForward Proxy構成は、技術的な観点での情報が出回っていな かったため、筆者が苦労した点を踏まえて、導入における知っておくべき用途を 心得としてまとめました。 • Forward Proxy構成での導入事例はまだまだ少ないようですので、今後の バージョンアップに伴い、ユーザー要望が反映されていけば、大幅な改良がなさ れる可能性があります。そのため、最新の正確な情報を確認するようにしてくだ さい。 • より良い導入の手助けになれば幸いです。 4
5. 本資料の記載方針 • 本資料は構築手順書ではないため、設定手順の一つ一つまでは深堀し ません。 • 最大の理由は、自らの手で答えを導ける方でなければ、そもそもBIG-IP のForward Proxy構成を導入するのが難しいためです。 • そのため、導入にあたり鍵となる情報をメインで紹介します。 5
6. 心構え • 本資料はスライド数は多いものの、内容は必須中の必須のものしか扱っ ておりません。そのため、内容は全て理解して、常に把握しておく必要があ ります。 • 例えば、一つの改修を行おうとするならば、局所的に捉えると、考慮漏れ が誘発しやすくなります。そのため、全ての内容を脳内で処理して、影響 箇所や考慮点を全網羅的に洗い出す必要があります。 6
7. 目次 • 第1部 BIG-IPとForward Proxyの概要 • 第2部 BIG-IP Forward Proxy 標準実装 • 第3部 BIG-IP Forward Proxy SSLO実装 • 第4部 BIG-IP Forward Proxy 応用実装 • 第5部 まとめ • 付録 • 注記 • 標準実装, SSLO実装, 応用実装は、筆者が便宜的に名付けたものです。 13
8. 第1部 BIG-IPとForward Proxy の概要 14
9. BIG-IP全般 15
10. BIG-IPとは • F5 Networks社が販売する製品であり、LB (Load Balancer)として 名高いです。 • 多種多様なモジュールがあり、その中でもLBの機能を基軸としたLTM (Local Traffic Manager)が有名です。 • iRulesと呼ばれるスクリプト言語ベースで機能を拡張できます。 16
11. 本資料で取り扱うモジュール • LTM (Local Traffic Manager) • LBを基軸としたモジュールですが、Forward Proxy構成でも用いられます。 • APM (Access Policy Manager) • アクセス制御を担うモジュールです。汎用的な機能であるため、様々な構成で用いられる可能性が あります。特段、SSL-VPNで用いられる事例が多いように見受けられます。 • SSLO (SSL Orchestrator) • 他社メーカーのセキュリティ機器との連携を視野に入れたSSLの可視化を担うモジュールです。 • Orchestratorの名の通りに、複雑になりがちな設定のデプロイ(展開)を簡易化します。 17
12. 18 赤枠で囲まれているのが本書で取り扱うモジュールです。
13. APM (Access Policy Manager)の特徴 • VPE (Visual Policy Editor)と呼ばれるフローチャート形式でアクセス制御を行うた めの機能が特徴的です。 • VPEでは2種類のアクセス制御のPolicyがあります。どちらもVPEで設定するため、外 観は似通ってますが、用途と設定可能な項目が異なります。 • Per-Session Policy (Access Profile) • 認証と認可の制御を担います。Forward Proxy構成では主に認証の方を担います。 • Per-Request Policy • Forward Proxy構成では、URLフィルタリングやSSL復号化の制御を担います。 • ユーザーの所属グループや所属サブネットに応じて、Allow Listの設定も可能なため、認可の制御も担えます。 19
14. 20 Per-Session Policy / Access Profileと Per-Request Policyと名前が似通っているので、 混同しないように注意してください。 APMのPolicy系のメニュー
15. 21 APMのPer-Session Policy (Access Profile)
16. 22 APMのPer-Request Policy
17. SSLO(SSL Orchestrator)の特徴 • Guided Configurationと呼ばれるセットアップ ガイドに基づいて、設定 のデプロイを担います。 • 他社メーカーとのセキュリティ機器との連携機能を持ち合わせていますが、 まずは「Forward Proxyとして顧客の要件が満たせるか？」が重要にな るため、本資料では掘り下げません。 • そのため、連携機能を用いない場合は、実質的に単なるセットアップ ガイ ドの使い方がメインになります。 23
18. 24 SSLOのConfigurationメニュー ※メインとなるメニュー
19. 25 SSLOのGuided Configuration(セットアップ ガイド)のメニュー
20. モジュールと”構成” • BIG-IPのモジュールにはいくつもの種類がありますが、そのモジュールのひとつ 取っても複数の”構成”に適用できます。 • 実際、Forward Proxy構成では、LB構成で有名なLTMや、SSL-VPN構 成で有名なAPMを主に用います。 • そのため、BIG-IPのモジュールの資料を見かけたら、どの”構成”を前提としてい る記事なのか？を念頭に置いて読む必要があります。 • LTMの資料を見かけたら、LB構成を前提としているのか？ • APMの資料を見かけたら、SSL-VPN構成を前提としているのか？ 26
21. Forward Proxy全般 27
22. BIG-IPとForward Proxyを知る • BIG-IPのForward Proxy構成では、実装対象のBIG-IPへの理解と、 Forward Proxyへの深い理解が必要になります。 • Forward Proxyが担う役割を実現するための機能を、BIG-IPの標準 機能にない場合は、自らの手で実装する必要があるためです。 • また、どのような機能をBIG-IPで実現するかにあたって、顧客が Forward Proxyに求める要件の整理も重要となってきます。 28
23. Forward Proxy【構成】における利点 • Forward Proxy【構成】の構成上の利点は主に下記となります。 • Internet (不特定多数)宛のWeb通信の送信元アドレスをForward Proxyに 絞れる。 • Forward Proxyによりアプリケーション層の情報を元にアクセス制御をきめ細かに 行える。 29
24. Forward Proxy構成における利点 Firewallを介したInternet直抜けの場合 30 Firewall Internet Web Server Web Server 悪意ある Web Server Client (Web Browser) Client (Web Browser) Client (Web Browser) Policy ID Action Protocol Source Address Source Port Destination Address Destination Port 1 Permit TCP Client Any Any 80, 443 ... 不特定多数(Any)のWeb ServerがInternet上には存在するため、 それらのサービスの恩恵を受けるには宛先をAnyで穴あけする必要があります。 しかし、それだと悪意あるWeb Serverに接続してしまう危険性がありますが、 Layer 4レベルまでのアクセス制御では、よりセキュアにするのは難しくなります。
25. Forward Proxy構成における利点 Forward Proxyが存在する場合 31 Firewall Internet Web Server Web Server 悪意ある Web Server Client (Web Browser) Client (Web Browser) Client (Web Browser) 送信元をForward Proxyにして、 Clientからは直接的にInternetへ抜けないようにします。 Forward Proxy Internet(不特定多数)宛の通信となるため、 基本的にはAnyのままになります。 ポートを 8080 等にして公開しているWebサイ トもあるため、必要に応じてAnyにします。 Policy ID Action Protocol Source Address Source Port Destination Address Destination Port 1 Permit TCP Forward Proxy Any Any 80, 443 ... 【Allow List / White List】 URL: https://www.google.com URL: https://www.yahoo.com Category: Information Layer 7レベルの情報を用いて、 アクセス制御はForward Proxyが担います。
26. Forward Proxy構成の注意点 32 Internet Client (Web Browser) Firewall Firewall Forward Proxy Web Server Web Server Web Server • Forward Proxy構成によるアクセス制御を念頭に置いていると、 Internet Breakoutのような直接Internetへ抜けようとする通信と相 性が悪くなります。利点だけではない点に注意が必要です。 【理想】 特定の通信をInternet直抜けにしたい。 (Internet Breakout) 【現実】 通常ではForward Proxy経由になるため、 特定の通信をPACファイルで除外する必要などが生じる。
27. Forward Proxyの役割の一例 • Forward Proxyを介して通信させると、一元的なアクセス制御を行えま す。 • 通信ログにより通信状況を把握し、後追いもしやすくなります。 • よく閲覧されるサイトの情報をキャッシュすることにより、通信量の削減やレ スポンスの向上を期待できます。 33
28. Forward Proxyの機能の一例 • URLフィルタリング • ユーザー認証 • SSL復号化 • キャッシュ (HTTP Cache / Web Cache) • 注記: 紹介する機能は一例でしかありません。先入観を持たずに、既存で顧客が利用している機能の 踏襲可否や、次期の更改や新規導入で求められている機能を確認してください。 34
29. URLフィルタリング • “宛先(URL)”に対して通信の許可や拒否の制御を行います。 • 要件によっては、送信元サブネットや所属グループの組み合わせが要求される 場合があります。例えば、営業システム(https://sales-sys.test/)には各営 業支店(10.0.X.0/24)からのSalesグループのみしかアクセスさせたくない等。 • その他にもHTTP MethodやUser Agentなども要素に含めたい場合は、 URLフィルタリングと言えども、”宛先(URL)”だけの要素ではなくなるため、どのよ うに実装できるか検討する必要があります。 35
30. ユーザー認証 • 「誰がどの情報にアクセスできるか？」を制御するために、「誰が」を識別す るためのユーザーの識別を行います。 • また、ユーザー単位では粒度が細かすぎるため、現実的には所属している グループ単位の制御を併用します。 • 認証方式はいくつかあるので、用途に応じて選びます。 36
31. SSL復号化 • HTTPSによる暗号化通信が一般化しており、そのままだと通信の中身を 確認できないため、管理者の制御下に置き難い課題があります。 • そのため、暗号化通信の中身をIntercept(傍受)して一度通信を紐解 き、中身を確認してから再暗号化して、通信させる処理をSSL復号化で 行います。 37
32. キャッシュ (HTTP Cache / Web Cache) • 回線帯域の節約や通信の高速化のために、Web通信をキャッシュします。 • BIG-IPではメモリ上にキャッシュするため、大容量データのキャッシュ向きで はありません。BIG-IPはディスク上にはキャッシュできません。 • 時代の変化と共に回線帯域も増強されており、セキュリティ強化のために アクセス制御の方が重要視されるニーズがあるため、BIG-IPの利用にお いては副次的な効果の期待に留めるのが現実的です。 38
33. 機能を特定の条件下で無効化する必要性 • 実際の運用では、Forward Proxyの機能を特定の条件下で無効化さ せる必要が出てくる場合があります。 • そのため、特定の条件をトリガーとして、機能の有効化と無効化ができる か否かが重要になります。 • 背景としては、不特定多数の様々なWebサーバへの接続の仲介を行う 性質があるが故に、相手方の仕様に合わせた調整が必要になるためです。 39
34. 機能を特定の条件下で無効化する例 #1 • 認証除外 (認証なし) • 認証が行えないツールの存在が想定されます。 • SSL復号化除外 • クライアント認証を行っているWebサイトの存在が想定されます。 • センシティブな情報が扱われているWebサイト(例: オンライン バンク)では、ユー ザーの通信の中身を見てしまわないように、SSL復号化の対象から除外が必要に なってくる可能性があります。 40
35. 機能を特定の条件下で無効化する例 #2 • サーバ証明書のチェックの除外(サーバ証明書チェックの無効化) • 通信先のWebサイトの仕様に応じて、サーバ証明書のチェックを無効化する必要 が想定されます。 • 例えば、ネットワーク機器の自己署名証明書で設定されたWeb UIへの接続があ ります。 • キャッシュ除外 (HTTP Cache除外 / Web Cache除外) • Webサイトの死活監視のヘルスチェックのために、常に最新の情報を得られるよう にキャッシュから除外する用途が想定されます。 41
36. 条件の要素 • 条件を付ける場合は、どのような要素が必要なのかを顧客要件から整理 してください。 • 例えば、認証除外で宛先FQDNを判断要素にしたい場合、APMのPer- Session Policy(Access Profile)に、宛先に関するItemが無いため、 iRulesでの実装の検討が必要となります。 • 必要な場合、今後の新しいバージョンでは対応しているか確認してください。 42
37. BIG-IPの構成と設計の観点 43
38. BIG-IPの構成による設計の違い • BIG-IPはLB構成とSSL-VPN構成が有名のため、Forward Proxy構 成での導入では、世に出回っているBIG-IPの情報に疑問を抱く必要が あります。 • また、BIG-IPの各設定のデフォルト値は、どの構成を前提としてチューニン グされたものかを意識して設計が必要になります。 44
39. 各構成の通信の向きの違い • LB構成とSSL-VPN構成に対して、Forward Proxy構成では通信の 向きが異なります。 • 言い換えると、LB構成とSSL-VPN構成はInbound通信ですが、 Forward Proxy構成はOutbound通信です。 • また、不特定多数の存在が始点になるか終点になるかの違いもあります。 45
40. 各構成と制御配下の違い • LB構成のWebサービスでは、不特定多数のClientから接続されるため、サービス管理者の 制御配下には置かれませんが、ClientのOSやWebブラウザのサポート対象をサービス利用規 約で絞れます。 • SSL-VPN構成では、正規ユーザーからのSSL-VPN Clientのみを認証して許可するため、 BYODで私物端末を持ち込む場合を除いて、比較的に制御配下に置き易いです • しかし、Forward Proxy構成では、宛先が不特定多数のInternet側に向くため、システム 管理者の制御配下から外れてしまい、宛先のWebサイトの仕様に合わせるしかありません。 46
41. 各構成における通信の向き 47 BIG-IP LB構成 Internet Web Server Client (Webブラウザ) BIG-IP SSL-VPN Internet 社内Server Client (SSL-VPN Client) BIG-IP Forward Proxy構成 Internet Client (Webブラウザ) Web Server 不特定多数が存在する環境 【Forward Proxy構成】 【SSL-VPN構成】 【LB構成のWebサービス】 Forward Proxy構成では、主に不特定多数が宛先となるため、 システム管理者の制御配下から外れざるをえない。
42. 不特定多数の考慮 • Internet上の不特定多数のWeb Serverは、様々な人や会社によって提供 されているため、基本的にサービスを受けたければ、相手側のサービス仕様に合 わせるしかありません。 • そのため、通信を介在するForward Proxyには、Webサイトの仕様に合わせ てパラメータの調整が可能な機能が求められます。 • 不特定多数のWebサービスの仕様を洗い出すのは現実的に不可能であるた め、既存環境でチューニングに利用している機能は、更改に伴い洗い出す必要 があります。 48 Web Server 我らのサービスを使いたければ、 我らのサービス仕様に合わせよ！ Web Server Web Server Web Server Web Server
43. 構成の違いを意識した設計例 • Webサイトのキャッシュを実現するためにWeb Acceleration Profileがあります。 • 一般的なLB構成では宛先がシステム部に限られるため、キャッシュの設計はWeb Server側のコンテンツなどを基準に設計できました。 • しかし、Forward Proxy構成では、不特定多数が宛先になり、キャッシュ可能なコン テンツもWebサービス側に大きく依存し、時代の変化も受けやすく一意に決め打ちす るのが難しくなります。 • また、 BIG-IPの仕様ではメモリ上でキャッシュするため、Forward Proxy構成での 大容量データのキャッシュには向いていません。 • そのため、意図的にデフォルト値のままの設計としておき、検証時や導入後に実際の 利用状況に応じて修正をかける案があります。 49
44. Web Server Web Server 構成による設計観点の違い 50 BIG-IP LB構成 Internet Web Server Client (Webブラウザ) BIG-IP Forward Proxy構成 Internet Client (Webブラウザ) Web Server 不特定多数が存在する環境 【Forward Proxy構成】 【LB構成のWebサービス】 不特定多数のWeb ServerがInternet上には存在するため、キャッシュ対象に際限がないです。 Web Server Web Server LB構成では、システム内のWeb Serverに限定されるため、 キャッシュ対象が有限的です。 Web Server Web Server Web Server Cache キャッシュ対象 増大 Cache
45. LTMで意識する設計 • LTMのモジュールは、Virtual Serverに各種Profileを紐付けて成り立っ ています。また、Profile内で条件指定を変更できない場合があります。 • 例えば、SSL証明書のチェック除外を行いたくても、SSL Server Profile 内では条件指定ができず、有効化と無効化のみしか選択できません。そ のため、APMのPer-Request PolicyのServer Cert StatusのItem を用いて条件分岐で挙動を変える実装が必要となります。 51
46. iRules 条件指定と挙動の変更例 52 Virtual Server Profile #X Profile #1 用途1 Profile #2 用途2 Profile #N 用途N VPE (Visual Policy Editor) - Per-Session Policy (Access Profile) - Per-Request Policy iRulesにより条件に応じて、 Profileを張り替えて特性を変える。 例: SSL::profile コマンド ・VPEで条件に応じて挙動を変える。 ・ItemでProfile内の設定値を変える。 設定X: Disabled ⇒ Enabled 例: SSLの復号化/復号化除外の切り替え iRulesにより条件に応じて、 Profile内の設定値を変える。
47. APMで意識する設計 • APMではVPEによりフローチャート形式で条件に応じたアクションを指定で きます。 • よって、何を条件の要素に指定できるか？が重要な要素となってきます。 • そのため、APMでは、どのようなItemがあって、どのような制御が可能であ るか把握する必要があります。Per-Session Policy (Access Profile) とPer-Request Policyの2種類のポリシーがあるため、忘れずに両方の 確認が必要です。 53
48. 設定のデフォルト値と推奨値 • BIG-IPの多くの設定は、LB構成やSSL-VPN構成を前提としている可 能性があります。 • そのため、設定の値がデフォルトでForward Proxy構成に適した値であ る保証はありません。 • ましてや、何かしらの構成の推奨値の情報があれば、それがForward Proxy構成でも同じく当てはまるとは言い切れません。 54
49. 実装方式の概要 • 設計の方式は大きく分けると3つの方式に分かれます。 55 実装方式 (便宜上の名称) 説明 標準実装 LTMとAPMを用いてBIG-IPの標準的な機能での実装です。 SSLO実装と応用実装の基礎となり、必須の知識となります。 アクセス制御を行わない場合は、APMは不要です。 SSLO実装 SSLOのGuided Configurationを用いて、BIG-IP標準の機能としてデプロイす る実装です。 表面上は簡単になりますが、簡単に見せるために隠蔽されている内部的な実装は 複雑になっています。 応用実装 BIG-IPの標準の機能では実現できない機能をiRulesを用いて実装します。 基本的には、SSLO実装をベースにしての発展させるイメージになります。
50. SSLO実装 各実装の違い モジュールとiRules有無の観点 56 LTM APM SSLO iRules LTM APM SSLO LTM APM LTM LTM APM iRules 応用実装 標準実装 標準実装ベース SSLO実装ベース アクセス制御が必要なければ、 LTM単体でも機能します。
51. 難易度 57 標準実装 SSLO実装 応用実装 難易度 高 (High) 低 (Low) 各実装は積み重ねで成り立っています。
52. 第2部 BIG-IP Forward Proxy 標準実装 58
53. 標準実装 • BIG-IPが本来持つ標準的な機能を用いての実装方法です。 • Forward Proxyの基本機能にLTMの機能を、アクセス制御にAPMのモ ジュールの機能を用います。 • アクセス制御を行わなければ、LTM単体でも動作します。 59
54. Forward Proxy構成で必須とな る知識 60
55. Forward Proxy構成で必須となる知識 • BIG-IPのForward Proxy構成では、基本的に2種類のVirtual Serverが使われます。 • そのVirtual Serverの用途の違いを把握するには、HTTP CONNECT MethodとSSL復号化の観点を意識する必要があります。 61
56. HTTP CONNECT Method • Web BrowserがForward Proxyを介してHTTPSで接続する場合、 HTTP CONNECT Methodでホスト部分(FQDN部分)を指定して、 暗号化トンネルを張りに行くため、Forward Proxy側ではURLのPath 部分を判別できません。 • 例: CONNECT www.example.test:443 HTTP/1.1 • www.example.test/path/index.html の /path/index.html までは判 別できません。 • BIG-IPのForward Proxy構成では、HTTP CONNECT Methodが 処理フローに大きく影響します。 62
57. SSL復号化とURL • Forward Proxyを介する場合のHTTPS通信は、HTTP CONNECT Methodで接続先と暗号化トンネルを確立します。 • HTTPS通信では中身が暗号化されるため、Forward ProxyはHost 部分(FQDN部分)までしか判別できない制約があります。しかし、SSL復 号化を行うとURL全体を確認することが可能になります。 63 接続先URL SSL復号化: 無効化 (Disabled) SSL復号化: 有効化 (Enabled) http://www.example.test/path/index.html www.example.test/path/index.html www.example.test/path/index.html https://www.example.test/path/index.html www.example.test www.example.test/path/index.html
58. 標準実装: LTM単体 64
59. Forward Proxyを実現する2つのVirtual Server • BIG-IPでForward Proxyを実現するには、2種類のVirtual Serverを使い 分けます。 1. HTTP Forward Proxy向け • 種別: SSL Bypass • SSL復号化の処理をBypass(迂回)するタイプのVirtual Serverです。 2. SSL Forward Proxy向け ※オプションですが、実質必須です。 • 種別: SSL Intercept • SSLの通信をIntercept(傍受) して、SSL復号化するタイプのVirtual Serverです。 65
60. Virtual ServerのIPアドレスとポート番号の指定 #1 1. HTTP Forward Proxy向け • IP Address & Port: 通信を待ち受けるためのIPアドレスとポート番号を指定し ます。 2. SSL Forward Proxy向け • IP Address: HTTP Tunnel上のSSL復号化対象の通信にマッチするように 0.0.0.0/0 (Any) を指定します。 • Port: HTTP Tunnel上のHTTPS通信にマッチするように 443 もしくは Any を 指定します。 • 補足: https://webserver.test:10443/ のようなポート指定の通信にマッチさせるには Any に指定する必要があります。 66
61. Virtual ServerのIPアドレスとポート番号の指定 #2 Virtual Server種別 IPアドレス ポート番号 HTTP Forward Proxy向け Virtual Server 待ち受け用のIPアドレスを指定します。 例: 192.168.0.123 待ち受け用のIPアドレスを指定します。 例: 8080 SSL Forward Proxy向け Virtual Server 0.0.0.0/0 (Any) 443 or Any 67
62. 68 Destination と Service Port が異なるVirtual Serverを2つあるのに着目してください。
63. 標準実装時のVirtual Serverの動作イメージ HTTP(80/tcp)通信の場合 69 SSL Forward Proxy 0.0.0.0:443 or Any HTTP Forward Proxy 192.168.0.123:8080 Client (Web Browser) Web Server HTTP GET Method HTTP(80/tcp)通信の場合は、 HTTP Forward Proxyのみを通ります。
64. 標準実装時のVirtual Serverの動作イメージ HTTPS(443/tcp)通信の場合 70 SSL Forward Proxy 0.0.0.0:443 or Any HTTP Forward Proxy 192.168.1.123:8080 Client (Web Browser) Web Server HTTP CONNECT Method HTTP Forward Proxyに紐付く HTTP Tunnelを通る通信に対して、 SSL復号化の処理を担います。 HTTPS(443/tcp)通信の場合は、 HTTP Connect Methodが HTTP Forward Proxyを通り、 HTTP Tunnelを確立します。 HTTP Tunnel
65. Forward Proxyの設定要素 LTM Onlyの実装の場合 • HTTP Forward向けVirtual Server ➢HTTP Profile(Explicit Mode) ➢DNS Resolver ➢HTTP Tunnel (tcp-forward) • SSL Forward Proxy向けVirtual Server ➢VLAN and Tunnels: HTTP Tunnel (tcp-forward) ➢SSL Profile(Client) ➢SSL復号化向けのSSL Certificate ➢SSL Profile(Server) 71 同じHTTP Tunnelを紐付ける。 【注記】 APMを用いる場合は、 追加でアクセス制御の設定を行います。
66. 72 HTTP Forward Proxyに紐付いているHTTP Profile SSL Forward ProxyのVirtual Serverに紐付いているTunnel 同じHTTP Tunnelを紐付ける。
67. HTTP Tunnel (tcp-forward)の紐付け 73 SSL Forward Proxy#1 0.0.0.0:443 or Any HTTP Forward Proxy#1 192.168.1.123:8080 Client#1 (Web Browser) Web Server HTTP CONNECT Method HTTP Tunnel http-tunnel_1 http-tunnel_1 http-tunnel_1 SSL Forward Proxy#2 0.0.0.0:443 or Any HTTP Forward Proxy#2 192.168.1.123:8080 http-tunnel_2 http-tunnel_2 0.0.0.0/0:AnyのVirtual Serverは どの通信にも該当してしまうので 複数存在すると競合してしまいます。 しかし、HTTP Tunnelの設定により、 Virtual Server同士の紐付けを行えております。 同じHTTP Tunnelを通る。
68. デフォルトの http-tunnel (tcp-forward) の使い回し • 複数のHTTP & SSL Forward Proxy向けVirtual Serverを複数セット作成する際は、 HTTP Tunnel を分けるのが必須となります。 • マルチテ ナントのような使い方や、ステージング用途で複数セットを使う場合も考えられるため、 デフォルトの http-tunnel の使い回しを意図的にしているのか否かを意識してください。 74
69. 設定の構成要素 HTTP Forward Proxy向け • HTTP Tunnel (tcp-forward) • SSL Forward Proxy向けのVirtual ServerでHTTPS通信を処理するために、 HTTP Tunnelを作成します。 • DNS Resolver • Forward Proxyとして代理でWebサイトに接続しに行くために、HTTP Profileに紐付 ける名前解決先を指定します。 • HTTP Profile • L3 Forward Proxyとして構成するために、HTTP ProfileのProxy ModeをExplicit に指定します。 75
70. 設定の構成要素 SSL Forward Proxy向け • Virtual ServerのVLANs and Tunnelに、HTTP Forward Proxy で割り当てているHTTP Tunnelを指定します。 • SSL Client ProfileとSSL Server ProfileのSSL Forward Proxy 関連項目を設定します。 • SSL Client ProfileではSSL復号化時に使用するSSL証明書を指定 できます。 76
71. 標準実装: LTM + APM 77
72. 標準実装でのAPMによるアクセス制御 • APM利用時は、Virtual Serverで受けた通信を、Per-Session Policy (Access Profile)で認証関連の制御をしてから、Per- Request PolicyでURLフィルタリングやSSL復号化関連の処理をするフ ローになります。 78 Virtual Server Per-Session Policy (Access Profile) Per-Request Policy
73. Virtual ServerのAccess Policyの設定 • Per-Request Policyの設定を行うには、Per-Session Policy (Access Profile)の設定が必須であり、設計における重要な要素です。 79
74. Virtual Serverが2つの場合はどうなるのか？ • Forward Proxy構成では、HTTP & SSL Forward Proxyの Virtual Serverが存在する関係で、処理のタイミングを意識する必要が 出ます。 • HTTPとHTTPSのフローの違いと、HTTPSの暗号化前後 (Before/After)の違いを意識してください。 80
75. HTTP Forward Proxy向け 81 Virtual Server Per-Session Policy (Access Profile) Per-Request Policy SSL Forward Proxy向け Virtual Server Per-Session Policy (Access Profile) Per-Request Policy 種別が同じPolicyが2つあるので、 どちらのPolicyで何をするのか？が重要です。
76. 82 Per-Session Policy (Access Profile)では 何かしらのアクションとして Ending(Allow, Deny)を指定しなければならない。
77. Forward Proxyの設定要素 LTM + APMの実装の場合 • HTTP Forward向けVirtual Server ➢ Per-Session Policy (Access Proifle) ➢ Pe-Request Policy ➢ HTTP Profile(Explicit Mode) ➢ DNS Resolver ➢ HTTP Tunnel (tcp-forward) • SSL Forward Proxy向けVirtual Server ➢ Per-Session Policy (Access Proifle) ➢ Per-Request Policy ➢ VLAN and Tunnels: HTTP Tunnel (tcp-forward) ➢ SSL Profile(Client) ➢ SSL復号化向けのSSL Certificate ➢ SSL Profile(Server) 83 認証用途のPolicyが重複して適用された場合、 処理はどのようになるでしょうか？ 例えば、前段のHTTP Forward ProxyでAllowされて、 後段のSSL Forward ProxyでDenyされたら、 通信は結果的にDenyされるでしょうか？ 筆者が実機で確認した限りでは、 前段が優先されるため、Allowされます。 後述のProfile Type: SSL Orchestrator は例外です。 SSL Forward Proxy向けのPer-Request Policyでは、 SSL復号化した通信に対する処理を行えるのが 決定的な違いです。
78. 認証用途のPolicyの重複適用の設計 • SSL Forward Proxy向けVirtual ServerにてSSL復号化した通信に対す る処理をできなければ、SSL復号化を行う価値が半減されます。 • そのため、HTTP Forward Proxy向けのVirtual Serverで認証の制御を 行い、SSL Forward Proxy向けのVirtual Serverには「何もしない」に相 当するダミーのAllowのPolicyの適用が考えられます。ただし、厳密に同じ動作 はしませんでした。 • ただし、筆者が実機で確認した際の挙動のため、ご自身で裏付けは取ってくだ さい。また、「何もしない」ためだけにも後述するSSLOの導入を検討してください。 84
79. 85 AskF5 | Manual: F5 SSL Orchestrator: Architecture https://techdocs.f5.com/kb/en-us/products/ssl-orchestrator/manuals/product/ssl-orchestrator-architecture-14-0-0-4-0.html リンク先で「Click here to view the PDF」をクリックしてPDFファイルをダウンロードします。
80. 86 Per-Session Policy (Access Profile)の Profile Type: SSL Orchestrator は、 「何もしない」のが特徴です。 SSLOモジュールの有効化時でしか指定できません。
81. 87 Profile Type: SSL Orchestrator には 下記のような「Edit...」ボタンがない特殊な扱いになっており、 同等な設定を手動作成しようにも不可能なのが分かります。
82. Access Policyの優先 88 HTTP Forward Proxy向け Virtual Server Access Policy SSL Forward Proxy向け Virtual Server Access Policy Access Policy Allow Policy Deny Policy SSL Orchestrator Policy Access Policy Allow Policy Deny Policy SSL Orchestrator Policy 組み合わせ × 「何もしない」ためのProfile Type: SSLO Orchestrator を例外的に除くと、 前段のAllowとDenyのAccess Policyが優先されます。
83. Policyの適用順序の検証方法 • LTM + APMの標準実装ベースのVirtual Serverに3種類のPolicyを 適用して検証すると挙動の違いが分かります。通信時にはどちらの Virtual Serverも通るように、HTTPS通信で試しました。 89
84. 前段と後段のAccess Policyの組み合わせ 90 No. HTTP Forward Proxy (前段) SSL Forward Proxy (後段) 通信の成否 1 Allow Policy Deny Policy Allow (成功) 2 Deny Policy Allow Policy Deny (拒否) 3 SSL Orchestrator Policy (何もしない) Allow Policy Allow (成功) 4 SSL Orchestrator Policy (何もしない) Deny Policy Deny (拒否) 5 Allow Policy SSL Orchestrator Policy (何もしない) Allow (成功) 6 Deny Policy SSL Orchestrator Policy (何もしない) Deny (拒否) 7 Allow Policy Allow Policy Allow (成功) 8 Deny Policy Deny Policy Deny (拒否) 9 SSL Orchestrator Policy (何もしない) SSL Orchestrator Policy (何もしない) Allow (成功) No.1 と No.2 を見ると、Profile Type: SSL Orchestratorが、Allow Policyと等価ではないのが分かります。
85. APMのPolicyの適用パターンの概要表 モジュールの組み合わせ HTTP Forward Proxy Virtual Server SSL Forward Proxy Virtual Server Per-Session Policy (Access Profile) Per-Request Policy Per-Session Policy (Access Profile) Per-Request Policy LTM - - - - LTM + APM 認証の制御が可能 HTTPと、復号化前(Before) のHTTPSを対象に制御が可能 ？？？？ 復号化後(After)のHTTPSを 対象に制御が可能 LTM + APM + SSLO 認証の制御が可能 SSLOはデフォルトで作成しない 何もしないProfile Type: SSL Orchestrator が指定される SSL復号化済みのHTTPS通 信を含めて制御が可能 91 認証の制御を既にしているため、この段階では「何もしない」を選びたいが、 「何もしない」設定のPolicyがSSLOなしでは作れない。 Per-Session Policyなしでは、 Per-Request Policyの指定ができない。
86. APMと処理フローの関係 • 処理フローは実装によって変わるため、下記の図の3パターンを掘り下げて いきます。コメントのあり/なしの図を用意しました。 • SSLOの有無で処理フローが変わる点が、APMの適用パターンに影響が あります。 92
87. 処理フロー図 コメントなし版 99
88. BIG-IP 100 HTTP Forward Proxy向け Virtual Server Client (Webブラウザ) Web Server SSL Forward Proxy向け Virtual Server HTTPS(443/tcp) 暗号化通信 HTTP(80/tcp)通信 【標準実装】 LTM HTTP CONNECT Method
89. BIG-IP 101 HTTP Forward Proxy向け Virtual Server Per-Session Policy (Access Profile) Per-Request Policy Client (Webブラウザ) Web Server SSL Forward Proxy向け Virtual Server Per-Session Policy (Access Profile) Per-Request Policy HTTPS(443/tcp) 暗号化通信 HTTP(80/tcp)通信 【標準実装】 LTM + APM HTTP CONNECT Method
90. BIG-IP 102 HTTP Forward Proxy向け Virtual Server Per-Session Policy (Access Profile) Client (Webブラウザ) Web Server SSL Forward Proxy向け Virtual Server Per-Session Policy (Access Profile) Profile Type: SSL Orchestrator Per-Request Policy HTTP CONNECT Method HTTPS(443/tcp) 暗号化通信 HTTP(80/tcp)通信 iRules virtual コマンド 【SSLO実装】 LTM + APM + SSLO
91. 処理フロー図 コメントあり版 103
92. BIG-IP 104 HTTP Forward Proxy向け Virtual Server Client (Webブラウザ) Web Server SSL Forward Proxy向け Virtual Server HTTPS(443/tcp) 暗号化通信 HTTP(80/tcp)通信 【標準実装】 LTM HTTP CONNECT Method SSL Forward Proxy向けには、 HTTPSの通信しか通りません。
93. BIG-IP 105 HTTP Forward Proxy向け Virtual Server Per-Session Policy (Access Profile) Per-Request Policy Client (Webブラウザ) Web Server SSL Forward Proxy向け Virtual Server Per-Session Policy (Access Profile) Per-Request Policy HTTPS(443/tcp) 暗号化通信 HTTP(80/tcp)通信 【標準実装】 LTM + APM HTTPもしくはSSL復号化前 に対する処理を行える。 ここでの処理はどうするか？ Per-Request Policyを指定するには、 Per-Session Policyの方の指定も必須のため、 特に何もしなければ、何もしない処理が必要となります。 SSL復号化後に対する処理を行える。 HTTP CONNECT Method
94. Per-Request Policy BIG-IP 106 HTTP Forward Proxy向け Virtual Server Per-Session Policy (Access Profile) Client (Webブラウザ) Web Server SSL Forward Proxy向け Virtual Server Per-Session Policy (Access Profile) Profile Type: SSL Orchestrator Per-Request Policy HTTP CONNECT Method HTTPS(443/tcp) 暗号化通信 HTTP(80/tcp)通信 iRules virtual コマンド 【SSLO実装】 LTM + APM + SSLO Per-Session Policyは 認証・認可の有無の必要に応じて指定します。 SSLOではPer-Request Policyは作られません。 SSL Forward Proxyの方のPolicyで、 SSL復号化後の段階の処理をHTTP, HTTPSとわに処理が可能なためと考えられます。 HTTPの通信であっても、 SSL Forward Proxy向けのVirtual Serverに virtual コマンドで転送する実装になっています。 認証処理はこの段階では既に行われているため、 「何もしない」ための Profile Type: SSLO Orchestratorを指定しています。 SSLO実装では、 HTTP, HTTPを問わずに 一括で処理が可能になります。
95. 標準実装とSSLO実装のフローの 違い 107
96. 標準実装とSSLO実装の通信フローの違い • 標準実装とSSLO実装の違いは、SSL Forward Proxy向けのVirtual Serverに、HTTPとHTTPSのどちらの通信であっても集約される点です。 • iRulesの virtual コマンドを用いて、Virtual ServerからVirtual Serverへの転送の処理をしています。 • そのため、SSL復号化された状態の通信に対して、一元的にPolicyの適 用を行える利点が生まれています。 108
97. SSLO実装時のVirtual Serverの動作イメージ 109 SSL Forward Proxy 0.0.0.0:Any HTTP Forward Proxy 192.168.1.123:8080 Client (Web Browser) Web Server HTTP GET Method SSLO実装では、iRulesの virtual コマンドで SSL Forward Proxyに転送しています。 HTTP Tunnel SSLO Forward Proxy側で一元管理的に 処理を行え安くなります。
98. SSL Forward Proxyでの非SSL通信の受け入れ • SSL Forward Proxy向けVirtual ServerでHTTP通信を受け入れ るには、紐付いているSSL Client Profileの設定変更が必要です。 • SSL Client ProfileのNon-SSL ConnectionsをEnabledにします。 110
99. 111 Non-SSL Connections の設定を表示するには、 Configuration を Advanced 表示にします。
100. 112 SSL Forward Proxyで非SSL通信を受け入れるためには、 SSL Client ProfileのNon-SSL Connections を Enable にします。
101. virtual コマンドと SSL::enable / SSL::disable コマンド • Virtual ServerからVirtual Serverへの転送には、iRulesでvirtual コマンドを用います。 • SSL通信の有無に応じて、SSL Forward ProxyのVirtual Server側 では、SSL Profileの有効化と無効化の処理が必要です。iRulesで SSL::enable と SSL::disable コマンドを用います。 • 本資料にもコンセプト コードを掲載します。エラー ハンドリングの実装をし 切れていないため、あくまでもコンセプトの参考用となります。 113
102. 114 virtual https://clouddocs.f5.com/api/irules/virtual.html
103. 115 SSL::enable https://clouddocs.f5.com/api/irules/SSL__enable.html
104. 116 SSL::disable https://clouddocs.f5.com/api/irules/SSL__disable.html
105. 117 Master list of iRule Commands https://clouddocs.f5.com/api/irules/Commands.html Clouddocs の Master list of iRule Commands に iRules コマンドの情報が網羅的に掲載されているので参考にしてください。
106. 118 HTTP Forward Proxyに適用するiRules
107. 119 when CLIENT_ACCEPTED { set domain "?" ; # e.g. www.example.com set addr "?" ; # e.g. 10.0.1.2.3 set port "?" ; # e.g. 80, 443, 8080 } ; # CLIENT_ACCEPTED when HTTP_PROXY_REQUEST { # Get domain name # e.g. http://www.example.com/ => www.example.com # e.g. http://1.1.1.1/ => 1.1.1 set domain [string tolower [URI::host [HTTP::uri]]] if {[regexp {^([0-9]{1,3}[.]){3}[0-9]{1,3}$} $domain]} { ; # IPv4 address pattern set addr $domain } else { # Get DNS A record set result [RESOLV::lookup -a $domain] set addr [lindex $result 0] ; # Get 1st DNS A record } # Get port number # iRules URI::port command returns 80/443 for empty http/https port # e.g. http://www.example.com/ => 80 # e.g. https://www.example.com/ => 443 set port [URI::port [HTTP::uri]] # Jump to SSL Forward Proxy Virtual Server # TODO: Specify Virtual Server name in your environment virtual "VS_SSL_FORWARD_PROXY" $addr $port } ; # HTTP_PROXY_REQUEST when HTTP_REQUEST { # Jump to SSL Forward Proxy Virtual Server # TODO: Specify Virtual Server name in your environment virtual "VS_SSL_FORWARD_PROXY" [HTTP::proxy addr] [HTTP::proxy port] } ; # HTTP_REQUEST HTTP Forward Proxyに適用するiRules
108. 120 SSL Forward Proxyに適用するiRules
109. 121 # TODO: Change SSL Client Profile # allow-non-ssl (CLI) / Non-SSL Connections (Web UI): disabled => enabled # tmsh modify ltm profile client-ssl clientssl_YOUR_PROFILE allow-non-ssl enabled when CLIENT_ACCEPTED { # Preparing to accept HTTP(Non-SSL) SSL::disable serverside } when CLIENTSSL_CLIENTHELLO { # Preparing to accept HTTPS(SSL) SSL::enable serverside } SSL Forward Proxyに適用するiRules
110. 標準実装のAPMによる制御 122
111. 標準実装のAPMによる制御の一例 • APMによる下記4つの制御を紹介します。 • BASIC認証 & Local User DB • URLフィルタリング • SSL 復号化”除外” • サーバ証明書のチェック除外 123
112. BASIC認証 & Local User DB 124
113. APMによる認証制御 • 標準実装でもSSLO実装でも、APMによる認証制御の設定方法は同 等になります。 • SSLO実装では、自ら作成したPer-Request Policy (Access Profile)をGuided Configurationで指定するためです。 • 認証方法はいつくかありますが、BIG-IP単体で実装可能なBASIC認証 とLocal User DBを用いた方法を紹介します。 125
114. 認証の方式 • Client - Forward Proxy間 • 資格情報のやり取りを行います。下記のような認証方法があります。 • BASIC認証 • 注記: BASIC認証は資格情報が暗号化されません。 • Kerberos認証 • Forward Proxy - 認証Server間 • ユーザーから得られた資格情報の真正性の確認を行います。 • Local User DB • LDAP • Active Directory 126
115. 認証の方式のイメージ 127 BIG-IP Forward Proxy構成 Client (Web Browser) Web Server 認証Server Local User DB 資格情報のやり取り 資格情報の真正性の確認
116. HTTP 407 Responseによる資格情報のやり取り • APMのPer-Session Policy (Access Profile)には、HTTP 407 ResponseのItemがあり、Client - Forward Proxy間で資格情報の やり取りに用いられます。 • Forward Proxyから「407 Proxy Authentication Required」によ り、Clientに資格情報の要求を行います。 • Clientは「Proxy-Authorization」をHTTP Requestのヘッダーに付 与して資格情報を送付します。 128
117. HTTP 407 ResponseのItemの動作イメージ 129 BIG-IP Forward Proxy構成 Client (Web Browser) 1. HTTP Request → Proxy-Authorizationなし (資格情報なし) ← 2. HTTP 407 Response (407 Proxy Authentication Required) 3. HTTP Request → Proxy-Authorizationあり (資格情報あり)
118. BASIC認証 & Local User DBの設定 1. Local User DB Instance • Local Userを格納するためのDBインスタンスを作成します。 2. Local User • DBインスタンスにLocal Userを作成します。 3. Per-Request Policy (Access Profile) • BASIC認証とLocal User DBの認証の設定を行います。 130
119. 131 Instanceを先に作成してから、 UserをそのInstanceに所属させます。
120. 132 User情報を格納するためのInstanceを作成した状態です。
121. 133 Userを作成した状態です。
123. 135 HTTP 407 ResponseのBasicの分岐がBASIC認証のフローになります。 Negotiate の分岐はKerberos認証です。
124. 136 Basic Auth RealmとHTTP Auth Levelを設定します。 ちなみに、HTTP Auth levelのnegotiateの選択肢を選ぶと Kerberos認証になります。
125. 137 予め作成しておいたLocal User DBを指定します。
126. BASIC認証の認証タイムアウト • BASIC認証の認証が一度通ると、WebブラウザがHTTP Requestに資格情 報を載せるケースがあります。 • 資格情報が毎回載っていると、認証タイムアウトの状態であっても、認証ダイア ログの表示なしで認証が通ります。実質的に認証タイムアウトが発生しない挙 動に見えます。 • ただし、WebブラウザがHTTP Requestを送付しない限り、認証タイムアウト 時の再認証が行われないため、バックグラウンドの通信は認証で失敗する可能 性があります。 138
127. “宛先ベース”の認証”除外” • APMのPe-Session Policy (Access Profile)では、宛先による分岐 を行えるItemが無いため、宛先ベースの認証除外を行えません。 • Per-Request Policyでは宛先ベースの制御を行えますが、Per- Session Policy (Access Profile)では行えないため、混同に注意して ください。 • iRulesを用いた実装などの検討が必要となります。 139
128. APMを用いたURLフィルタリング 140
129. URLフィルタリングの設定 • URLフィルタリングは Access > Secure Web Gateway のメニュー配下の 設定を主に使用します。 • 下記の3つのItemの設定例を紹介します。 • URL CategoriesによりURLのリストを用意して、Category LookupのItemから参 照する。 • URL FiltersでURL Categoriesの各URLのリストに対するアクションを定義して、URL Filter AssignのItemから参照する。 • Per-Request PolicyからURL BranchingのItemで直接的に指定する。 141
130. 142 Secure Web Gatewayのモジュールがなくても、 手動登録によるURLフィルタリングの機能は利用できます。
131. Category LookupによるURL フィルタリング 143
132. 144 URL Categoriesの設定のひとつを、 VPEのCategory Lookupから参照します。
133. 145 URL Categoriesでは、 Glob Pattern Matchが使えます。
135. 147 HTTPまたはSSL復号化されたHTTPS通信に対して、 URLのPath(例: https://www.example.test/path)まで含めて識別を行う場合は 「Use HTTP URI」を選択します。
136. URL Filter AssignによるURL フィルタリング 148
137. URL Filter Assignの使い方 • URL Filter AssignのItemを用いる場合、Category Lookupの Itemをその前に配置します。 • Category LookupのItemが無い場合は、「URL filter lookup Agent Failed. No category information available」のエラー メッ セージが /var/log/apm のログに出力されます。 149
138. 150 URL Categoriesで作成されている設定が、 URL Filtersの設定に関わってきます。
139. 151 URL Categoriesで作成した各カテゴリに対して、 URLフィルタリングのアクションを指定します。
140. 152 URL Filter AssignのItemの前には、 Category lookupのItemが必要です。
141. URL BranchingによるURLフィル タリング 153
142. 154 URL Branchingは直接的にURLを指定できます。 そのため、単一のURLを例外的に処理する場合などに向いています。
143. APMを用いたSSL復号化”除外” 155
144. SSL復号化”除外”の制御 • SSL Forward Proxyを設定しただけでは、HTTPS(443/tcp)通信の 全てがIntercept(傍受)されてしまいます。 • そのため、SSL復号化の除外をするには、APMのPer-Request Policy により、除外する対象に対して、SSL Bypass SetのItemで復号化の 除外を行います。 156
145. APMでのSSL復号化”除外”の設定 • SSL ProfileのClientとServerの両方で SSL Forward Proxy Bypass を Enabled にします。 • なお、Virtual Serverに適用済みのSSL Profileは、ClientとServerの両方で SSL Forward Proxy Bypassの設定が合致する必要があります。 • APMのPer-Session Policyで条件に応じて、SSL Bypass Set の Itemを配置します。 157
146. 158 SSL Client Profileの方です。
147. 159 SSL Server Profileの方です。
148. 160 この例では、「www.example.com」にマッチした場合に、 SSL Bypass Set によりSSL復号化除外の対象になります。
149. APMを用いたサーバ証明書の チェック除外 161
150. サーバ証明書のチェック除外の設定 • サーバ証明書のチェック機能は、SSL Server Profileの機能にて行われ ています。 • SSL Server Profileではチェックの有効化と無効化しか指定できません が、VPEのItemを用いれば除外を行えます。 • VPEのItemにより制御を行う場合は、SSL Server Profileを特定の値 に設定する必要があります。 162
151. Server SSL Profileのサーバ証明書のチェック 除外向けの設定 • SSL Server Profileで下記の通りに設定をします。 • Server Certificate: require... • Expire Certificate Response Control: ignore もしくは mask • Untrusted Certificate Response Control: ignore もしくは mask 163
153. 165 Server Certificate を Require とし、 Expire/Untrusted Certificate Response Control は、 Ignore もしくは Mask にします。
154. 166 Server Cert Statusでfallbackした通信に対して、 URL識別系のItemで対象通信をAllowにすれば、 サーバ証明書のチェック除外ができます。 サーバ証明書のチェックでNGだった場合は、 fallbackに分岐します。 Server Cert StatusのItemは サーバ証明書関連のPerflow変数をチェックする仕組みになってます。
155. 不正なサーバ証明書のチェックの確認方法 • badssl.com (https://badssl.com/)に様々な不正なサーバ証明 書が用意されているため、サーバ証明書のチェック除外の確認に活用でき ます。 167
156. 168 badssl.com https://badssl.com/
157. キャッシュの設計 169
158. キャッシュ • キャッシュは、Web Acceleration ProfileをVirtual Serverに紐付け ると有効化できます。 • そのため、処理フロー上に複数のVirtual Serverが存在する場合、どの Virtual ServerにWeb Acceleration Profileを適用するべきかの検 討が必要になります。 • 標準実装とSSLO実装では処理フローが異なる関係上、キャッシュの設 計も異なってきます。 170
159. HTTPSの暗号化通信とキャッシュ • Web Acceleration Profileではキャッシュ対象に制約があります。詳細 はドキュメントを参照してください。 • Article: K14903 - Overview of the Web Acceleration profile • URL: https://support.f5.com/csp/article/K14903 • HTTPSで使われるCONNECT Methodはキャッシュ対象にはなりません が、暗号化トンネルが確立された後のGET Methodは、SSL復号化され ていればキャッシュ対象に含まれます。 171
160. キャッシュとアクセス制御 • キャッシュされたデータは、送信元ホストを問わず共有されます。 • そのため、アクセス制御で通信可否が決まった上で、許可された送信元ホ ストに対してキャッシュを返す必要性があります。 • 標準実装とSSLO実装ではアクセス制御が適用されるタイミングが、キャッ シュの設計に違いが出るひとつの理由となります。 172
161. 標準実装でのWeb Acceleration Profile • 標準実装ではHTTP & SSL Forward Proxy向けの両方のVirtual ServerにWeb Acceleration Profileを適用します。 • 一方にしか適用しないと、HTTPもしくはSSL復号化されたHTTPS通信 の一方しかキャッシュできないためです。 173
162. BIG-IP 174 HTTP Forward Proxy向け Virtual Server Client (Webブラウザ) Web Server SSL Forward Proxy向け Virtual Server HTTPS(443/tcp) 暗号化通信 HTTP(80/tcp)通信 【標準実装】 LTM HTTP CONNECT Method SSL復号化されたHTTPS通信であれば、 キャッシュの対象に含まれます。 Web Acceleration Profile Web Acceleration Profile HTTP通信をキャッシュします。 HTTP CONNECT Methodは キャッシュ対象には含まれません。
163. BIG-IP Web Acceleration Profile 175 HTTP Forward Proxy向け Virtual Server Per-Session Policy (Access Profile) Per-Request Policy Client (Webブラウザ) Web Server SSL Forward Proxy向け Virtual Server Per-Session Policy (Access Profile) Per-Request Policy HTTPS(443/tcp) 暗号化通信 HTTP(80/tcp)通信 【標準実装】 LTM + APM HTTP CONNECT Method Web Acceleration Profile HTTP通信をキャッシュします。 HTTP CONNECT Methodは キャッシュ対象には含まれません。 SSL復号化されたHTTPS通信であれば、 キャッシュの対象に含まれます。
164. SSLO実装でのWeb Acceleration Profile • SSLO実装では前段にあたるHTTP Forward Proxy向けVirtual Serverの方にはWeb Acceleration Profileは適用しないでください。 • SSLO実装では後段にあたるSSL Forward ProxyのVirtual Server向けVirtual Serverを必ず通信が通るようにした上でアクセス 制御を一括適用しているため、前段でキャッシュ機能を適用するとアクセ ス制御がバイパスされてしまい、セキュリティ上のリスクになります。 176
165. Per-Request Policy BIG-IP 177 HTTP Forward Proxy向け Virtual Server Per-Session Policy (Access Profile) Client (Webブラウザ) Web Server SSL Forward Proxy向け Virtual Server Per-Session Policy (Access Profile) Profile Type: SSL Orchestrator Per-Request Policy HTTP CONNECT Method HTTPS(443/tcp) 暗号化通信 HTTP(80/tcp)通信 iRules virtual コマンド 【SSLO実装】 LTM + APM + SSLO Web Acceleration Profile アクセス制御が迂回されないように、 後段の方で適用します。 前段の方ではアクセス制御がないため、 キャッシュ機能は適用しないでください。
166. Web Acceleration Profileの適用の比較表 178 実装方法 HTTP Forward Proxy (前段) SSL Forward Proxy (後段) 標準実装 Web Acceleration Profileを適用 Web Acceleration Profileを適用 SSLO実装 - Web Acceleration Profileを適用
167. キャッシュに関するコマンド • キャッシュの確認 • tmsh show ltm profile web-acceleration webacceleration_For_HTTP_Forward_Proxy_VS • tmsh show ltm profile web-acceleration webacceleration_For_SSL_Forward_Proxy_VS • キャッシュの削除 • tmsh delete ltm profile ramcache webacceleration_For_HTTP_Forward_Proxy_VS • tmsh delete ltm profile ramcache webacceleration_For_SSL_Forward_Proxy_VS • キャッシュのカウンターのリセット • tmsh reset-stats ltm profile web-acceleration webacceleration_For_HTTP_Forward_Proxy_VS • tmsh reset-stats ltm profile web-acceleration webacceleration_For_SSL_Forward_Proxy_VS 179 備考: 設定名は適宜置き換えてください。
168. 第3部 BIG-IP Forward Proxy SSLO実装 180
169. SSLO実装の概要 • SSLOのGuided Configurationにより、Setup Wizardのようなガイド の指示に従って、設定内容を入力してデプロイします。 • より詳細なチューニングを行うには、Guided Configurationから標準設 定へのデプロイされ方を把握する必要があります。 181
170. SSLOの必要性 • BIG-IPは様々なモジュールにより様々な構成に対応できる素晴らしい製 品です。しかし、有名所のLB構成やSSL-VPN構成にアーキテクチャが 偏っている側面もあるため、Forward Proxy構成向けにはチューニングさ れてないとも解釈できます。 • しかし、F5 Network社が公式に提供しているSSLOを用いることで、 Forward Proxy構成向けにチューチングされる点に、SSLOの価値があ ります。 182
171. SSLOはiApps LXにより実現されている • SSLOはBIG-IPの標準的な機能として実装されているのではなく、 iApps LXと呼ばれる機能にて、追加パッケージのように実装されています。 • SSLOのパッケージは https://downloads.f5.com より任意のバー ジョンがRPMファイルとして入手が可能です。 183
172. 184 F5 Downloads URL https://downloads.f5.com/
173. 185 iAppsのメニュー内に追加パッケージとして実装されている面影があります。
174. 冗長化構成時のSSLOの設定の同期 • SSLOはBIG-IPの標準機能ではなく、追加パッケージとして提供されているた め、設定の同期方法が特殊となります。 • SSLOのGuided ConfigurationでActive機側からデプロイすると、SSLO自 体がStandby機にREST APIを用いて設定を流し込みます。その際、設定の 差分は発生するため、別途ConfigSyncによる設定の同期は必要になります。 • 特殊な設定の同期方法をしているため、Standby機の設定のタイムスタンプが Active機側より最新になる場合があります。必ず発生するとは限りませんが、 ConfigSyncを行う際は、注意して対象を選んでください。 186
175. SSLOの設定の同期のイメージ 187 F5 BIG-IP #1 (Active) F5 BIG-IP #2 (Standby) ①. SSLOはデプロイ時に、Active機からStandby機にREST APIで設定を流し込む挙動をします。 ① ② ②. SSLOのデプロイ後に別途ConfigSyncによる設定同期が必要です。
176. 188 Active機(01号機)からSSLOでデプロイしていたのにも関わらず、 Standby機(02号機)のタイムスタンプが1秒進んで最新になっています。
177. 設定の同期崩れ • 何かしらの設定や操作に起因して、Active機とStandby機で設定の同期が崩れた場合、 根本原因を解決しなければ、SSLOからのデプロイが出来なくなる可能性があります。 • そのため、設定の変更が発生する際は、設定の変更前後でActive機とStandby機のUCS ファイルを必ず取得してください。UCSファイルが無い場合は、最悪のケースで一から再構築と なります。 • v16.0.0 からはHA関連の診断の修正を行う ha-sync スクリプトが導入されていますが、 v15.1.1 では存在しません。 • 上述の背景があるため、検証環境での導入であっても、SSLOの挙動の把握のために冗長化 構成での導入をオススメします。 189
178. SSLOは簡単であり、複雑でもある • SSLOはガイドによる設定により、表面上は簡単にセットアップが可能になっております。 • 簡単になってはいますが、SSLOのバックグラウンドの処理で何が行われているか把握しておかないと、エ ラーが起きた際に対応できません。 • iApps LXではNode.jsの技術が使われており、デプロイ時にエラーが発生した場合に、SSLOの開発 者向けのようなメッセージが出力されるため、そのままメッセージに従えば解決できるような代物ではあり ません。インターネットで検索しても、利用ユーザーが少ないため同一事例が見つかる可能性も現状で はほぼありません。そのため、ログからエラー発生原因を追い、SSLOのiApps LXのソース コードの解析 作業が必要となり、アプリケーション開発寄りの知見が必要になります。そのため検証用途であっても、 問い合わせ可能な保守サービスを契約するのが無難です。 190
179. SSLOの取り扱いにおける注意点 • SSLOはバック グラウンド処理がとても複雑でトラブルシュートが困難なた め、F5 Professional Serviceの契約を検討してください。 • プロフェッショナル サービス | F5 • URL: https://www.f5.com/ja_jp/services/professional-services • 古いバージョンの情報ですが、SSL Orchestrator Architecture Guide Version 14.0.0-4.0 で推奨されています。 • AskF5 | Manual: F5 SSL Orchestrator: Architecture • URL: https://techdocs.f5.com/kb/en-us/products/ssl- orchestrator/manuals/product/ssl-orchestrator-architecture-14-0-0-4-0.html • リンク先で「Click here to view the PDF」をクリックしてPDFファイルをダウンロードします。 191
180. 192 AskF5 | Manual: F5 SSL Orchestrator: Architecture https://techdocs.f5.com/kb/en-us/products/ssl-orchestrator/manuals/product/ssl-orchestrator-architecture-14-0-0-4-0.html リンク先で「Click here to view the PDF」をクリックしてPDFファイルをダウンロードします。
181. SSLOの情報源 • SSLOはiApps LXを用いているため、挙動がとても特殊になります。その ため、ドキュメントを必ず読んでください。 • またドキュメントを読んでも分からない場合は、BIG-IPのShellから下記 のディレクトリ配下のソース コードを確認してください。もしくは、SSLOの RPMファイルを展開して確認します。 • ls /var/config/rest/iapps/f5-iappslx-ssl-orchestrator/ 193
182. 194 Software Knowledge Centers https://support.f5.com/csp/knowledge-center/software SSLOのドキュメントは「F5 SSL Orchestrator」のリンク先にあり、 BIG-IPのカテゴリには無い点に注意してください。
183. 195 AskF5 | Manual: F5 Guided Configuration for SSL Orchestrator: Setup 15.1.0-7.0 https://techdocs.f5.com/en-us/bigip-15-1-0/ssl-orchestrator-setup.html v15.1.1 向けのドキュメントがないため v15.1.0 のドキュメントを掲載しています。
184. SSLOの主な要素 • SSLOはBIG-IPの標準設定としてデプロイする仕組みのため、SSLO自 体の要素は限定的です。 • SSLOのPackage Upgrade • SSLOのバージョンを指定のものにします。 • System Settings • SSLOの基本設定です。 • HA Status • HAの状態を確認できます。HA構成時は設定の同期状況に注意を払います。 • Guided Configuration • 設定のデプロイを行います。 196
185. 197 SSL Orchestratorメニューの矢印マークは、 BIG-IP標準設定へのリンクとなっており、 SSLO自体のオリジナルのメニューは限定的です。
186. 198 SSLOの中核的なメニューが SSL Orchestrator > Configuration です。
187. 199 歯車(Gear)アイコンからSystem Settingsのメニューに飛べます。
188. 200 System Settingsには名前解決の設定があるので、 設計に合わせて適宜修正します。
189. 201 この例ではCloudflareのPublic DNSサーバ(1.1.1.1)に指定しています。
190. 202 SSLOのメニュー内にアップグレードのメニューがあります。
191. 203 SSLOのPRMファイルをアップロードして、 バージョンのアップグレードが可能です。 アップグレード方法は必ずドキュメントを確認してください。
192. Guided Configurationのメニュー • Topology • SSL Configuration • Service • Service chain • Security Policy • Interception Rule • Egress Setting • Log Settings • Summary 204
193. 205 SSLOによって設定がデプロイされる際の基軸となる名前を指定します。 その名前に接頭辞や接尾辞が付与されてデプロイされます。 構成を選択します。 Forward Proxy構成では文字通りにL3 Explicit Proxyを選択します。
194. 206 文字通りにSSL Client/Server Profileに紐付く設定を行います。
195. 207 セキュリティ機器の連携を行うためのメニューです。 本資料では取り扱いしません。
196. 208 セキュリティ機器の連携を行うためのメニューです。 本資料では取り扱いしません。
197. 209 主にPer-Request Policyにデプロイされる設定を行います。
198. 210 待ち受けアドレスやポートの指定を行います。
199. 211 One-Arm構成だと、 送信元アドレス変換による戻り通信の制御が重要になります。
200. 212 ログの設定を行います。 必要に応じて適宜調整します。
201. 213 文字通りの設定の要約画面となります。 Deploy ボタンを押す前に、設定が同期状態になっているかを必ず確認します。 設定に不整合が発生しているとデプロイが中途半端な状態で失敗し、 その修正に手間がかかる可能性があります。
202. 214 Deploy ボタンを押すと、デプロイが進行している旨が表示されます。
203. 215 デプロイが成功した場合のメッセージです。
204. 216 デプロイが成功すると本画面に設定が追加されます。
205. SSLOのオブジェクト名 • SSLOのオブジェクト名の命名規則は下記の記事が参考になります。 • Article: K26520133 - Troubleshooting SSL Orchestrator(SSLO) • URL: https://support.f5.com/csp/article/K26520133#Service%20Objects%20a nd%20Naming 217
206. 218 Article: K26520133 - Troubleshooting SSL Orchestrator(SSLO) https://support.f5.com/csp/article/K26520133#Service%20Objects%20and%20Naming
207. SSLO開発者の意図をくみ取る • SSLOのGuided Configurationによるデプロイでは、SSLOの開発者 の意図をくみ取って設定するシーンがあります。 • 例えば、サーバ証明書のチェック除外だと開発者の思想に従って設定を 行う必要があります。 219
208. SSL Configurations • Guided ConfigurationのSSL Configurationメニューでは、 Advanced Settingsの表示の有無を切り替えるのを把握しておいてくだ さい。 • 「Bypass on Handshake Alert」と「Bypass on Client Certificate Failure」の設定有無により挙動が変わるためです。 220
210. 222 Advanced Setting が表示される状態になっていると、 Bypass 系の設定が表示されます。 Show Advanced Setting を押した後の状態なので、 メニュー表示上は Hide ... になっている。
211. Bypass on Handshake Alert (SSLハンドシェイク失敗時の挙動) • SSLOの「Bypass on Handshake Alert」を有効化すると、SSLハン ドシェイク失敗時でもバイパスする動作となります。 • バイパス処理が発生すると下記のようなメッセージが表示されます。 • SSL Traffic bypassed due to handshake failure alert(40) for TCP #.#.#.#:#### -> #.#.#.#:#### 223
212. 224 この例では、意図的に Server-side SSL の Processing Options を全て無効化し、 SSLハンドシェイクを失敗するようにして、 Bypass on Handshake Alert の条件を満たすようにしています。
213. 225 SSL Server Profile にデプロイした設定を確認しています。 Bypass on Handshake を有効化した場合は -vht (Trueの方) を確認します。
215. Bypass on Client Certificate Failure (クライアント認証とBypass) • SSLOの「Bypass on Client Certificate Failure」の有効化すると、 クライアント認証を行う通信がSSL復号化対象になっていても、SSL復号 化対象から除外されます。 • 表現を変えると、 「Bypass on Client Certificate Failure」の有効 化の状態で、クライアント認証を意図的に行うと、暗号化通信となるため、 不正にデータを持ち出しやすくなる可能性があります。 227
216. SSLOとSSL Profile(Client/Server) • SSLOが作成するSSL Client ProfileとSSL Server Profileには下記 の2種類があります。フォントが小さいと t (Trueの意)と f (Falseの意)の 文字が潰れて判別がつきにくいので注意が必要です。 • -vht (Verified Handshake True) • Bypass on Handshake Alert もしくは Bypass on Client Certificate Failure に チェックが入っていると、SSL Forward Proxyに -vht が適用されます。 • -vhf (Verified Handshake False) 228
217. 229 Bypass系の設定の片方でもチェックが入ると、 SSL Forward ProxyにSSL Profile(Client/Server)の -vht (Trueの方)が適用されます。
218. 230 -vht (Trueの方) と –vhf (Falseの方) はフォントが小さいと識別し難いので注意が必要です。 SSL Client Profileの方です。
219. 231 -vht (Trueの方) と –vhf (Falseの方) はフォントが小さいと識別し難いので注意が必要です。 SSL Server Profileの方です。
220. 232 Virtual Serverに -vht (Trueの方)が適用されている時の例です。
221. サーバ証明書のチェック除外 • SSLOのGuided Configurationで下記の一方もしくは両方を ignore に設定します。 • Expire Certificate Response • Untrusted Certificate Authority • Security Policyで SSL Check is false のルールを作成します。 • Security Policyで Server Certificate Status Check にチェックを 入れて有効化します。 233
222. 234 適宜、要件に応じて設定を ignore に指定します。
224. 236 Server Certificate Status Check にチェックを入れて有効化します。
225. 237 サーバ証明書チェックから除外するURLのリストの格納先を、 URL Categoriesで作成しています。
226. 238 Security Policyで サーバ証明書のチェック除外のルールを要件に応じて追加します。
227. 239 SSL Check を False にしてサーバ証明書チェックから除外する。 その対象のURLのリストは、URL Categoriesの設定を指定している。
228. 240 SSL Check is false となっており、 サーバ証明書のチェック除外が設定されたのが確認できます。
229. 241 SSLOのGuided ConfigurationによるSSLサーバ証明書のチェック除外は、 Per-Request Policyに反映されます。 詳細な設定はMacro化されています。
230. 242 サーバ証明書のチェック除外の関連設定を一望した参考キャプチャです。
231. 243 サーバ証明書のチェックを行うMacroが、 Macroから参照される構造になっています。
232. SSLOの設定例の紹介 244
233. SSLOの設定例の紹介 • 実際にSSLOでデプロイする場合の設定例を紹介します。下記は設定値の例です。 • 設定名称 (Name): BASE-NAME • 構成: L3 Explicit Proxy • IP Address: 10.1.2.3 • Port: 3128 (Default) • Service Interface: VLAN_Service • NAT: Auto Map 245
234. 設定例のOne-Arm構成 246 Firewall Internet BIG-IP Forward Proxy構成 Web Server Client (Web Browser) Virtual Server - IP Address: 10.1.2.3 - Port: 3128 Ingress Network: Service_VLAN SNAT: Auto Map 行きの通信 戻りの通信
235. 247 BIG-IPの標準設定としてデプロイされる際の ベースとなる名前を設定します。 この名前に接頭辞や接尾辞がついて オブジェクトとしてデプロイされます。 SSLOの構成の指定では、 L3 Explicit Proxyを選択します。
236. 248 Interception Ruleで、 待ち受けのアドレスやポートを指定できます。
237. 249 Forward Proxyとして待ち受けるための IPアドレスとポート番号を指定します。 通信を待ち受けるVLANを指定します。
238. 250 One-Arm構成の場合、 戻り通信がForward Proxy経由となるように 送信元アドレスの変換を行います。
239. Strict Updates (設定のロック) 251
240. Strict Updatesの概要 • SSLOがBIG-IPの標準設定とデプロイされると、SSLOの管理配下となり、 設定変更に対してロックがかかります。 • そのため、標準設定として設定を変更するにはStrict Updatesを無効 化してロックを外す必要があります。 252
241. Strict Updatesの設計面と運用面の考慮 • Guided Configurationによる設定のみで要件を満たせない場合、 BIG-IPの標準設定として個別に修正を行う必要があります。 • 一度設定した内容をBIG-IP標準設定で修正した後に、Strict Updatesでロックをかけ直したり、設定をデプロイし直すと、修正した設定 が更に変更される可能性があります。 • そのため、ドキュメンテーションによる変更管理が重要になります。 253
242. SSLOがデプロイしたオブジェクトの確認方法 • SSLOでデプロイした設定に紐付くオブジェクトは、実際にはiAppsに紐付 いているため下記のようにコマンドを実行すれば確認できます。 • tmsh modify sys application service sslo_DEMO.app/sslo_DEMO description none • tmsh modify sys application service ssloP_DEMO.app/ssloP_DEMO description none • tmsh modify sys application service ssloT_DEMO.app/ssloT_DEMO description none 254
243. 255 下記のコマンドの例のように実行すると、SSLOのiAppsとしての設定が表示できます。 【コマンドの例】 tmsh modify sys application service sslo_DEMO.app/sslo_DEMO description none tmsh modify sys application service ssloP_DEMO.app/ssloP_DEMO description none tmsh modify sys application service ssloT_DEMO.app/ssloT_DEMO description none
247. 259 iAppsのメニュー上での Strict Updates の見え方です。
248. 260 SSLO上では鍵アイコンのロックの有無で表現されています。 これは、ご覧の通りにロックされている時のアイコンです。
249. 261 これは、ご覧の通りにロックが外れている時のアイコンです。
250. 262 SSLOのGuided Configurationの管理外の設定を保持したい場合は、 Merge Changes にチェックをします。(保持対象の制限あり)
251. Merge Changesと運用方法への影響 • Unprotected から Protected に変更すると、Merge Changesを チェックしていても、変更内容が保持されない設定があります。 • Merge Changesの対象となる設定は、ドキュメント上では明示的に公 開されていません。 • そのため、一度、Unprotectedにして、本番導入を迎えた場合は、二度 とProtectedに戻さない運用方法が考えられます。 263
252. SSLOのドキュメンテーションの重要性 • SSLOはUnprotectからProtectの変更や、再デプロイなどをトリガーにし て、変更済みの設定値が別のものに上書きされる可能性があります。 • そのため、一から現在の設定まで作り直せるように、設定変更の管理が 重要となります。 • 設定の同期崩れが発生した場合に、再構築が必要になる可能性を秘め ているためです。 264
253. SSLOのBug • SSLOはSSLO自身が持つ機能が少ないため、他のモジュールと比べると Bugが比較的に少なく見えます。 • しかし、それは表面上少なく見えるだけであり、Guided Configuration でデプロイされるBIG-IP標準の機能のBugには該当する可能性がありま す。 • そのため、Bugの調査では関連するモジュールのBugまで確認が必要で す。 265
254. SSLOのサンプル画面 266
265. 第4部 BIG-IP Forward Proxy 応用実装 277
266. 応用実装とは • BIG-IPの標準機能(SSLO含む)で実装不可能なものを、iRulesによる 機能追加で補う力業です。 • iRulesでは自らの手で機能を作りこむため、出来合いで用意されている 機能と異なり、開発者が自ら品質を担保する必要があります。 • BIG-IPへの理解、Forward Proxyへの理解は勿論のこと、アプリケー ション開発への理解も求められます。 278
267. 具体的な応用実装とは • 顧客の要件によって具体的な実現方法は異なるため、「組織として、自分たちの手で 答えを作り出してください。」の一言に集約されます。 • また、設計や構築はゴールでは無く、その先には運用があります。そのため、他者の手 助けを前提して導入を行えたとしても、とても運用し続けられるものにはなりません。 • 特段、iRulesによる実装は複雑となります。人材調達によるマンパワーを使えても、 BIG-IP経験者且つiRulesの有識者は、採用が難しくなります。 • それらの考慮事項を踏まえて、応用実装まで行う前提で提案や導入を行うかを検討 してください。 279
268. iRulesコマンドによる機能へのアクセス • 目的を実現するのに必要なBIG-IPの機能へアクセスするiRulesコマンド があるか確認してください。 • iRulesコマンドでBIG-IPの挙動を変化させる都合上、対応するiRules コマンドがないと、そもそも実現性がなくなります。 280
269. iRules と iRules LX • iRules と呼ばれるものには、iRules LX (Language eXtension)もあ ります。 • iRules LXはNode.jsの技術を用いており、iRulesから呼び出します。そ のため、iRulesを完全に置き換えるものではなく、 LX (Language eXtension)の名の通りに拡張を行うものです。 281
270. 実装時のiRules LXの採択可否 • tclベースのiRulesと、Node.jsベースのiRules LXの両方が実装に採択 されるとエンジニアの学習コストが増大するのが懸念点になります。 • iRules LXではDBとの連携機能があるため、設定データの格納先として 使えそうですが、そこまですると、別途DBサーバを用意する必要があるた め、アプライアンスとして提供されているBIG-IPの価値が半減してしまいま す。 282
271. 標準実装ベース vs SSLO実装ベース • 応用実装はiRulesによる機能追加となるため、標準実装もしくはSSLO 実装をベースとする必要があります。 • 自らの手でBugを作りこむのを避ける観点と、Forward Proxy向けに改 善されている観点で、SSLO実装の方が好ましいと考えられます。 283
272. データの格納先のData Group • 任意のデータの格納先としてKey-Value Store型のData Groupがあ ります。 • Data Groupにはいくつか種類(Type)がありますが、Forward Proxy 構成では下記の2種類が活用候補です。 • Type: Address • アクセス制御で用いるIPアドレスを格納するのに適しています。 • Type: String • URLフィルタリングの宛先を格納するのに適しています。 284
273. Data Groupの扱い方 • 作成したData Groupは、iRulesから class コマンドを用いて参照しま す。class コマンドには何種類かのサブコマンドが用意されているため、ド キュメントを確認してください。 • class • URL: https://clouddocs.f5.com/api/irules/class.html 285
274. 286 class https://clouddocs.f5.com/api/irules/class.html
275. Data Groupの扱い方 287 Key Value Key#1 Value#1 Key#2 Value#2 Key#3 Value#3 Valueは任意のため、省略もできます。 Keyにはユニーク制約があり、データの重複ができません。 when HTTP_REQUEST { log local0. "MyDataGroup: [class get MyDataGroup]" } Data Group名: MyDataGroup iRules class コマンドを使用してData Groupを参照します。 この例では get のサブコマンド指定でData Group全体を取得してます。
277. 289 Data GroupはiRulesからメインに扱うこともあり、 iRulesのサブ メニューの中にあります。
278. 290 Data Groupにはいくつかのデータ保持形式があります。
279. Type: Address のData Group • Type: Address のData Groupは、Address欄(Key)に任意のサブ ネットを登録できます。 • 例えば、許可対象の送信元サブネットを格納しておく使い方が想定されま す。 291
281. Type: String のData Group • Type: String のData Groupは、String欄(Key)に任意の文字列を 格納できるため、自由度が高い形式です。 • 自由度が高い分、様々な入力が可能なため、入力値の妥当性確認 (Validation)や入力値エラー時のエラー ハンドリングは開発者側で実装 する必要があります。 293
283. HTTP::host の表現形式 • iRulesのコマンドである HTTP::host では、HTTPヘッダーの Hosts: の情 報を下記の参考例のように取得できます。 • 【参考例】 • www.example.com • www.example.com:80 • www.example.com:443 • sales-system.test:8080 • 1.1.1.1 • Hosts: の内容であるため、ポート番号の情報が付与されている場合があり、 必要に応じてポート番号を取り除いてからパターン マッチングしたり、設定データ としていくつかのパータンを登録するなどの考慮が必要とになります。 295
284. サンプル コード ～ 完全一致 (equals) ～ 296
285. 297 完全一致 (equals)向けの Data Groupの例
286. 完全一致(equals) when HTTP_PROXY_REQUEST { if { [class match [HTTP::host] equals Data_Group_equals_Host_List] } { log local0. "Match: [HTTP::host]" } else { log local0. "Not Match: [HTTP::host]" reject } } 298
287. サンプル コード ～ 前方一致 (starts_with) ～ 299
288. 300 前方一致 (starts_with)向けの Data Groupの例
289. 前方一致(starts_with) when HTTP_PROXY_REQUEST { if { [class match [HTTP::host] starts_with Data_Group_StartsWith_Host_List] } { log local0. "Match: [HTTP::host]" } else { log local0. "Not Match: [HTTP::host]" reject } } 301
290. サンプル コード ～ 中間一致 (contains) ～ 302
291. 303 中間一致 (contains)向けの Data Groupの例
292. 中間一致(contains) when HTTP_PROXY_REQUEST { if { [class match [HTTP::host] contains Data_Group_Contains_Host_List] } { log local0. "Match: [HTTP::host]" } else { log local0. "Not Match: [HTTP::host]" reject } } 304
293. サンプル コード ～ 後方一致 (ends_with) ～ 305
294. 306 後方一致 (ends_with)向けの Data Groupの例
295. 後方一致(ens_with) when HTTP_PROXY_REQUEST { if { [class match [HTTP::host] ends_with Data_Group_EndsWith_Host_List] } { log local0. "Match: [HTTP::host]" } else { log local0. "Not Match: [HTTP::host]" reject } } 307
296. サンプル コード ～ 組み合わせや正規表現 ～ 308
297. 組み合わせ 完全一致, 前方一致, 中間一致, 後方一致 when HTTP_PROXY_REQUEST { if { [class match [HTTP::host] equals Data_Group_equals_Host_List] } { log local0. "Match(equals): [HTTP::host]" } elseif { [class match [HTTP::host] starts_with Data_Group_StartsWith_Host_List] } { log local0. "Match(starts_with): [HTTP::host]" } elseif { [class match [HTTP::host] contains Data_Group_Contains_Host_List] } { log local0. "Match(contains): [HTTP::host]" } elseif { [class match [HTTP::host] ends_with Data_Group_EndsWith_Host_List] } { log local0. "Match(ends_with): [HTTP::host]" } else { log local0. "Not Match: [HTTP::host]" reject } } 309
298. 正規表現(matches_regex) when HTTP_PROXY_REQUEST { if { [HTTP::host] matches_regex {www¥..*¥.com} } { log local0. "Match: [HTTP::host]" } elseif { [HTTP::host] matches_regex {www¥..*¥.co¥.jp} } { log local0. "Match: [HTTP::host]" } else { log local0. "Not Match: [HTTP::host]" reject } } 310
299. 正規表現(matches_regex) Deny List & Allow List when HTTP_PROXY_REQUEST { if { [HTTP::host] matches_regex {.*¥.?eicar¥.org} } { log local0. "Deny Host: [HTTP::host]" reject } elseif { [HTTP::host] matches_regex {.*¥.org} } { log local0. "Allow Host: [HTTP::host]" } elseif { [HTTP::host] matches_regex {.*¥.com} } { log local0. "Allow Host: [HTTP::host]" } elseif { [HTTP::host] matches_regex {.*¥.co¥.jp} } { log local0. "Allow Host: [HTTP::host]" } else { log local0. "Not Match: [HTTP::host]" reject } } 311
300. 認証除外(送信元&宛先) when HTTP_PROXY_REQUEST { if { [IP::addr [IP::client_addr] equals 10.0.0.0/8] || [IP::addr [IP::client_addr] equals 172.16.0.0/12] || [IP::addr [IP::client_addr] equals 192.168.0.0/16] } { if { [HTTP::host] matches_regex {www¥.example¥.com} } { log local0. "Excluded Authentication: [IP::client_addr] => [HTTP::host]" ACCESS::disable } } elseif { [HTTP::host] matches_regex {.*¥.com} } { log local0. "Allow Host: [HTTP::host]" } elseif { [HTTP::host] matches_regex {.*¥.co¥.jp} } { log local0. "Allow Host: [HTTP::host]" } else { log local0. "Not Match: [HTTP::host]" reject } } 312
301. パターン マッチングの条件式の注意点 • 例えば、「my-corp.test」のサイト内へのアクセスを許可したい場合に、 URLを対象に前方一致で「my-corp.test」を指定するとします。 • その場合、「my-corp.test.fake-site.test」も前方一致で合致してし まい、URLフィルタリングを迂回される可能性があります。 • 回避策としては、ホスト部分(FQDN部分)を対象に完全一致で「my- corp.test」を指定する方法があります。 313
302. URLフィルタリングが迂回される例 • 設定例 • URL(URLスキーム部分は除く)を対象に前方一致で「my-corp.test」に合致 した場合に許可する。 • Webサイト例 • 自社サイトのTopページ: https://my-corp.test/ • 自社サイトのイベント情報: https://my-corp.test/event/ • 自社サイトの採用情報: https://my-corp.test/recruit/ • 偽サイト: https://my-corp.test.fake-site/ 314 偽サイトも許可の対象に入ってしまう。
303. 設定データの保持形式 • 設定データの保持形式は、既存導入済み機器の保持形式と、BIG-IP で表現可能なデータの保持形式を考慮して設計が必要です。 • 設定の保持形式が異なると、大量のデータの移行/移植の作業で設定の 読み替えが必要なため、設定量に比例して作業時間が増えていくのが懸 念されます。 • また、URLフィルタリングなどの処理の順番も要素にあれば、BIG-IPで実 現が必要です。 315
304. 設定データの移植/変換の失敗例 316 処理順序 アクション 送信元 宛先 1 Deny 0.0.0.0/0 malware-site.test 2 Allow 192.168.0.0/16 sales-system.test 3 Allow 192.168.0.0/16 www.google.com 4 Allow 172.16.0.0/24 www.example.com 5 Deny Any Any Key(Address) Value 0.0.0.0/0 malware-site.test Key(Address) Value 192.168.0.0/16 malware-site.test 192.168.0.0/16 www.google.com 172.16.0.0/24 www.example.com 【既存】設定データ 【移行先】BIG-IPのDeny List用Data Group 【移行先】BIG-IPのAllow List用Data Group Keyにはユニーク制約があるため、 重複したKeyは登録できない。 移植/変換
305. 設定データの移植/変換 317 ？？？？ 既存導入済み (更改元) F5 BIG-IP 新規導入 (更改先) ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## 移植/変換は、更改先/元の形式の違いを考えて 設定データを移行する必要があるため頭脳労働になります。 そのため、考慮漏れが起きないアルゴリズムに落とし込めなければ、 単純作業としてマンパワーで処理をスケールするのが困難です。
306. Data Groupの限界 • Data Groupはユーザー定義データの格納先としては便利ですが、Key- Value Store型となるため、Firewall Policyのようにテーブル型でデータを保 持したい場合には不向きです。そのため、設定データの保持形式に表現の限 度があるのを認識しておいてください。 • URLの格納先としてはURL Categoriesがありますが、あくまでもURLを対象 としたデータ設計となっています。 • iRulesのコードとして直書きする方式もありますが、運用時のコード編集は ヒューマン エラーを引き起こす可能性が高くなるため危険です。 318
307. Data Groupに独自フォーマットを仕込む • とても複雑になる悪い例を紹介します。決して真似はしないでください。 • 処理が複雑になると運用性だけでなく、処理性能に影響するため注意し てください。 319
308. Data GroupのValueを独自に区切る 320 Key Value 1 2 3 Field#1 Field#2 Field#3 Field#1 Field#2 Field#3 Field#1 Field#2 Field#3 区切り文字を活用して、 Valueをユーザー定義に基づいたField単位に分割します。 この例では、区切り文字にカンマ(,)を用いています。 Field内でも使用される文字と、 区切り文字が重複しないように考慮が必要になります。
309. Data Groupの独自フォーマットの例 Firewall Policyのような形式とする例 321 実際の設定画面では見難いため、 Excelにてテーブル形式で表現した例です。
310. 322 独自に定義したフォーマットに従って入力しているため、 初見のエンジニアには何をしているのか分かりにくい欠点があります。
311. iRulesとData Groupの設計の注意点 • iRules内のロジック改修が後から発生しないように、要件をよく洗い出し た上で設計します。 • ロジックが変わると、設定データの保持形式に影響する可能性があります。 • 例えば、URLを対象にAction(例: 認証除外の有無)指定を後から行いたくなっ た場合、設定データの保持形式にActionの項目を追加する必要が出てきます。 • Data Groupの設定データ保持形式が変わらないように設計します。 • 例えば、項目が新たに追加されると、既存データに対してその項目を明示的に設 定し直したり、項目が存在しない場合のデフォルトの動作を考慮する必要が出て きます。 323
312. 処理フローの難解さ • Forward Proxy構成ではBIG-IPの内部仕様を意識して、処理フロー がどのようになっているのかを把握する必要があります。 • 設計や構築時だけでなく、導入後の運用担当者も意識する必要がある ため、難解な処理フローでは運用引継が困難となります。 324
313. 処理フロー / 実装箇所 • Profile • Web Acceleration Profile によるキャッシュ除外の設定 • VPE (Visual Policy Editor) • Per-Session Policy (Access Profile) による認証の設定 • Per-Request Policy によるサーバ証明書のチェック除外やSSL復号化除外の設定 • iRules • class コマンドによるData Groupの参照 • virtual コマンドによる別のVirtual Serverへの転送(処理フローの変更)の考慮 • Data Group • Access > Secure Web Gateway 325 これらの設定方法を全て把握して、 適切に使用する必要があります。
314. どこに設定データを移行/移植しますか？ 326 色々な設定箇所があると、 設定の複雑性が上がり、運用性が著しく下がります。
315. 応用実装によるカスタマイズの弊害 • カスタマイズしているとBIG-IPの標準的な挙動から変わるため、F5 Network社が提供している公式の情報ですら、参考にできなくなる可能 性があります。 • そのため、各種設計書(例: 基本設計書)や実機設定が一次情報源と なります。よって、正確な記述は元より、適切に最新化を行い、ドキュメン トの品質を管理するのが重要となります。 327
316. みんなちがって、みんないい？ 328 F5 BIG-IP A社のBIG-IP A社向けカスタマイズ F5 BIG-IP B社のBIG-IP B社向けカスタマイズ F5 BIG-IP C社のBIG-IP C社向けカスタマイズ B C A カスタマイズされた他社の導入実績は 参考になるとは限らない。 同じBIG-IPなのに、 弊社とは別物... A社 公開ナレッジ
317. アクセス ログ • BIG-IPでのアクセス ログは必要に応じて、iRulesの log コマンドやHSL (High Speed Logging)を用いて独自フォーマットで作成します。 • その場合、各イベントで取得可能なデータが変わる点を踏まえて、ログ出力の設計を 行う必要があります。 • iRulesによるカスタマイズの粒度が高くなると、トラブル シューティングが難しくなるため、 ログ レベルに応じてメッセージの出力度合を変えるなどの対策が必要です。 • 適切なアクセス ログが無ければ、どのData Groupのどのレコードにマッチした処理 か？などの判別が追えなくなります。 329
318. 第5部 まとめ 330
319. まとめ • 各種実装だけではなく、実装以外の側面についても知っておくことは多々 あります。 331
320. 導入検討の方へ • 顧客の要件を満たせるかの確認は、検証用途のBIG-IP Virtual Edition Lab版(型番の例: F5-BIG-VE-LAB-V18)で安価に検証環境を構築でき ます。 • Lab版ではスループットの制限があるため、性能試験までは行えませんが、機能 の充足の観点や、運用面の考慮事項を事前に知り得る方が有益です。 • F5-BIG-VE-LAB-V18 では、LTM, APM, SSLOを有効化できます。 • 古い型番(例: 末尾 -V13)では、SSLOの前進であるSSL Forward Proxy しか対応していないためご注意ください。 332
321. PoC (Proof of Concept) / 概念実証 • BIG-IPはiRulesによる機能拡張が行えるため、単純な機能レベルの確 認をPoCで行うと、優位性が高く見える可能性があります。 • そのため、導入後の運用面を考慮するのであれば、要件の実現に際して のiRulesの使用有無と、iRulesを用いている場合の複雑性の確認をす るのが好ましいと考えられます。 333
322. 導入における障壁 • BIG-IPのForward Proxy構成は導入するだけでも難易度が高いです。 • その上で、導入後の運用性や障害時のリカバリを検討する必要がありま す。 • また、次期の移行まで考えると、応用実装ではベンダー ロックインされる可 能性があります。 • そもそも、ベンダー ロックイン以前に属人化により、ベンダーへの依存度より 人への依存度が高くなる可能性があります。 334
323. 必要な人材の観点 • BIG-IPの有識者 • SSL Orchestrator(旧SSL Forward Proxy)の有識者は少ないように見受けられる ため、少なくともLTMとAPMの有識者が居ると好ましいです。 • Forward Proxyの有識者 • 既存導入済み機器がBIG-IPとは限らない点と、iRulesによるスクラッチ開発の点におい てForward Proxyの動作の理解が必要になります。 • アプリケーション開発の有識者 • iRulesによるスクラッチ開発は基盤寄りの知見のみでは収まらないため、アプリケーション 開発の知見が必要になります。また、コードによる拡張により脆弱性を生まないために、セ キュリティの知見も必要になります。 335
324. 運用保守チーム(導入後) 次期更改チーム(未来) 導入チーム(導入時) 時系列と人材の関係性 336 BIG-IPエキスパート Forward Proxy エキスパート アプリケーション開発 エキスパート BIG-IPエンジニア 導入時だけエキスパートを投入しても、 複雑な設計だと後工程の運用保守をしていけない。 次期更改時に移行対応が可能な人材やSIerは存在するのか？ ? ? ブラック ボックス状態 のBIG-IP これは本当にBIG-IPなのか？
325. 更改 From: BIG-IP => To: BIG-IP • 既存(更改元)と新規(更改先)の機器が共にBIG-IPの場合は、バージョ ンの変化があります。 • 応用実装をしている場合は、標準機能で実装可能な要素が増えている 場合、標準実装で再実装し直すのかの検討が必要です。 • バージョンアップに伴い、iRulesのコマンドにアップデートがある可能性があ ります。そのまま既存踏襲するにおいても、iRulesのコードもそのまま動くか は確認が必要です。 337 設定データの保持構造の見直しで、 移植/変換も大変だ！
326. 成果物の観点 • 実案件では顧客要望に応じて、成果物を作成する必要が出てきます。 • BIG-IP自体は元々パラメータ数が多く、パラメータ シートの作成であって もかなりの作業工数が必要となります。 • 応用実装の場合は、アプリケーション開発を行っているような状態になるた め、ドキュメントに求められる品質や種別に違いが出る可能性があります。 338
327. 成果物の一例 • 基本設計書 • パラメータ シート • フローチャート 339 スクラッチ開発状態の動作を正しく理解して、フローチャートを書けますか？ Visioで書く場合はライセンスの準備はありますか？ SSLOが大量に作成するオブジェクトは全部書きますか？ それとも明示的に指定するものだけ書きますか？ SSLOの設定方針やスクラッチ開発したiRulesを、 誰が見ても分かりやすく網羅的に書けますか？ 運用手順書 私のこと、忘れてない？運用軽視ですか？ 運用手順書なしに誰でも運用できますか？
328. フローチャートはひとつではない！ 1. BIG-IP全体の処理フロー • 近視眼的にならないように、全体の処理を俯瞰する必要性があります。 2. Pe-Session Policy (Access Profile)の処理フロー 3. Per-Request Policyの処理フロー 4. iRulesの処理フロー 340
329. フローチャートの成果物 341 Start End 処理フローのイメージはできますか？
330. 最後に • 筆者が苦悩した経験を元に、情報を体系立ててまとめてみましたが、本 資料の情報は必須知識にすぎません。 • この先には未だ見ぬiRulesの無限の可能性が広がっています。 • しかし、可能性は希望にもなり、絶望にもなり得ます。 • 実導入する方々がより良い未来を掴み取れるのを切に願っております。 342
331. 付録 343
332. FTP over HTTP 344
333. FTP over HTTP • Web BrowserからFTPサーバへ接続するための機能です。 • FTPサーバへ直接FTP接続を行わせずにForward Proxyを介させることにより、アクセス 制御を行いやすくなる利点があります。 • BIG-IPはWeb BrowserからのFTP over HTTPには対応しておりませ ん。 • HTTP ProfileのExplicit ProxyでFTPがサポートされていないためです。 • また、昨今ではFTP over HTTPはWeb Browser側でサポートがされなくな りつつあります。 • HTTPSによる暗号化通信が普及してきた時代背景に伴い、セキュアでは無いFTPによる 平文通信が問題視されているのが理由の一端としてあるようです。 345
334. FTP over HTTPの通信フロー 346 Client (Web Browser) FTP Server Forward Proxy FTP HTTP GET ftp://ftp-server.test/ HTTP/1.1 HTTPで ftp:// のURL scheme(URLスキーム)を指定して接続しに行きます。
335. 347 BIG-IPはFTP over HTTPに対応してないため、 Squidで試したときの画面キャプチャです。 URL欄には ftp:// のURL scheme(URLスキーム) で入力されています。 FTP over HTTP対応のProxyサーバを指定しています。
336. 348 BIG-IPはFTP over HTTPに対応してないため、 Squidで試したときの画面キャプチャです。 HTTPで ftp:// のURL scheme(URLスキーム)を指定しているのが見て取れます。
337. 補足資料: FTP over HTTPのサポート状況 • Google Chrome • Deprecate FTP support - Chrome Platform Status • URL: https://www.chromestatus.com/feature/6246151319715840 • Mozilla Firefox • Mozilla will remove FTP support in the Firefox web browser - gHacks Tech News • URL: https://www.ghacks.net/2020/03/19/mozilla-will-remove-ftp- support-in-the-firefox-web-browser/ 349
338. End Of File このスライドが本資料の最後です。 350