IDCF Tech-Blog

IDCF テックブログ

クラウド・ビッグデータ・データセンターを提供するIDCフロンティアの公式エンジニアブログ

IDCフロンティアのネットワークサービス(LB/WAF)を使った事例紹介

今回はIDCフロンティアのネットワークサービス(以下「IDCFネットワークサービス」)を使用した事例紹介をさせていただきます。

IDCFネットワークサービスとは?

IDCFネットワークサービスについて簡単に説明しますと、ファイアウォール(以下「FW」)/ロードバランサー(以下「LB」)/ウェブアプリケーションファイアウォール(以下「WAF」)の機能を選択して使用できるサービスです。その他にDDoS対策、IPS/IDSの機能も選択可能ですが、今回はFW/LB/WAFを中心にご紹介します。

特長としては、さまざまなネットワーク構成でご利用いただけることです。IDCFクラウドのゾーンやデータセンターを跨いだ構成や、IDCFクラウドの仮想マシンとお客さまマシンの負荷分散もできます。クライアント⇔サーバー間だけでなく、DB接続などのサーバー間の通信にも適用できます。 さまざまなネットワーク構成でご利用いただけます

どうやって実現している?

IDCFネットワークサービスではF5社のアプライアンス製品であるBIG-IPを使用しています。RouteDomainという機能で、下図のようにマルチテナントを実現し、RouteDomain毎に必要なサービスを適用しております。

BIGIP

RouteDomainをCLIで設定するとこのような感じです。BIG-IPはGUIで操作するのが一般的かもしれませんが、CLIもJunosチックで取っ付きやすいです。

id 101
   vlans {
       VLAN101-External
       VLAN1001-Internal
   }
id 102
   vlans {
       VLAN102-External
       VLAN1002-Internal
       VLAN103-External
       VLAN1003-Internal
   }
id 104
 vlans {
  VLAN104-External
  VLAN1004-Internal
       VLAN1005-Internal
   }

BIG-IPを使っているため、「現在オンプレ環境でBIG-IPアプライアンスを使用していて、クラウド環境に移行したい方」という方は既存の設定をそのまま(安価に)移設できます。事例で後ほどご紹介していきますね。また、SSLアクセラレーションや個別ヘルスモニター等の機能も標準サービスとして使えます。では事例の説明に入ります。

事例紹介

■WAFで速やかに脆弱性に対応した事例

PCIDSSでも推奨から必須となったWAFの活用事例をご紹介します。BIG-IPでいうとASMというモジュールの機能になります。

そもそも攻撃なんてあるの?

弊社のとあるサイトも毎日様々な国から様々な攻撃を受けています。脆弱性を放置することは大きなリスクです!

攻撃

内部ではこんな感じで攻撃の詳細が見れるのですが、残念ながらお客さまにお見せすることはできません。

sql

事例

あるサイトで、脆弱性検査の結果、クロスサイトスクリプティングとSQLインジェクションの攻撃に対して、脆弱であることがわかりました。

プログラムの改修には時間がかかるため、至急、サーバーの上位にIDCFのネットワークサービスを導入し、攻撃をきっちり防御しました。高価なWAFは攻撃を受けてから導入を検討されるケースが多いのですが、比較的安価なIDCFネットワークサービスのLBをご契約いただいた状態であれば、いつでもすぐにWAF機能を利用開始できます。

ご契約いただいているお客さまには毎日の簡易レポートと、ご要望に応じて詳細レポートをご提供しております。その一部を、ちょっとだけ貼りますね。

レポート

ちなみにシグネチャは毎日4:00に更新しています。

■iRuleの活用事例

IDCFネットワークサービスではF5社のアプライアンス製品であるBIG-IPを使用しているため、iRuleが利用できます。日頃運用していて「多いな」と感じるお客さまのご要望に対し、iRuleを使用して実現した事例をご紹介します。

ご要望1:暗号化が必要なサイトにリダイレクトしたい

下記のように、「クライアントからのHTTPアクセスをHTTPSにリダイレクトさせたい」というご要望に対応したケースです。セキュアな情報の入力等が必要なサイトで、ご要望が寄せられることがあります。

手順

iRuleの中身はこんな感じです。

when HTTP_REQUEST {
               HTTP::redirect https://[HTTP::host][HTTP::uri]
                   }

ご要望2:Sorryサーバーに自動で切り替えたい

運用中のサイトがダウンした際に、自動でSorryサーバーへ切り替える方法として、IDCFネットクワークサービスでは以下の3つパターンを用意しました。

  1. [パターン1] お客さまにてSorryサーバーをご用意いただき、お客さまのSorryサーバーに分散させる
  2. [パターン2] 外部サイトにリダイレクトする
  3. [パターン3] IDCフロンティアにてLB上にファイルをアップし、そのページにアクセスさせる(単一ファイルのみ)

