makoto_fujimotoのblog

株式会社進角
代表 藤本信のブログです
どうぞよろしくお願いします

ロードバランサを導入するメリットは"サーバの負荷を減らすこと"と思っている方が多いようですが少し違いまして、役割りとしては配下のサーバに適切な負荷がかかるように制御することです。
最近いわゆるクラウドサービスで標準で使えるロードバランサの仕様を調べたら、ちょっとビジネス要件を満たせない仕様だったので、あらためて一般的なロードバランサ製品が実装している機能を整理してみました。

(1) 様々な指標でサーバの重みづけが設定できる
トラフィック、コネクション数、ロードアベレージなどを検知し動的に任意の配分が可能です。負荷以外にもラウンドロビン形式(巡回)での分散も可能です。

(2) サーバのヘルスチェック機能
サーバの様々な障害を検知して故障と判断したら自動的にトラフィックを流さないようにします。また一方のサーバの障害検知をトリガーとして待機サーバにトラフィックを切り替えるホットスペア機能などもあります。

(3) セッション維持機能
cookieやアクセス元のIPアドレスを使用してショッピングカートやユーザ認証状態が維持されるように通信中のサーバを保持し続ける機能があります。

(4) L7機能によってURL判別などができる
通信内容を判別してサーバの振り分けなどを行う機能です。例えばURLに/shop/という文字列があったらショップ専用のサーバにトラフィックを振り分けたりできます。

(5) HTTPS通信の際にアクセス元のソースIPアドレスが判別出来る
Spoof機能がないロードバランサではHTTPS通信時のソースIPアドレスが検知できず、ロードバランサのIPとなってしますので、アクセス元制限やログ解析、調査などに支障があります。

ダイナミックDNS(以下DDNS)とは動的にゾーン情報のIPアドレス等を書き換えることが出来るDNSの仕組みです。例えば固定IPアドレスを持たない家庭用ネットワークに一時的にホスト名を割り当てて外部との通信を手助けしたり、CDNサービスの負荷分散に利用されています。

また機器障害が発生した際の可用性を担保する仕組みとして、通常はロードバランサー等のヘルスチェック機能&切替機能を利用しますが、構成が複雑になり費用もかかるため、DDNSと監視システム等を組み合わせて障害発生時速やかに機器を切り替えてクライアントへの影響を最小限にするなどの応用も可能です。

