JP4287456B2 - サービス不能攻撃を防止するサーバ装置、方法およびプログラム - Google Patents

サービス不能攻撃を防止するサーバ装置、方法およびプログラム Download PDF

Info

Publication number
JP4287456B2
JP4287456B2 JP2006291521A JP2006291521A JP4287456B2 JP 4287456 B2 JP4287456 B2 JP 4287456B2 JP 2006291521 A JP2006291521 A JP 2006291521A JP 2006291521 A JP2006291521 A JP 2006291521A JP 4287456 B2 JP4287456 B2 JP 4287456B2
Authority
JP
Japan
Prior art keywords
inquiry
message
identification information
response message
received
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Expired - Fee Related
Application number
JP2006291521A
Other languages
English (en)
Other versions
JP2008109483A (ja
Inventor
達哉 神明
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Toshiba Corp
Original Assignee
Toshiba Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Toshiba Corp filed Critical Toshiba Corp
Priority to JP2006291521A priority Critical patent/JP4287456B2/ja
Priority to US11/808,149 priority patent/US8234376B2/en
Publication of JP2008109483A publication Critical patent/JP2008109483A/ja
Application granted granted Critical
Publication of JP4287456B2 publication Critical patent/JP4287456B2/ja
Expired - Fee Related legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/14Network architectures or network communication protocols for network security for detecting or protecting against malicious traffic
    • H04L63/1441Countermeasures against malicious traffic
    • H04L63/1458Denial of Service
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00Network arrangements, protocols or services for addressing or naming
    • H04L61/45Network directories; Name-to-address mapping
    • H04L61/4505Network directories; Name-to-address mapping using standardised directories; using standardised directory access protocols
    • H04L61/4511Network directories; Name-to-address mapping using standardised directories; using standardised directory access protocols using domain name system [DNS]

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Description

この発明は、問い合わせの送信元を詐称したパケットによって増幅された応答パケットを送信することで引き起こされるサービス不能攻撃を防止するサーバ装置、方法およびプログラムに関するものである。
DNS(Domain Name System)は、ホスト名とIP(Internet Protocol)アドレスとの対応付けを提供するサーバ・クライアント型のデータベースシステムであり、インターネットにおける基幹機能の一つである。通常、DNSのクライアントは、特定のドメイン名(ホスト名など)を含む問い合わせのパケットをサーバ宛に送信し、サーバがそれを処理して該当するデータ(リソースレコードもしくは単にレコードと呼ばれる)を含む応答パケットをクライアントに返送する。
一般にDNSでは、サーバはクライアントを認証せずに応答パケットを返す。すなわち、サーバはどのようなクライアントに対しても同等の応答を行う。特に、権威(authoritative)サーバと呼ばれるDNSサーバは、原則としてインターネット上のすべてのクライアントからの問い合わせに応答する必要がある。
現在、このような権威サーバに対するサービス不能攻撃が問題となっている。この攻撃手法では、攻撃ノードは、まず、送信元アドレスを被害ノードであるかのように装った問い合わせパケットをサーバに送信する。その際、攻撃ノードは、サーバからの応答のサイズが問い合わせパケットのサイズに比べて十分に大きくなるようなドメイン名およびリソースレコードを選ぶ。一般に、DNSの応答パケットは問い合わせパケットに比べて大きくなることが多い。特に、EDNS0(Extension Mechanisms for DNS)技術や、DNSSEC(DNS Security Extensions)技術を利用している場合には、応答メッセージが送信メッセージの10倍以上となることもある。
サーバは応答パケットを問い合わせパケットの送信元アドレスに向けて送信する。ここで、送信元パケットのアドレスが詐称されているため、応答パケットは被害ノードに向けて送信されることになる。また、応答パケットのサイズが問い合わせパケットに比べて大きいことから、攻撃ノードは、より少ない帯域でより大きな被害を生じさせられる。例えば、応答メッセージのサイズが問い合わせメッセージサイズの10倍であり、攻撃ノードが利用可能なネットワーク帯域が10Mbpsであるとすると、この攻撃手法では実質的に100Mbpsの帯域を利用した場合と同等の被害が生じる。
このようなサービス不能攻撃を防止するために種々の技術が提案されている。例えば、非特許文献1では、送信元アドレスを詐称した問い合わせを防ぐために、アドレスベースによる問い合わせのフィルタを用いる技術が提案されている。この方法では、サーバが受け付ける問い合わせの送信元アドレスを所定の範囲内(通常はそのサーバが属する組織内)に限定することにより、攻撃が可能となるネットワーク上の範囲を制限している。しかし、この方法は、任意のクライアントからの問い合わせに答える必要がある権威サーバでは利用できない。
一方、非特許文献2では、DNSのプロトコルを拡張し、サーバとクライアントの間でクッキー情報をやり取りすることで、送信元アドレスを偽った問い合わせに無条件で応答しないようにする技術が提案されている。
J. Damas et.al.、 "Preventing Use of Recursive Nameservers in Reflector Attacks"、 [online]、 retrieved from the Internet: <URL: http://www.ietf.org/internet-drafts/draft-ietf-dnsop-reflectors-are-evil-02.txt> Donald E. Eastlake 3rd、 "Domain Name System (DNS) Cookies"、 [online]、 retrieved from the Internet: <URL: http://www.ietf.org/internet-drafts/draft-eastlake-dnsext-cookies-00.txt>
しかしながら、非特許文献2の方法は、権威サーバの場合にも適用可能であるが、クライアント側でも同様の方式に対応する必要があるという問題があった。したがって、現在インターネット上に多数存在する既存のクライアントのほとんどすべてが同方式に対応するまでは事実上利用不可能であるという問題があった。
本発明は、上記に鑑みてなされたものであって、クライアント側の実装を変更せずに、増幅サービス不能攻撃を防止することができるサーバ装置、攻撃防止方法および攻撃防止プログラムを提供することを目的とする。
上述した課題を解決し、目的を達成するために、本発明は、ネットワークを介して接続されたクライアント装置から、前記クライアント装置のアドレスと、問い合わせの内容を表す問い合わせ情報とを含む第1問い合わせメッセージを受信する第1受信部と、受信した前記第1問い合わせメッセージに含まれる前記アドレスに基づいた第1識別情報を算出する第1算出部と、算出された前記第1識別情報を前記問い合わせ情報に関連づけ、前記第1識別情報を関連づけた前記問い合わせ情報と、再度問い合わせるべきことを表す再送情報とを含む第1応答メッセージを生成する第1生成部と、生成された前記第1応答メッセージを前記クライアント装置に送信する第1送信部と、前記アドレスと、前記第1識別情報が関連づけられた前記問い合わせ情報とを含む第2問い合わせメッセージを前記クライアント装置から受信する第2受信部と、受信した前記第2問い合わせメッセージに含まれる前記アドレスに基づいた第2識別情報を算出する第2算出部と、受信した前記第2問い合わせメッセージに含まれる前記問い合わせ情報に関連づけられた前記第1識別情報と算出した前記第2識別情報とに基づいて、前記第2問い合わせメッセージを送信した前記クライアント装置の正当性を判断する判断部と、前記クライアント装置が正当であると判断された場合に、前記問い合わせ情報に対する応答を含む第2応答メッセージを生成する第2生成部と、生成された前記第2応答メッセージを前記クライアント装置に送信する第2送信部と、前記第1問い合わせメッセージを受信したときに、前記第1問い合わせメッセージに含まれる前記問い合わせ情報に対する応答を含む第3応答メッセージを生成する第3生成部と、を備え、前記判断部は、生成された前記第3応答メッセージのデータサイズが予め定められた閾値より大きいか否かをさらに判断し、前記第1算出部は、前記データサイズが前記閾値より大きいと判断された場合に、受信した前記第1問い合わせメッセージに含まれる前記アドレスに基づいた前記第1識別情報を算出し、前記第1生成部は、前記データサイズが前記閾値より大きいと判断された場合に、前記第1応答メッセージを生成し、前記第1送信部は、前記データサイズが前記閾値より大きいと判断された場合に、生成された前記第1応答メッセージを前記クライアント装置に送信すること、を特徴とする。
また、本発明は、上記装置を実行することができる方法およびプログラムである。
本発明によれば、クライアント側の実装を変更せずに、増幅サービス不能攻撃を防止することができるという効果を奏する。
以下に添付図面を参照して、この発明にかかるサーバ装置、攻撃防止方法および攻撃防止プログラムの最良な実施の形態を詳細に説明する。
本実施の形態にかかるサーバ装置は、クライアントからの最初の問い合わせにすぐに応答せず、リダイレクト用の応答メッセージを返信し、当該応答メッセージに対してクライアントから再度送信された問い合わせに対して応答を返すものである。このとき、リダイレクト用の応答メッセージに、送信元アドレスに依存する情報を含ませ、再度送信された問い合わせ時に当該情報を用いて正当なクライアントからの問い合わせであるか否かを判定する。
以下では、クライアントからの問い合わせに対して応答を返信するサーバ装置として、DNSサーバを用いた例について説明する。なお、適用可能な装置はDNSサーバに限られるものではなく、問い合わせに対して応答を返信する機能を有することにより、サービス不能攻撃の対象となりうる装置であればあらゆる装置に適用できる。
図1は、本実施の形態にかかるサーバ装置であるDNSサーバ100を含むネットワーク構成を示す説明図である。同図に示すように、DNSサーバ100は、インターネット500を介して、DNSの問い合わせを行うクライアントノード200と、被害ノード300と、攻撃ノード400とに接続されている。なお、被害ノード300および攻撃ノード400は、クライアントノード200のうち、特にサービス不能攻撃の被害者となるノードおよび攻撃を行うノードをそれぞれ表す。以下では、攻撃元と攻撃先とを特定しない場合は、問い合わせを行うノードを単にクライアントノード200という。
DNSサーバ100は「foo.example」というDNSゾーン(ドメイン空間の部分集合のうち、ある特定のサーバ群が管理する領域)を管理していると仮定する。また、DNSサーバ100には、増幅サービス不能攻撃を防止するための判断に用いる一定の閾値が記憶部(図示せず)に記憶されている。この閾値としては、例えば、応答パケットのサイズが問い合わせパケットの5倍以上であることといった条件を用いる。また、閾値の別な例として、応答パケットのサイズが問い合わせパケットのサイズよりも大きいこと、という条件を利用することもできる。
このような閾値を用いて、閾値を越える場合にのみ攻撃を防止する処理を行うことにより、有効でない攻撃に対する無用な攻撃防止処理の実行を回避することができる。
ここで、「foo.example」ゾーンには「www」と「zzz」という2つのドメイン名が含まれ、「www.foo.example」に対応する応答メッセージのサイズは十分に大きく、「zzz.foo.example」に対応するメッセージのサイズは十分小さいものとする。特に、「www.foo.example」に関する典型的な問い合わせメッセージのサイズに対し、その応答は上述の閾値によりサービス不能攻撃防止の対象になるものとする。一方、「zzz.foo.example」に関する典型的な問い合わせメッセージのサイズに対し、その応答は上述の閾値によりサービス不能攻撃防止の対象にならないものとする。
図2は、本実施の形態にかかるDNSサーバ100の構成を示すブロック図である。同図に示すように、DNSサーバ100は、鍵情報記憶部121と、DNSデータ記憶部122と、受信部101と、生成部102と、判断部103と、算出部104と、送信部105と、を備えている。
鍵情報記憶部121は、DNSサーバ100の管理者のみが知る秘密鍵(Secret Key)Kを記憶するものである。後述するように、この秘密鍵Kは、DNSのCNAMEレコードを利用した問い合わせのリダイレクトメッセージを生成する際に参照される。秘密鍵Kとしては、例えば128ビットの整数値を用いることができる。
DNSデータ記憶部122は、DNSサーバ100が提供するDNSゾーンのデータを保持するものである。DNSデータ記憶部122は、他のDNSサーバから得たゾーンのデータをキャッシュとして保持している場合もある。
なお、鍵情報記憶部121およびDNSデータ記憶部122は、HDD(Hard Disk Drive)、光ディスク、メモリカード、RAM(Random Access Memory)などの一般的に利用されているあらゆる記憶媒体により構成することができる。
受信部101は、クライアントノード200から各種メッセージを受信するものである。具体的には、受信部101は、名前解決を要求するドメイン名を含むDNSの問い合わせメッセージをクライアントノード200から受信する。問い合わせメッセージは、従来から用いられているDNSパケットと同様であり、送信元であるクライアントノード200のIPアドレス(送信元IPアドレス)が含まれる。
生成部102は、受信した問い合わせメッセージに対する応答メッセージを生成するものである。具体的には、生成部102は、受信した問い合わせメッセージが通常のDNSの問い合わせメッセージである場合は、別の問い合わせ名で再度問い合わせることを表す再送情報を含むリダイレクト用の応答メッセージを生成する。本実施の形態では、DNSのCNAMEレコードを再送情報として含む応答メッセージを、リダイレクト用の応答メッセージとして利用する。
CNAMEレコードとは、DNSサーバ100から返信される応答メッセージに含まれうるレコードの1つであり、「問い合わせられたドメイン名(A) CNAME Aの正式なドメイン名(標準名)」の形式で表される。DNSの仕様では、CNAMEレコードを含む応答メッセージを受信したクライアントノード200は、標準名で再度問い合わせを行うことが規定されている。
生成部102は、送信元IPアドレス、ドメイン名、および秘密鍵Kから算出されるハッシュ値を含むように編集したドメイン名を標準名として含むリダイレクト用の応答メッセージを生成する。なお、ハッシュ値は後述する算出部104が算出した値を用いる。
例えば、生成部102は、問い合わせられたドメイン名が「www.foo.example」である場合、「www.foo.example. CNAME rcnamewww.XXXX.foo.example.」のような形式のCNAMEレコードを含む応答メッセージを生成する。ここで、「rcname」はリダイレクト用のCNAMEで用いる名前であることを示す文字列である。「rcname」に続く「www」は、問い合わせられた名前のfoo.exampleドメインにおけるラベルである。「rcname」は、それに続くラベルと組み合せた結果(この場合には「rcnamewww」)が「foo.example」ゾーン内に登録されている他のドメイン名のいずれとも異なるという条件を満たしていればその選択方法は任意である。ある固定されたゾーン内に含まれるドメイン名の個数は有限であるから、このような文字列は常に選択可能である。なお、上記CNAMEレコード内の「XXXX」は、上述のハッシュ値に対応する文字列を表している。
一方、生成部102は、受信した問い合わせメッセージが、標準名で再度名前解決を要求した問い合わせメッセージ(以下、リダイレクトメッセージという。)である場合に、名前解決した結果であるリソースレコードを含む応答メッセージを生成する。具体的には、生成部102は、後述する判断部103の判断結果に応じて、標準名である編集したドメイン名の編集元となったドメイン名に対応するリソースレコードをDNSデータ記憶部122から取得して、取得したリソースレコードを応答として返すDNSの応答メッセージを生成する。
なお、生成部102は、算出したハッシュ値をリダイレクト用の問い合わせ名内に埋め込んで応答メッセージを生成する代わりに、算出したハッシュ値を所定の領域に格納した応答メッセージを生成するように構成してもよい。この場合、クライアントノード200は、応答メッセージの当該領域からハッシュ値を取得し、取得したハッシュ値を問い合わせメッセージの所定の領域に格納してDNSサーバ100に送信する。また、DNSサーバ100は、問い合わせメッセージの当該領域からハッシュ値を取得し、再計算したハッシュ値との比較に利用する。
判断部103は、受信した問い合わせメッセージがリダイレクトメッセージであるか否かを判断するとともに、リダイレクトメッセージである場合は、当該リダイレクトメッセージの正当性を鍵情報記憶部121に記憶された秘密鍵Kの情報を用いて判断するものである。正当性判断の具体的方法については後述する。
また、判断部103は、応答メッセージのデータサイズが上述の閾値より大きいか否かを判断する。閾値より大きい場合にのみリダイレクト用の応答メッセージを生成するためである。
算出部104は、受信した問い合わせメッセージに含まれる送信元IPアドレスおよびドメイン名と、秘密鍵Kから、予め定められた一方向性のハッシュ関数を用いてハッシュ値を算出するものである。このハッシュ値は、送信元のクライアントノード200の送信元IPアドレスをハッシュキーとして用いるため、正当なクライアントノード200であるか否かを識別可能な識別情報として利用することができる。また、DNSサーバ100の管理者のみが知る秘密鍵Kを用いるため、攻撃ノード400によって推測されることを回避できる。
なお、ハッシュ関数としては、MD5(Message Digest 5)、SHA1(Secure Hash Algorithm 1)などの従来から用いられているあらゆるアルゴリズムを用いた関数を利用できる。
送信部105は、生成された応答メッセージをクライアントノード200に送信するものである。
次に、このように構成された本実施の形態にかかるDNSサーバ100による応答処理について説明する。図3は、本実施の形態における応答処理の全体の流れを示すフローチャートである。
まず、受信部101が、クライアントノード200からDNSの名前解決を要求する問い合わせメッセージを受信する(ステップS301)。次に、判断部103が、問い合わせメッセージに含まれる問い合わせ対象となるドメイン名(以下、問い合わせ名という。)を確認する(ステップS302)。具体的には、判断部103は、問い合わせ名が[rcname]で始まっているか否かにより、当該問い合わせ名がリダイレクト用の問い合わせ名か否かを確認する(ステップS302)。
次に、判断部103が、問い合わせ名がリダイレクト用の問い合わせ名であるか否かを判断する(ステップS303)。リダイレクト用の問い合わせ名でない場合は(ステップS303:NO)、生成部102が、問い合わせ名に対応するリソースレコードをDNSデータ記憶部122から取得し、取得したリソースレコードを含む応答メッセージを生成する(ステップS304)。
次に、判断部103が、生成された応答メッセージのデータサイズが予め定められた閾値より大きいか否かを判断する(ステップS305)。閾値より大きくない場合は(ステップS305:NO)、送信部105は、ステップS303で生成された応答メッセージをクライアントノード200に送信する(ステップS308)。これにより、仮に攻撃ノード400からの攻撃に対応する応答メッセージであったとしても、増幅サービス攻撃として意味をなさない攻撃の場合はそのままクライアントノード200に応答メッセージを返し、DNSサーバ100上での処理負担を軽減することができる。
閾値より大きい場合は(ステップS305:YES)、算出部104は、リダイレクト用の応答メッセージを生成するときに用いるハッシュ値を算出する。具体的には、算出部104は、受信した問い合わせメッセージに含まれる送信元IPアドレスおよび問い合わせ名と、DNSデータ記憶部122に記憶されている鍵情報をそれぞれバイナリ化した数値とみなして連結した値をハッシュキーとして、所定のハッシュ関数を用いてハッシュ値を算出する(ステップS306)。
次に、生成部102は、算出されたハッシュ値を用いて編集した問い合わせ名を含むCNAMEレコードを生成し、生成したCNAMEレコードを含むリダイレクト用の応答メッセージを生成する(ステップS307)。
図4は、生成されたリダイレクト用の応答メッセージの一例を示す説明図である。同図に示すように、DNSで規定された所定のヘッダ(UDP(User Datagram Protocol)ヘッダ、DNSヘッダ)に加えて、応答としてCNAMEレコードを含むDNSパケットが、リダイレクト用の応答メッセージとして生成される。
同図は、問い合わせ名が「www.foo.example」である場合に生成されるリダイレクト用の応答メッセージの例を表している。同図に示すように、当該応答メッセージには、「www.foo.example. CNAME rcnamewww.XXXX.foo.example.」がCNAMEレコードとして含まれる。なお、「XXXX」は、算出されたハッシュ値をBASE64などのアルゴリズムでアスキー文字列にエンコードした値である。
図3に戻り、送信部105は、ステップS307で生成されたリダイレクト用の応答メッセージをクライアントノード200に送信する(ステップS308)。生成されたリダイレクト用の応答メッセージは、上述のようにCNAMEレコードのみを含むため、データサイズは問い合わせメッセージのデータサイズとほぼ同等である。従って、このメッセージによる増幅効果が存在するとしても軽微である。
ステップS303でリダイレクト用の問い合わせ名であると判断された場合は(ステップS303:YES)、算出部104は、問い合わせメッセージの正当性を検証するためのハッシュ値を算出する。具体的には、算出部104は、まず、リダイレクト用の問い合わせ名から元の問い合わせ名を抽出する。例えば、リダイレクト用の問い合わせ名が「rcnamewww.XXXX.foo.example」であった場合、「rcname」と、ハッシュ値をエンコードした部分に対応する「XXXX.」を削除することにより、元の問い合わせ名である「www.foo.example」を抽出する。
次に、算出部104は、受信した問い合わせメッセージに含まれる送信元IPアドレスと、抽出した元の問い合わせ名と、DNSデータ記憶部122に記憶されている鍵情報とをそれぞれバイナリ化した数値とみなして連結した値をハッシュキーとして、ステップS306で用いたものと同じハッシュ関数を用いてハッシュ値を算出する(ステップS309)。
次に、判断部103が、リダイレクト用の問い合わせ名に含まれるハッシュ値と、算出したハッシュ値とが一致するか否かを判断する(ステップS310)。一致する場合は(ステップS310:YES)、生成部102が、抽出した問い合わせ名に対応するリソースレコードをDNSデータ記憶部122から取得し、取得したリソースレコードを名前解決の結果として含む応答メッセージを生成する(ステップS311)。
次に、送信部105が、生成した応答メッセージをクライアントノード200に送信し(ステップS312)、応答処理を終了する。
ステップS310でハッシュ値が一致しないと判断された場合(ステップS310:NO)、判断部103は、受信した応答メッセージを破棄し(ステップS313)、応答処理を終了する。
次に、本実施の形態にかかるDNSサーバ100による攻撃防止処理の具体例について説明する。最初に、正当なクライアントノード200がDNSサーバ100に対して「www.foo.example」というドメイン名の名前解決を要求する問い合わせメッセージを送信するときの動作について説明する。
まず、判断部103がドメイン名(問い合わせ名)について確認し(ステップS302)、ゾーン内のラベル(ピリオドで区切られるドメイン名の部分文字列)である「www」はリダイレクト用のラベル名の形式(rcnamewww)ではないと判断する(ステップS303:NO)。
次に、判断部103により、応答メッセージのサイズが閾値より大きいか否かが判断される(ステップS305)。上述の仮定(「www.foo.example」に対応する応答メッセージのサイズは十分に大きい)により、応答サイズが閾値を超えていると判断されたとすると(ステップS305:YES)、リダイレクト用の応答メッセージが生成される(ステップS307)。
この例では、送信元IPアドレスと問い合わせ名と秘密鍵Kとからハッシュ関数を用いてハッシュ値を算出し、算出したハッシュ値をエンコードした「XXXX」を含むCNAMEレコード「www.foo.example. CNAME rcnamewww.XXXX.foo.example.」を含む応答メッセージが生成される。
なお、以下では便宜上、送信元IPアドレス(Cとする)と、問い合わせ名(www.foo.example.)と、秘密鍵Kとからハッシュ関数で求めた「XXXX」を以下の(1)式のように表すこととする。
XXXX = hash-encode(C, www.foo.example, K)・・・(1)
クライアントノード200は、この応答メッセージを受け取ると、CNAMEレコードで指定された名前、すなわち「rcnamewww.XXXX.foo.example.」に対する問い合わせメッセージを再度送信する。以下、この問い合わせメッセージを受けたDNSサーバ100の動作を説明する。
まず、判断部103が問い合わせ名について確認し(ステップS302)、ゾーン内のラベルが「rcnamewww」であることから、リダイレクト用の問い合わせ名であると判断する(ステップS303:YES)。
次に、問い合わせ名の検証処理が行われる。まず、「rcname」に続くラベルの一部「www」を取り出し、さらにハッシュ値のエンコード部分に相当する「XXXX.」を削除した問い合わせ名を用いて、以下の(2)式で表される値を計算する。
hash-encode(C', www.foo.example, K)・・・(2)
ここで、C'は問い合わせメッセージの送信元IPアドレスである。この例では、クライアントノード200は正当なクライアントであるため、CとC'は一致し、算出結果は「XXXX」となる。これが問い合わせ名に含まれるハッシュ値部分と一致することから(ステップS310:YES)、この問い合わせメッセージは正当であると判断される。そこで、本来問い合わせられた名前である「www.foo.example」に対応するレコードを含む応答を、送信元IPアドレスがC’であるクライアントノード200に送信する(ステップS312)。
この結果、クライアントノード200は、本来必要としていた「www.foo.example」に対する応答結果を得ることができる。
次に、正当なクライアントが別なドメイン名「zzz.foo.example」に関する問い合わせメッセージを受信したDNSサーバ100の動作について説明する。
まず、判断部103が問い合わせ名について確認し(ステップS302)、ゾーン内のラベルである「zzz」はリダイレクト用のラベル名の形式(rcnamezzz)ではないと判断する(ステップS303:NO)。
次に、判断部103により、応答メッセージのサイズが閾値より大きいか否かが判断される(ステップS305)。上述の仮定(「zzz.foo.example」に対応する応答メッセージのサイズは十分に小さい)により、応答サイズが閾値を超えていないと判断されたとすると(ステップS305:NO)、通常の応答メッセージが送信される(ステップS308)。
次に、攻撃ノード400が送信元IPアドレスを偽って、「www.foo.example」の問い合わせをDNSサーバ100に送信した場合の動作について説明する。この場合、正当なクライアントノード200からの問い合わせと同様に、応答メッセージサイズが閾値を超えていることから(ステップS305:YES)、以下のCNAMEレコードとして「www.foo.example. CNAME rcnamewww.YYYY.foo.example.」を含むリダイレクト用の応答メッセージを送信する(ステップS308)。
ここで、「YYYY」は以下の(3)式により算出される。
YYYY = hash-encode(V, www.foo.example, K) ・・・(3)
ただし、Vは被害ノード300のIPアドレスであり、攻撃ノード400によって詐称され、問い合わせの送信元IPアドレスとして用いられているものとする。
この応答メッセージは被害ノード300に送信されるが、被害ノード300はこれに対する問い合わせメッセージを送信していないため、この応答メッセージを無視し、その時点で処理は完了する。この場合、CNAMEレコードのみを含むリダイレクト用の応答メッセージと問い合わせメッセージのデータサイズはほぼ同等であるため、増幅サービス不能攻撃としては有効なものとならない。
一方、攻撃ノード400は、増幅された応答メッセージが被害ノード300に返されるようにするためには、(3)式により求めた「YYYY」を含む問い合わせ名「rcnamewww.YYYY.foo.example」をDNSサーバ100に送信する必要がある。しかし、そのためにはDNSサーバ100の管理者のみが知る秘密鍵Kが必要となる。しかし、通常、攻撃ノード400が秘密鍵Kの値を知る方法が存在しないため、攻撃ノード400は「YYYY」を算出することができず、増幅サービス不能攻撃を実現することができない。
ここで、従来技術との比較について説明する。図5は、従来のDNSサーバ900による応答処理の概要を説明する模式図である。また、図6は、本実施の形態のDNSサーバ100による応答処理の概要を説明する模式図である。
図5で、攻撃ノード400が送信元IPアドレスを被害ノード300の送信元IPアドレス(V)と偽って問い合わせ名「www.foo.example」の問い合わせメッセージを送信すると(1)、DNSサーバ900は、問い合わせ名「www.foo.example」に対応するIPアドレス(a,a,a,a)を含む応答メッセージを、被害ノード300に送信する(2)。したがって、従来のDNSサーバ900では、応答メッセージのサイズが大きい場合に、攻撃ノード400による増幅サービス不能攻撃が成立することになる。
一方、図6では、攻撃ノード400が送信元IPアドレスを被害ノード300の送信元IPアドレス(V)と偽って問い合わせ名「www.foo.example」の問い合わせメッセージを送信したとしても(1)、DNSサーバ100は、直ちに名前解決したアドレスを含む応答メッセージは送信しない。代わりに、DNSサーバ100は、CNAMEレコードを含むサイズの小さいリダイレクトメッセージを送信する(2)。このため、攻撃ノード400は有効な増幅サービス不能攻撃を実行できない。また、上述のように、秘密鍵Kを知ることができないため、攻撃ノード400はリダイレクト用の問い合わせ名を不正に生成することができない。すなわち、攻撃ノード400は、リダイレクト用の問い合わせ名を用いた増幅サービス不能攻撃を実行することもできない。
このように、本実施の形態によれば、問い合わせに対応する適切なデータを応答するサーバ・クライアント型通信システムで、送信元を偽った問い合わせメッセージに対して大きなサイズの応答メッセージを送信することによる別の通信装置への増幅したサービス不能攻撃が成立することを防止でき、この通信システムにおけるセキュリティを向上させることが可能となる。
また、本実施の形態では、クライアント側は標準的なDNSのCNAMEレコードの処理手順にしたがった処理を行うのみである。すなわち、クライアント側で特別に対応することなく増幅効果によるサービス不能攻撃を防止することでき、防止効果を得るための開発および運用コストを下げることが可能となる。
図7は、本実施の形態にかかるDNSサーバのハードウェア構成を示す説明図である。
本実施の形態にかかるDNSサーバは、CPU(Central Processing Unit)51などの制御装置と、ROM(Read Only Memory)52やRAM53などの記憶装置と、ネットワークに接続して通信を行う通信I/F54と、HDD(Hard Disk Drive)、CD(Compact Disc)ドライブ装置などの外部記憶装置と、ディスプレイ装置などの表示装置と、キーボードやマウスなどの入力装置と、各部を接続するバス61を備えており、通常のコンピュータを利用したハードウェア構成となっている。
本実施の形態にかかるDNSサーバで実行される攻撃防止プログラムは、インストール可能な形式又は実行可能な形式のファイルでCD−ROM(Compact Disk Read Only Memory)、フレキシブルディスク(FD)、CD−R(Compact Disk Recordable)、DVD(Digital Versatile Disk)等のコンピュータで読み取り可能な記録媒体に記録されて提供される。
また、本実施の形態にかかるDNSサーバで実行される攻撃防止プログラムを、インターネット等のネットワークに接続されたコンピュータ上に格納し、ネットワーク経由でダウンロードさせることにより提供するように構成してもよい。また、本実施の形態にかかるDNSサーバで実行される攻撃防止プログラムをインターネット等のネットワーク経由で提供または配布するように構成してもよい。
また、本実施の形態の攻撃防止プログラムを、ROM等に予め組み込んで提供するように構成してもよい。
本実施の形態にかかるDNSサーバで実行される攻撃防止プログラムは、上述した各部(受信部、生成部、判断部、算出部、送信部)を含むモジュール構成となっており、実際のハードウェアとしてはCPU51(プロセッサ)が上記記憶媒体から攻撃防止プログラムを読み出して実行することにより上記各部が主記憶装置上にロードされ、上述した各部が主記憶装置上に生成されるようになっている。
以上のように、本発明にかかるサーバ装置、攻撃防止方法および攻撃防止プログラムは、問い合わせに対してサイズの大きい応答を返すDNSサーバに適している。
DNSサーバを含むネットワーク構成を示す説明図である。 DNSサーバの構成を示すブロック図である。 応答処理の全体の流れを示すフローチャートである。 リダイレクト用の応答メッセージの一例を示す説明図である。 従来のDNSサーバによる応答処理の概要を説明する模式図である。 本実施の形態のDNSサーバによる応答処理の概要を説明する模式図である。 本実施の形態にかかるDNSサーバのハードウェア構成を示す説明図である。
符号の説明
51 CPU
52 ROM
53 RAM
54 通信I/F
61 バス
100 DNSサーバ
101 受信部
102 生成部
103 判断部
104 算出部
105 送信部
121 鍵情報記憶部
122 DNSデータ記憶部
200 クライアントノード
300 被害ノード
400 攻撃ノード
500 インターネット
900 DNSサーバ

Claims (10)

  1. ネットワークを介して接続されたクライアント装置から、前記クライアント装置のアドレスと、問い合わせの内容を表す問い合わせ情報とを含む第1問い合わせメッセージを受信する第1受信部と、
    受信した前記第1問い合わせメッセージに含まれる前記アドレスに基づいた第1識別情報を算出する第1算出部と、
    算出された前記第1識別情報を前記問い合わせ情報に関連づけ、前記第1識別情報を関連づけた前記問い合わせ情報と、再度問い合わせるべきことを表す再送情報とを含む第1応答メッセージを生成する第1生成部と、
    生成された前記第1応答メッセージを前記クライアント装置に送信する第1送信部と、
    前記アドレスと、前記第1識別情報が関連づけられた前記問い合わせ情報とを含む第2問い合わせメッセージを前記クライアント装置から受信する第2受信部と、
    受信した前記第2問い合わせメッセージに含まれる前記アドレスに基づいた第2識別情報を算出する第2算出部と、
    受信した前記第2問い合わせメッセージに含まれる前記問い合わせ情報に関連づけられた前記第1識別情報と算出した前記第2識別情報とに基づいて、前記第2問い合わせメッセージを送信した前記クライアント装置の正当性を判断する判断部と、
    前記クライアント装置が正当であると判断された場合に、前記問い合わせ情報に対する応答を含む第2応答メッセージを生成する第2生成部と、
    生成された前記第2応答メッセージを前記クライアント装置に送信する第2送信部と、
    前記第1問い合わせメッセージを受信したときに、前記第1問い合わせメッセージに含まれる前記問い合わせ情報に対する応答を含む第3応答メッセージを生成する第3生成部と、を備え、
    前記判断部は、生成された前記第3応答メッセージのデータサイズが予め定められた閾値より大きいか否かをさらに判断し、
    前記第1算出部は、前記データサイズが前記閾値より大きいと判断された場合に、受信した前記第1問い合わせメッセージに含まれる前記アドレスに基づいた前記第1識別情報を算出し、
    前記第1生成部は、前記データサイズが前記閾値より大きいと判断された場合に、前記第1応答メッセージを生成し、
    前記第1送信部は、前記データサイズが前記閾値より大きいと判断された場合に、生成された前記第1応答メッセージを前記クライアント装置に送信すること、
    を特徴とするサーバ装置。
  2. 前記第1算出部は、受信した前記第1問い合わせメッセージに含まれる前記アドレスと予め定められた鍵情報とに基づいた前記第1識別情報を算出し、
    前記第2算出部は、受信した前記第2問い合わせメッセージに含まれる前記アドレスと前記鍵情報とに基づいた前記第2識別情報を算出すること、
    を特徴とする請求項1に記載のサーバ装置。
  3. 前記第1算出部は、受信した前記第1問い合わせメッセージに含まれる前記問い合わせ情報と、受信した前記第1問い合わせメッセージに含まれる前記アドレスと、前記鍵情報とに基づいた前記第1識別情報を算出し、
    前記第2算出部は、受信した前記第2問い合わせメッセージに含まれる前記問い合わせ情報と、受信した前記第2問い合わせメッセージに含まれる前記アドレスと、前記鍵情報とに基づいた前記第2識別情報を算出すること、
    を特徴とする請求項2に記載のサーバ装置。
  4. 前記第1算出部は、予め定められたハッシュ関数により、受信した前記第1問い合わせメッセージに含まれる前記アドレスのハッシュ値である前記第1識別情報を算出し、
    前記第2算出部は、前記ハッシュ関数により、受信した前記第2問い合わせメッセージに含まれる前記アドレスのハッシュ値である前記第2識別情報を算出し、
    前記判断部は、受信した前記第2問い合わせメッセージに含まれる前記問い合わせ情報に関連づけられた前記第1識別情報と算出した前記第2識別情報とが一致する場合に、前記第2問い合わせメッセージを送信した前記クライアント装置が正当であると判断すること、
    を特徴とする請求項1に記載のサーバ装置。
  5. 前記第1送信部は、前記データサイズが前記閾値より大きくないと判断された場合に、生成された前記第3応答メッセージを前記クライアント装置に送信すること、
    を特徴とする請求項に記載のサーバ装置。
  6. 前記第1受信部は、DNS(Domain Name System)で名前解決を要求するドメイン名を前記問い合わせ情報として含む前記第1問い合わせメッセージを受信し、
    前記第1生成部は、DNSのCNAMEレコードを前記再送情報として含む前記第1応答メッセージを生成すること、
    を特徴とする請求項1に記載のサーバ装置。
  7. 前記第1生成部は、予め定められた付加情報を前記第1識別情報に付加した前記ドメイン名を前記ドメイン名に対応する標準名として含む前記CNAMEレコードを前記再送情報として含む前記第1応答メッセージを生成すること、
    を特徴とする請求項に記載のサーバ装置。
  8. 前記第2生成部は、前記第1識別情報と前記第2識別情報とが一致すると判断された場合に、受信した前記第2問い合わせメッセージに含まれる前記CNAMEレコードに含まれる前記標準名から前記ドメイン名を取得し、取得した前記ドメイン名に対する応答を含む前記第2応答メッセージを生成すること、
    を特徴とする請求項に記載のサーバ装置。
  9. クライアント装置にネットワークを介して接続されたサーバ装置におけるサービス不能攻撃に対する攻撃防止方法であって、
    第1受信部、前記クライアント装置から、前記クライアント装置のアドレスと、問い合わせの内容を表す問い合わせ情報とを含む第1問い合わせメッセージを受信する第1受信ステップと、
    第1算出部、受信した前記第1問い合わせメッセージに含まれる前記アドレスに基づいた第1識別情報を算出する第1算出ステップと、
    第1生成部、算出された前記第1識別情報を前記問い合わせ情報に関連づけ、前記第1識別情報を関連づけた前記問い合わせ情報と、再度問い合わせるべきことを表す再送情報とを含む第1応答メッセージを生成する第1生成ステップと、
    第1送信部、生成された前記第1応答メッセージを前記クライアント装置に送信する第1送信ステップと、
    第2受信部、前記アドレスと、前記第1識別情報が関連づけられた前記問い合わせ情報とを含む第2問い合わせメッセージを前記クライアント装置から受信する第2受信ステップと、
    第2算出部、受信した前記第2問い合わせメッセージに含まれる前記アドレスに基づいた第2識別情報を算出する第2算出ステップと、
    判断部、受信した前記第2問い合わせメッセージに含まれる前記問い合わせ情報に関連づけられた前記第1識別情報と算出した前記第2識別情報とに基づいて、前記第2問い合わせメッセージを送信した前記クライアント装置の正当性を判断する判断ステップと、
    第2生成部、前記クライアント装置が正当であると判断された場合に、前記問い合わせ情報に対する応答を含む第2応答メッセージを生成する第2生成ステップと、
    第2送信部、生成された前記第2応答メッセージを前記クライアント装置に送信する第2送信ステップと、
    第3生成部が、前記第1問い合わせメッセージを受信したときに、前記第1問い合わせメッセージに含まれる前記問い合わせ情報に対する応答を含む第3応答メッセージを生成する第3生成ステップと、を備え、
    前記判断ステップは、生成された前記第3応答メッセージのデータサイズが予め定められた閾値より大きいか否かをさらに判断し、
    前記第1算出ステップは、前記データサイズが前記閾値より大きいと判断された場合に、受信した前記第1問い合わせメッセージに含まれる前記アドレスに基づいた前記第1識別情報を算出し、
    前記第1生成ステップは、前記データサイズが前記閾値より大きいと判断された場合に、前記第1応答メッセージを生成し、
    前記第1送信ステップは、前記データサイズが前記閾値より大きいと判断された場合に、生成された前記第1応答メッセージを前記クライアント装置に送信すること、
    を特徴とする攻撃防止方法。
  10. クライアント装置にネットワークを介して接続されたサーバ装置におけるサービス不能攻撃に対する攻撃防止プログラムであって、
    前記クライアントから、前記クライアント装置のアドレスと、問い合わせの内容を表す問い合わせ情報とを含む第1問い合わせメッセージを受信する第1受信手順と、
    受信した前記第1問い合わせメッセージに含まれる前記アドレスに基づいた第1識別情報を算出する第1算出手順と、
    算出された前記第1識別情報を前記問い合わせ情報に関連づけ、前記第1識別情報を関連づけた前記問い合わせ情報と、再度問い合わせるべきことを表す再送情報とを含む第1応答メッセージを生成する第1生成手順と、
    生成された前記第1応答メッセージを前記クライアント装置に送信する第1送信手順と、
    前記アドレスと、前記第1識別情報が関連づけられた前記問い合わせ情報とを含む第2問い合わせメッセージを前記クライアント装置から受信する第2受信手順と、
    受信した前記第2問い合わせメッセージに含まれる前記アドレスに基づいた第2識別情報を算出する第2算出手順と、
    受信した前記第2問い合わせメッセージに含まれる前記問い合わせ情報に関連づけられた前記第1識別情報と算出した前記第2識別情報とに基づいて、前記第2問い合わせメッセージを送信した前記クライアント装置の正当性を判断する判断手順と、
    前記クライアント装置が正当であると判断された場合に、前記問い合わせ情報に対する応答を含む第2応答メッセージを生成する第2生成手順と、
    生成された前記第2応答メッセージを前記クライアント装置に送信する第2送信手順と、
    前記第1問い合わせメッセージを受信したときに、前記第1問い合わせメッセージに含まれる前記問い合わせ情報に対する応答を含む第3応答メッセージを生成する第3生成手順と、を前記サーバ装置に実行させるための攻撃防止プログラムであって、
    前記判断手順は、生成された前記第3応答メッセージのデータサイズが予め定められた閾値より大きいか否かをさらに判断し、
    前記第1算出手順は、前記データサイズが前記閾値より大きいと判断された場合に、受信した前記第1問い合わせメッセージに含まれる前記アドレスに基づいた前記第1識別情報を算出し、
    前記第1生成手順は、前記データサイズが前記閾値より大きいと判断された場合に、前記第1応答メッセージを生成し、
    前記第1送信手順は、前記データサイズが前記閾値より大きいと判断された場合に、生成された前記第1応答メッセージを前記クライアント装置に送信すること、
    を特徴とする攻撃防止プログラム。
JP2006291521A 2006-10-26 2006-10-26 サービス不能攻撃を防止するサーバ装置、方法およびプログラム Expired - Fee Related JP4287456B2 (ja)

Priority Applications (2)

Application Number Priority Date Filing Date Title
JP2006291521A JP4287456B2 (ja) 2006-10-26 2006-10-26 サービス不能攻撃を防止するサーバ装置、方法およびプログラム
US11/808,149 US8234376B2 (en) 2006-10-26 2007-06-07 Server apparatus and method of preventing denial of service attacks, and computer program product

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2006291521A JP4287456B2 (ja) 2006-10-26 2006-10-26 サービス不能攻撃を防止するサーバ装置、方法およびプログラム

Publications (2)

Publication Number Publication Date
JP2008109483A JP2008109483A (ja) 2008-05-08
JP4287456B2 true JP4287456B2 (ja) 2009-07-01

Family

ID=39331665

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2006291521A Expired - Fee Related JP4287456B2 (ja) 2006-10-26 2006-10-26 サービス不能攻撃を防止するサーバ装置、方法およびプログラム

Country Status (2)

Country Link
US (1) US8234376B2 (ja)
JP (1) JP4287456B2 (ja)

Families Citing this family (20)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7958555B1 (en) * 2007-09-28 2011-06-07 Trend Micro Incorporated Protecting computer users from online frauds
US8261351B1 (en) * 2008-01-22 2012-09-04 F5 Networks, Inc. DNS flood protection platform for a network
CN101383830A (zh) * 2008-10-28 2009-03-11 成都市华为赛门铁克科技有限公司 一种防护网络攻击的方法、系统及网关、域名系统
KR101063321B1 (ko) * 2009-11-05 2011-09-07 삼성에스디에스 주식회사 유해 트래픽 차단 장치 및 방법
FR2954547B1 (fr) * 2009-12-21 2012-10-12 Alcatel Lucent Procede de detection d?un detournement de ressources informatiques
US8407471B1 (en) * 2010-08-24 2013-03-26 Symantec Corporation Selecting a network service for communicating with a server
US8572680B2 (en) 2011-08-11 2013-10-29 Verisign, Inc. White listing DNS top-talkers
JP6171597B2 (ja) * 2013-06-10 2017-08-02 富士通株式会社 検証システム,検証方法,検証プログラム
JP5922622B2 (ja) * 2013-07-30 2016-05-24 日本電信電話株式会社 制御装置、通信システム、および、通信制御方法
JP5985462B2 (ja) 2013-12-24 2016-09-06 シャープ株式会社 画像処理装置及び画像処理装置の遠隔操作システム
US9246875B2 (en) 2013-12-31 2016-01-26 Dropbox, Inc. Identifying and blocking prohibited content items in a content management system
US9544266B2 (en) 2014-06-27 2017-01-10 Microsoft Technology Licensing, Llc NSEC3 performance in DNSSEC
US10320739B2 (en) * 2014-12-12 2019-06-11 Donuts Inc. Communication using DNS repurposing
US10530758B2 (en) * 2015-12-18 2020-01-07 F5 Networks, Inc. Methods of collaborative hardware and software DNS acceleration and DDOS protection
DE102016212816A1 (de) * 2016-07-13 2018-01-18 Robert Bosch Gmbh Verfahren und Vorrichtung zum Betreiben eines Bussystems
CN106302859B (zh) * 2016-09-09 2019-03-08 中国互联网络信息中心 一种dnssec否定应答的响应及处理方法
US10547636B2 (en) * 2016-12-28 2020-01-28 Verisign, Inc. Method and system for detecting and mitigating denial-of-service attacks
CN110636006B (zh) * 2018-06-25 2021-11-02 中国电信股份有限公司 域名查询方法和系统、路由节点、控制节点和防护节点
US11178107B2 (en) * 2019-09-30 2021-11-16 Michael Schloss System and method for detecting surreptitious packet rerouting
US20240048587A1 (en) * 2022-08-02 2024-02-08 Centurylink Intellectual Property Llc Systems and methods for mitigating domain name system amplification attacks

Family Cites Families (21)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP3688830B2 (ja) * 1995-11-30 2005-08-31 株式会社東芝 パケット転送方法及びパケット処理装置
US5958053A (en) * 1997-01-30 1999-09-28 At&T Corp. Communications protocol with improved security
US7363361B2 (en) * 2000-08-18 2008-04-22 Akamai Technologies, Inc. Secure content delivery system
US6324648B1 (en) * 1999-12-14 2001-11-27 Gte Service Corporation Secure gateway having user identification and password authentication
JP3526435B2 (ja) * 2000-06-08 2004-05-17 株式会社東芝 ネットワークシステム
US20060212572A1 (en) * 2000-10-17 2006-09-21 Yehuda Afek Protecting against malicious traffic
EP1368947B1 (en) * 2001-03-02 2006-08-30 Nokia Corporation Addressing method and system for using an anycast address
JP3509767B2 (ja) * 2001-03-29 2004-03-22 ミノルタ株式会社 電子メール送信装置、方法、プログラム、および、記録媒体
US7124173B2 (en) * 2001-04-30 2006-10-17 Moriarty Kathleen M Method and apparatus for intercepting performance metric packets for improved security and intrusion detection
US6907525B2 (en) * 2001-08-14 2005-06-14 Riverhead Networks Inc. Protecting against spoofed DNS messages
US7284272B2 (en) * 2002-05-31 2007-10-16 Alcatel Canada Inc. Secret hashing for TCP SYN/FIN correspondence
JP2004194196A (ja) 2002-12-13 2004-07-08 Ntt Docomo Inc パケット通信認証システム、通信制御装置及び通信端末
US7900254B1 (en) * 2003-01-24 2011-03-01 Mcafee, Inc. Identifying malware infected reply messages
JP2005101936A (ja) * 2003-09-25 2005-04-14 Canon Inc 通信装置及び通信装置の制御方法
US20050240989A1 (en) * 2004-04-23 2005-10-27 Seoul National University Industry Foundation Method of sharing state between stateful inspection firewalls on mep network
US7593740B2 (en) * 2004-05-12 2009-09-22 Google, Inc. Location-based social software for mobile devices
JP4723949B2 (ja) 2004-08-09 2011-07-13 日本電信電話株式会社 アクセス制御システム、アクセス制御方法およびアクセス制御プログラム
KR100673514B1 (ko) 2005-02-04 2007-01-24 주식회사 파이오링크 SlP 로드밸런서에서 레지스터 기능을 수행하는 방법 및이를 수행하는 SlP로드밸런서
US7970878B1 (en) * 2005-11-16 2011-06-28 Cisco Technology, Inc. Method and apparatus for limiting domain name server transaction bandwidth
US8613088B2 (en) * 2006-02-03 2013-12-17 Cisco Technology, Inc. Methods and systems to detect an evasion attack
JP4516594B2 (ja) * 2007-12-27 2010-08-04 株式会社日立製作所 メッセージ送信制御方法、メッセージ送信制御装置、及びメッセージ送信制御プログラム

Also Published As

Publication number Publication date
US8234376B2 (en) 2012-07-31
US20080104182A1 (en) 2008-05-01
JP2008109483A (ja) 2008-05-08

Similar Documents

Publication Publication Date Title
JP4287456B2 (ja) サービス不能攻撃を防止するサーバ装置、方法およびプログラム
US9985994B2 (en) Enforcing compliance with a policy on a client
US9419999B2 (en) Method and device for preventing domain name system spoofing
Ariyapperuma et al. Security vulnerabilities in DNS and DNSSEC
EP1361728B1 (en) Peer-to-peer name resolution protocol (pnrp) security infrastructure and method
US7620733B1 (en) DNS anti-spoofing using UDP
JP5350649B2 (ja) ユーザを認証する方法、ユーザ端末を認証する装置、及びユーザ端末を認証する認証サーバ
CN108632221B (zh) 定位内网中的受控主机的方法、设备及系统
Schmid Thirty years of DNS insecurity: Current issues and perspectives
Beernink Taking the quantum leap: Preparing dnssec for post quantum cryptography
JP2011049745A (ja) Dnsキャッシュ・ポイズニング攻撃を防御する装置
Al-Dalky et al. Practical challenge-response for DNS
Pansa et al. Architecture and protocols for secure LAN by using a software-level certificate and cancellation of ARP protocol
JP5095675B2 (ja) Dns応答制御装置、dns応答制御システム、dns応答制御方法およびdns応答制御プログラム
JP2007258986A (ja) 通信装置、通信方法および通信プログラム
Zhao et al. Analysis of existing privacy-preserving protocols in domain name system
JP5846652B2 (ja) キャッシュ機能を有するプロキシdnsサーバ及びdnsクエリ応答方法
JP5180146B2 (ja) Dnsメッセージ回送装置、dnsメッセージ回送システム、dnsメッセージ回送方法およびdnsメッセージ回送プログラム
Contributors Relevant DNSSEC Concepts and Basic Building Blocks
Chomsiri Architecture and Protocols for Secure LAN

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20080327

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20080825

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20080902

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20081023

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20090317

A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20090326

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20120403

Year of fee payment: 3

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20120403

Year of fee payment: 3

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20130403

Year of fee payment: 4

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20140403

Year of fee payment: 5

LAPS Cancellation because of no payment of annual fees