SorryServer

iRuleの中身をご説明します。

パターン1については実はiRuleではなくPoolのPriority Group(+Priority Group Activation )で実現しています。

パターン2のiRuleはこんな感じです。先ほどご紹介したリダイレクトの設定と同じです。

when HTTP_REQUEST {
       if { [active_members <strong>Poolの名前</strong>] < 1 }
         {HTTP::redirect https://[HTTP::host][HTTP::uri] }
         }

パターン3のiRuleはこんな感じです。iFile Listに単一ファイルをuploadして、それを指定しています。

when HTTP_REQUEST {
       if { [ active_members <strong>Poolの名前</strong>] < 1 }
         {HTTP::respond 200 content [ifile get /Common/<strong>fileName</strong>] "Content-Type" "text/html"
}
         }

ご要望3:特定の国からのアクセスを防ぎたい

特定の国からの攻撃は、WAFサービスでも防げるのですが、これをご利用でないお客さまでも、iRuleで実現することができます。「特定の国」を管理するデータベースは、更新頻度が高くないので、現場では月に1回、手動で更新しております(自動でできるようにならないかな。。。)。

iRuleはこんな感じです。下記では、日本からのアクセスを拒否しています。JPのところを別の国コードで記載すればその国からのアクセスは拒否されます。

when CLIENT_ACCEPTED {
  switch [whereis [IP::client_addr] country]
             {<strong>JP</strong> { reject }}
            }

 ご要望4:iRuleをそのまま移設

他にもiRuleを利用した事例は多くありますが、一番多いのが既存の(オンプレの)iRuleをそのままIDCFネットワークサービスに移設というケースです。Version9以降のiRuleであればほとんどの場合そのまま移設可能です(とはいえ稼動前にしっかり試験することは大事です)。

 

■こんなご利用事例も

その他に、お客さまがIDCFネットワークサービスをこのように使用しています、という例をご紹介します。

事例1:クライアントのIPアドレスを変換せずにWEBサーバーに渡す

マーケティングや運用上の目的で、WEBサーバーでクライアントのIPアドレスを集計している場合は、クライアントのIPアドレスをそのままWebサーバーに渡す必要があります。多く寄せられるご要望のため、この機能はデフォルトで有効となっております。

 

事例2:プライベートファイアウォールとしてのご利用

お客さまのオンプレミス環境とIDCFクラウドを連携させたケースです。オンプレからクラウドへの移行や、「通信量が多い時だけクラウドのサーバーを使いたい」といったときにこのような構成をとられることが多いです。

このケースでは内部間の通信にファイアウォールが必須であったため、プライベートコネクトをIDCFネットワークサービスのFWで終端させ、通信を制御しました。

ハイブリッド

 

この場合、インターネットへの出口は、お客さまのオンプレミス環境でも、IDCFクラウドでも、どちらもご利用いただくことがきます。

事例3:想定外のトラフィック量に対応

IDCFクラウドが標準で提供する仮想ルーターでは処理しきれない大量の通信が発生した お客さまにて、高性能なIDCFネットワークサービスをご利用いただくことで問題なく通信を処理できるようにしました。

traffic-2

少し前であればアプライアンス製品の導入の際には、調査、選定、検証、構築、設置等(だいぶ省略しましたが)が必要でした。IDCFネットワークサービスは、ケーブル配線すら必要なく、手軽に機能も性能も向上させることができた、いい事例かと思っています。

 

事例はこんなところで。

 

IDCFネットワークサービスの今後

最後にIDCFネットワークサービスについての今後についてお伝えします。一部の設定、例えばお客さまサーバーメンテナンスなどで分散対象から外したい場合などについて、UIをご提供しております。現在のところ下のような画面です。このUIについては改善要望も多く、随時更新しています。

LBportal

今UIでできることは

◯LB

  • ノード(分散対象となるサーバ)の追加
  • ノードの削除
  • ノードの有効化
  • ノードの無効化

もうすぐUIでできるのが

◯FW

  • ルールの追加
  • ルールの編集
  • ルールの削除

といったところです。さらにUIをよくしていきたいので、すでにご利用中のお客さまはご意見いただけますと助かります。

このようにIDCFネットワークサービス(FW/LB/WAF)では十分に実績のある機能を組み合わせることで新しいサービス、新しい価値をご提供しております。拙い説明で、わかりづらい点もあったかと思いますが、ここまで読んでいただきありがとうございました。気になる点ございましたらお問い合わせくださいませ。

 

でわでわ

Copyright © IDC Frontier Inc.