Edgenexus の同僚たちの間では、F5 LTM ロードバランサーは非常に強力で柔軟性がある一方で、いくつかの基本的な機能を実行するために iRules スクリプトの使用に依存することは不必要な複雑さにつながるという考えが広く浸透しています。
F5 iRulesをオンラインで検索するだけで、多くのITプロフェッショナルが機能的なiRulesを作成する過程で経験しなければならない苦痛や悩みを発見することができます。確かに、最近のF5ソフトウェアのリリースでは、「Local Traffic Policies」機能が拡張され、一般的なHTTPヘッダー操作機能のiRuleを作成する必要性が一部なくなりましたが、システム構成にレガシーなiRuleが残っているユーザーも多くいます。
ローカル・トラフィック・ポリシーでは、HTMLデータの操作はできないようだが、ストリーム・ポリシーでは可能である。デフォルトでは、これらはどちらの方向のトラフィックにも同じように影響するが、これは通常望ましくない。つまり、http:// から https へのリダイレクトと同時に、https:// URL の本文リンクの置換を行う必要がある場合は、iRules に戻す必要があります。
EdgenexusのflightPATHを導入 – トラフィック管理を簡単に
Edgenexusでは、flightPATHレイヤー7のHTTP操作機能のパワーと設定の簡単さを誇りに思っています。
もしあなたが既存のF5ユーザーで、HTTPやHTMLの操作にiRulesを利用しているのであれば、Edgenexus ALB-Xロードバランサーのデモを行い、flightPATHが比較的複雑な機能を実現するためにいかに簡単に設定できるかをお見せできる機会を喜んで提供します。お客様の既存のiRulesの機能をflightPATHのルールに変換するお手伝いをさせていただきます。
例として、F5 iRuleの一部とEdgenexus flightPATHルール設定のスクリーンショットを以下に示します。
ソースIP コンテンツサーバー ステアリング
F5 iRulesを使用して、特定のIPアドレス範囲からのユーザーをあるサーバープールに、別のIPアドレス範囲からのユーザーを別のサーバープールに誘導する例を示します。
F5:
| 名前 | IP_Choice |
| 定義 | when HTTP_REQUEST { if { ([IP::addr [IP::client_addr] equals 24.24.15.100] ) or ([IP::addr [IP::client_addr] equals 10.1.1.2] ) } }.{pool pool2 } 。} |
エドゲネクサス
- Web GUIでIP_Choice_Pool_1という名前で新しいflightPATHルールを作成します。flightPATHルールが実行する機能を識別できるように、簡潔な説明を追加します。
- 広範なドロップダウンリストからソースIPを選択し、新しいコンディションを追加する。センスのドロップダウンから「Does」を選択する。ドロップダウンの［チェック］リストから［開始］を選択することもできます（別の方法として、RegExなどの他のオプションを使用して、IPアドレスの「値」に柔軟性を持たせることもできます）。値」ボックスに開始IP範囲を入力します。
- 新しいアクションを追加します。アクション ] ドロップダウンボックスから、[ サーバーの使用 ] オプションを選択します ( 必要に応じて、[ セキュアサーバーの使用 ] オプションもあります )。ターゲット ] ボックスに必要な宛先の IP アドレスとポートを入力します。
HTTPからHTTPSへのリダイレクト
F5は現在、HTTPからHTTPへのリダイレクトを実行するためにiRulesを使用する代替手段を持っていますが、人々はまだこの機能のためにiRulesを使用している多くのインスタンスがあります。
F5:
| 名前 | HTTP_HTTPs リダイレクト |
| 定義 | when HTTP_REQUEST { HTTP::redirect “https://[HTTP::host][HTTP::uri]”} |
エドゲネクサス
- Web GUI経由でHTTPをHTTPSにリダイレクトするという名前の新しいflightPATHルールを作成します。flightPATHルールが実行する機能を識別できるように、簡潔な説明を追加します。
- ほとんどのアプリケーションでは、HTTPからHTTPSへのリダイレクトを実行する要件は、HTTPサービスにヒットするすべてのトラフィックに対して実行する必要がある。この場合、条件ルールを作成する必要はない。flightPATHルールが特定のトラフィックにのみ影響する場合は、条件ルールを作成する柔軟性が非常に高い。
- アクションドロップダウンボックスからリダイレクト302を選択し、新しいアクションを追加します（リダイレクト301も利用可能です）。Edgenexus ALB-X は、ALB-X によって処理されるトラフィックの特定のキーパラメータ用の変数を自動的に作成します。ターゲット] ボックスには、リクエストのリダイレクト先の詳細を入力します。この場合、https:// の前に入力し、$host$$path$$querystring$変数を使用して元のhttpリクエストのデータを挿入する。お分かりのように、ここでは必要に応じて全く別の行き先を定義する柔軟性があります。
クレジットカード番号のマスク
iRulesの複雑さと、F5がHTMLボディの操作を処理する方法の例を以下に示す。
F5:
| 名前 | クレジットカード番号マスキング |
| 定義 | HTTP_REQUEST {の場合 # サーバーが圧縮されたレスポンスを送信しないようにする # クライアントから圧縮機能を削除する HTTP::headerは “Accept-Encoding “を削除する。 # レスポンスデータのチャンクを許可しない if {[HTTP::version] eq “1.1”}{ # HTTP 1.0に強制的にダウングレードするが、キープアライブ接続は許可する。 # HTTP 1.1はデフォルトでkeep-aliveですが、1.0はkeep-aliveではありません、 # ヘッダーにkeep-aliveステータスが反映されていることを確認する必要がある。 # キープアライブ接続かどうかをチェックする if {[HTTP::header is_keepalive] }{ # コネクションヘッダーの値を “Keep-Alive “に置き換える。 HTTP::header replace “Connection” “Keep-Alive” } # サーバー側のリクエストのバージョンを1.0に設定する # これにより、サーバーはチャンキングなしで応答するようになる。 HTTP::バージョン “1.0” } } when HTTP_RESPONSE { # textコンテントタイプ(text/html, text/xml, text/plainなど)のレスポンスのみをチェックします. if {[HTTP::header “Content-Type”] starts_with “text/”}{ # HTTP_RESPONSE_DATAイベントで処理される）データを収集するために、コンテンツの長さを取得する。 # コレクションを1Mb（1048576から少し余裕を引いた値）に制限する – 詳細はSOL6578を参照 if {[HTTP::header exists “Content-Length”] }{ if {[HTTP::header “Content-Length”] > 1048000 }{ # コンテンツ長が1Mbを超えるので、1Mbを収集する。 content_length 1048000 } else { # Content-Lengthが1Mb以下なので、実際の長さを収集する。 コンテンツ長を設定する [HTTP::header “Content-Length”] } } else { # レスポンスにはContent-Lengthヘッダがないので、デフォルトの1MBを使用する。 content_length 1048000 } # Content-Lengthヘッダーの値が0の場合、コンテンツを収集しない。 if { $content_length> 0 } { { $content_length 0 } { { $content_length 0{ HTTP::collect $content_length } } } HTTP_RESPONSE_DATA {の場合 # 一回のパスで全てのクレジットカード番号を見つける set card_indices [regexp -all -inline -indices {(?:3[4|7]\d{2})(?:[ ,-]?(?:\d{5}(?:\d{1})?)){2}|(?:4\d{3})(?:[ ,-]?(?:\d{4})){3}|(?:5[1-5]\d{2})(?:[ ,-]?(?:\d{4})){3}|(?:6011)(?:[ ,-]?(?:\d{4})){3}}\ [HTTP::payload]] 各カードIDX $card_indices { セット・カード・スタート [lindex $card_idx 0] セット・カード・エンド [lindex $card_idx 1] set card_len [expr {$card_end – $card_start + 1}]. set card_number [string range[HTTP::payload] $card_start $card_end]. # ダッシュやスペースが存在する場合はそれらを取り除き、変数の切り出しで出現回数を数える。 セットカットアウト[regsub -all {[-]}card_number “” card_number]. # 変数card_lenを調整するが、後で使うために残しておく。 set new_card_len [expr {$card_len – $cutouts}]. set double [expr {$new_card_len & 1}]. セット・チャクサム 0 セットisCard無効 # MOD10を計算する for { set i 0 } { $i $new_card_len{ $i< $new_card_len } { { incr i } } { $new_card_len{ incr i } { $new_card_len{ セット [string index $card_number $i] if {($i & 1) == $double} { if {[incr c $c] >= 10}{incr c -9} } incr chksum $c } # カード・タイプの決定 switch[string index $card_number 0] { 3 { set type AmericanExpress }. 4 { set type Visa }. 5 { set type MasterCard }. 6 { set type Discover }. デフォルト } # 有効なカード番号であれば、数字をXでマスクする。 もし { ($chksum % 10) == 0 } ならば。{ 有効なisCardを設定する HTTP::payload replace $card_start $card_len [string repeat “X” $card_len] } # ログ結果 log local0.”Found $isCard $type CC# $card_number” } } |
エドゲネクサス
- 新しいflightPATHルールを作成し、意味のある説明を記述する。
- これは、条件マッチが不要な例である。通常、サーバからの応答を保護したいからである。もちろん、必要であればこのオプションもあります。
- 新しい’アクション’を追加し、ドロップダウンメニューから’Body Replace All’を選択します。このアクションで置換する対象テキストにマッチするように正規表現を使用します。クレジットカード番号の先頭12桁を検出し、置換する対象として、「☑b(?:☑d[ ☑t-]?){12} ☑b」を使用します。データフィールドに置換テキストとして xxxx-xxxx-xxxx を入力します。これにより、識別子として慣習的な下4桁はそのまま残ります。
- 国民保険番号のような他の機微なデータ型についても、上記のプロセスを繰り返す。 \b(?:≖d[ ≖]?){7} ≖b replaced by xxx-xxxx と ≖b(?:≖d[ ≖d]?){6} ≖b replaced by xxx.xxx
- 正規表現をうまく使えば、Body Replaceアクションを使うだけで、さまざまな文字列をマッチさせ、マスクすることができます。Body Replace FirstとBody Replace Lastは、ページ上の文字シーケンスの最初か最後のインスタンスだけを置き換える必要があるときに使える、他のアクションオプションです。
セキュリティを脅かす可能性のあるXヘッダーを削除する
アプリケーションやサーバ技術によってデフォルトで挿入される特定の HTTP ヘッダを削除することで、アプリケーショ ンの配信に使用されるサーバインフラに不必要な情報を提供しないようにすることは、しばしばグッドプラクティスとして 挙げられます。ハッカーが悪用しようとしているシステムについて知っていれば知っているほど、悪用は容易になります。システムの脆弱性が公表されてからパッチが適用されるまでには、しばしばタイムラグがあります。システムが最も脅威にさらされているのはこの時期であり、アプリケーションデリバリプラットフォームの詳細を不明瞭にするプロセスが最も有効である。
不要な情報の多くはX-Headerに含まれている。以下のiRuleは、望ましくないかもしれない包括的なX-Headerの削除を実行する。
F5:
| 名前 | HTTP Xサーバーヘッダ除去 |
| 定義 | when HTTP_RESPONSE { # Serverヘッダーのインスタンスをすべて削除する HTTP::header remove サーバー # x- で始まるすべてのヘッダーを削除する foreach ヘッダー名[HTTP::header names] { if {[string match -nocase x-* $header_name]}{ HTTP::header remove $header_name } } } |
エドゲネクサス
- 例えば、Remove HTTP Headers（HTTPヘッダーを削除する）など、意味のある名前で新しいflightPATHルールを作成する。
- これは、条件マッチングが必要ないと思われるflightPATHルールの例である。必要であれば、包括的な選択基準のセットが用意されている。
- 対象フィールドに削除するヘッダー値を入力します。Remove Response Headerアクションエントリを追加して、サーバーレスポンスからマスクする必要がある各ヘッダーフィールドを定義します。すべてのカスタムX接頭辞ヘッダーを削除する包括的なアクションは、実際には有害な効果をもたらす可能性があるため、flightPATHでは、削除する必要がある特定のヘッダーを定義する必要があります。
- 作成したflightPATHを、アクションが必要な各サービスに適用する。
仮想サービスへのflightPATHルールの適用
flightPATHは非常に強力ですが、簡単に使えるHTTP操作ツールです。ALB-Xロードバランサアプライアンスを通過するHTTPトラフィックに対して様々なアクションを実行するflightPATHルールの「ライブラリ」を作成できます。複数のflightPATHルールを仮想サービスに適用できます。flightPATHルールはサービスに適用された順に処理されます。一部のflightPATHルールは処理を終了します。ドラッグ＆ドロップを使用して順序を並べ替えることで、すべてのアクションが必要に応じて実行されるようにすることができます。flightPATH操作のデバッグを可能にする包括的なflightPATHロギングとトレースが利用可能です。エッジネクサスは、より複雑なflightPATHルールの変換と作成を支援する専門的なサービスを提供することができます。
もっと知りたい？
Edgenexusのトラフィック操作の詳細については、ここをクリックしてください。
ALB-Xの無料トライアルをダウンロードするには、ここをクリックしてください。
私たちは、Edgenexus ALB-XとflightPATHの機能をデモンストレーションする機会を大切にしています。 技術デモのご依頼はこちらから。