BIND9にはDDNSの機能が組み込まれていますので、比較的簡単な設定で利用できます。
以下に設定方法を説明します(既に通常のDNS設定が済んでいることを前提としてます)。

  1. named.confの設定
    allow-update{}にゾーン情報の更新を許可するクライアント(ネットワーク)を設定します。
    allow-updateはDDNSを使用するゾーンのみゾーン宣言の中に記述します。
    プライマリDNSのゾーン宣言部に
        allow-update{ [更新許可クライアント]; };
        notify yes;
        also-notify { [セカンダリDNS]; };
        allow-transfer { [セカンダリDNS]; };
    を追加します。
    セカンダリDNSのゾーン宣言部には
        allow-update{ [プライマリDNS]; };
    を追加します。
    これでプライマリDNSで更新されたゾーン情報がセカンダリDNSに同期されます。

    プライマリDNS named.conf 修正箇所
    ゾーン情報
    zone "ddzone.shinkaku" {
        type master;
        file "ddzone.shinkaku.zone";
        allow-update{ [更新許可クライアント]; }; #ゾーン情報の更新許可クライアント
        notify yes;                              #ゾーン情報の更新通知を送る
        also-notify { [セカンダリDNS]; };        #ゾーン情報の更新通知先
        allow-transfer { [セカンダリDNS]; };     #ゾーン転送を許可
    };

    セカンダリDNS named.conf 修正箇所
    #ゾーン情報
    zone "ddzone.shinkaku" {
        type slave;
        masters { [プライマリDNS]; };
        file "slaves/ddzone.shinkaku.zone";
        allow-update{ [プライマリDNS]; };        #ゾーン情報の更新を許可
    };

  2. ゾーン情報ファイル、ディレクトリのパーミッション設定
    ゾーン情報ファイルは、namedユーザーが書込みができるようにパーミッションを変更します。また差分更新のための *.jnlファイル が生成されるので、ディレクトリも同様にパーミッションを変更します。

  3. ゾーン情報ファイルを手修正する場合の注意点
    DDNSはゾーン情報ファイルと *.jnlファイルの組で構成されています。したがって、ゾーン情報ファイルを手書き更新してnamedを再起動しただけではエラーが発生しますので、必ず *.jnlファイルを削除してからnamedを再起動します。

  4. セカンダリDNSへの変更情報の即時反映について補足
    プライマリDNSが変更されてもセカンダリDNSへの反映が遅れると不都合がありますので
    セカンダリDNSのゾーン宣言部にも必ず
      allow-update{ [プライマリDNS]; };
    を設定します。
    設定していない場合はプライマリDNSからのゾーン情報更新通知(notify)が送られてもゾーン情報は即時に更新されません。

  5. 動作確認方法
    ゾーン情報の更新にはnspdateコマンドを使用します。
    以下が実行例になります。
    -----------------------------------------------------------
    [root]# nsupdate
    > server ns.ddzone.shinkaku
    DNSレコードの登録
    > update add dev.ddzone.shinkaku 3600 IN A 192.168.1.101
    > send
    DNSレコードの削除
    > update delete dev.ddzone.shinkaku In A 192.168.1.101
    > send

    デバッグ時は-dオプションを使用します。

    nsupdateで更新したゾーン情報は即座にDNSに反映されますが、更新情報は *.jnl ファイルに差分として保存され、時間を置いてからゾーン情報ファイルに反映されます。
    この時、シリアルは自動的にカウントアップされます。

  6. クライアントのリゾルバキャッシュについて
    DNSのゾーン情報が更新されても一般的なクライアントPCにはホスト名とIPアドレスの情報を一定時間キャッシュする機能があることを意識する必要があります。したがって、閉じたネットワークシステムを構成する場合はこの設定も最適化することをお勧めします。

    検証はWindows7でしか行っておりませんが、Microsoftのサポートに新しい情報はありませんので、おそらくWindows8でも大丈夫かと思います。なおCentOS等のUNIX系OSにも同様のキャッシュ機能があります。

    Windows7のDNSリゾルバキャッシュについて
    -------------------------------------------------------------------------------
    Windows7ではDNSへの問い合わせ結果がキャッシュされ、頻繁にDNSへ問合せしないしくみになっています。DNSのゾーン情報を更新しても、クライアントPCに反映されない場合は、DNSリゾルバキャッシュのエントリを消去します。一度問い合わせたDNS情報を、再度問い合わせるまでのDNSリゾルバキャッシュの有効時間は、DNSのゾーン情報におけるいわゆるTTLが設定時間になります。
    -------------------------------------------------------------------------------

    【DNSリゾルバキャッシュを確認する】
    DNSリゾルバキャッシュの内容を確認したい場合は、
    コマンド プロンプトで
     ipconfig /displaydns
    と入力する。

    【DNSリゾルバキャッシュのエントリを消去する】
    一時的にDNSリゾルバキャッシュを消去したい場合は、
    コマンド プロンプトで
     ipconfig /flushdns
    と入力する。

    【DNSリゾルバキャッシュ機能自体を無効にする方法】
    「コントロールパネル」⇒「管理ツール」⇒「サービス」からDNS Client(DNS クライアント サービス)を停止します。

    【DNSリゾルバキャッシュの有効時間を任意に設定する】
    レジストリキー(MaxCacheTtl と MaxNegativeCacheTtl) を設定すれば、DNSリゾルバキャッシュの有効時間は MaxCacheTtl に設定した秒数になります。
    レジストリ
    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\DNSCache\Parameters
    MaxCacheTtl      → リゾルバキャッシュ(秒)
    MaxNegativeCacheTtl  → 否定応答のキャッシュ(秒)

    (参考)
    Windows XP および Windows Server 2003 でクライアント側の DNS リゾルバ
    キャッシュ を無効にする方法
    http://support.microsoft.com/kb/318803/ja
    ※WindowsXP での設定方法ですが、Windows7 でも有効です。

今度は「ドメイン名ハイジャック」ですか。

ずいぶん派手な攻撃名が付けられたものです。
毎度この手のサイバー攻撃を命名する方の素晴らしいセンスを感じないわけにはいきません。

JPCERT/CC: 「登録情報の不正書き換えによるドメイン名ハイジャックに関する注意喚起」
https://www.jpcert.or.jp/at/2014/at140044.html

ところで早速この攻撃を受けたとされる大手新聞社関連サイトのドメインを調査しに逝ってみたところ、whois情報からドメインレジストラが判明しました。こういうダダ漏れのところが大好きです、ビバ!インターネッツ!

この有名なレジストラの仕様を改めて確認したところ、あろうことか利用者登録する際に任意のIDつまりメールアドレスが使用できるようになっているようです。当ブログをお読みになっている方ならもうお分かりですね?このようなユーザ認証方式を採用している場合に真っ先に考えられるサイバー攻撃がパスワードリスト攻撃です。

つまり、今やブラックマーケットで簡単に入手できるとされているログイン情報(メールアドレス+パスワードの組み合わせが多い)の中から影響力の高そうなドメインの管理者アカウントを抽出し、whois情報からレジストラを割りだし、不正にドメイン管理者としてログインを試み、ドメイン情報の中で特に重要なネームサーバ情報を書き替え、不正サイトに誘導させるということが行われたと考えられます。

また、攻撃対象のドメインがあらかじめ分かっていてかつレジストラがメールアドレスをログインIDに用いることができる仕様になっていれば、ドメイン管理者が使用しそうなメールアドレス、例えば
webmaster@shinkaku.com
root@shinkaku.com
admin@shinkaku.com
administrator@shinkaku.com
と、ありがちなパスワードの"123456"や"password"で難なくログインに成功してしまうかもしれません。

何度も言うようですが、ログインIDにメールアドレスや任意の文字列を利用できるような仕様を放置採用しているサイト管理者の方々には対策をお勧めします。
不正ログイン防止設計について


2014/11/7 19:16 追記

海外のメジャーなレジストラのアカウント仕様をいくつか確認したところ、ログインIDを任意に設定できる方がむしろスタンダードなようです。したがって、お名前.comのようにIDが払い出されるレジストラの方が少数派かもしれません。

このページのトップヘ