## page was renamed from 攻撃/DDoS/リフレクター型攻撃
<<Navigation(siblings,1)>>

== 攻撃/DDoS/リフレクター攻撃 ==
<<TableOfContents()>>

リフレクターという単語の意味するものよりずっと制約された攻撃を指しているので、
用語の利用には注意が必要だと思われる。 -- ToshinoriMaeno <<DateTime(2016-09-15T08:37:49+0900)>>

オープンリゾルバーを[[../踏み台]](反射板)として使ったDoS攻撃のうち、
 IPアドレスの詐称を行うものという条件を満たすものを指しているらしい。
   http://www.iot.ipsj.or.jp/files/iot22-invited_talk page 16 あたり
    {{attachment:131226_DNS_1_480x360.jpg}}
  問い合わせしていないのに、送られてくる(偽)返事で潰されるのはどこがまずいのか。

 botはなぜ直接攻撃しないのか。
 反射板の役をさせるのはオープンリゾルバーでなくてもよいのに、
 なぜオープンリゾルバーだと言うのか。(2008年に使われたのがオープンリゾルバーだっただけ?)

 * https://jprs.jp/tech/notice/2013-04-18-reflector-attacks.html
   「DNS Amp攻撃」と呼んでいたもの。
  『リフレクターが持つ特性をサービス不能(DoS)攻撃などに悪用した攻撃手
    法を総称して「Reflector Attacks(リフレクター攻撃)」と呼びます』
   リフレクター攻撃を効率よく成立させるためには、
      攻撃にあたり以下の三つの条件を満たしている必要があります。
    [[/三条件]] は必要なのだろうか。

 * https://www.ietf.org/rfc/rfc5358.txt
 Preventing Use of Recursive Nameservers in Reflector Attacks
 * https://jprs.jp/related-info/guide/003.pdf

 * http://www.npa.go.jp/cyberpolice/detect/pdf/20151023.pdf

 * http://www.iot.ipsj.or.jp/files/iot22-invited_talk
  オープンリゾルバーを用いたDNSリフレクター攻撃の概要と対策
    (注)オープンリゾルバーの説明も違っている。

 * http://ascii.jp/elem/000/000/853/853713/

DoS攻撃に必要な条件はもっとゆるくてよい。
 JPRSは自己流の用語法を多用しているので、定義として使うのは危ない。
-- ToshinoriMaeno <<DateTime(2016-09-15T08:22:56+0900)>>
----
「脆弱なDNSサーバーやNTPサーバーを踏み台として、
攻撃トラフィックを増大させるリフレクター型攻撃」:
 これだけの表現で間違いが複数あると考える。

-- ToshinoriMaeno <<DateTime(2016-09-06T14:45:01+0900)>>

Determined, mysterious attack hits major DNS provider, causing service outages
By Brad Jones — May 26, 2016 9:34 AM

http://www.digitaltrends.com/computing/dns-provided-ns1-attacked/

DNS Reflector Attacks(DNSリフレクター攻撃)[JPRS]
 https://www.ietf.org/rfc/rfc5358.txt
  以下にもとづく用語として使っているらしい。
   Preventing Use of Recursive Nameservers in Reflector Attacks
    https://www.ietf.org/rfc/rfc5358.txt

https://security.radware.com/ddos-knowledge-center/ddospedia/reflector-reflective-dos-attacks/

Preventing Use of Recursive Nameservers in Reflector Attacks

https://www.ietf.org/rfc/rfc5358.txt

https://www.nlnetlabs.nl/downloads/publications/report-rrl-dekoning-rozekrans.pdf

== 対策 ==
DNSサーバ側での対策: Response Ratie Limitingがどれくらい有効か。

https://www.nlnetlabs.nl/downloads/publications/report-rrl-dekoning-rozekrans.pdf
{{{
Connclusion is that RRL is a proper defense against current amplification attacks,
but it is not effective against future more sophisticated attacks.
}}}

経路変更を用いた分散フィルタリングによるDNS amp 攻撃への対策手法の提案
http://www.fun.ac.jp/~y-nakamr/research/csec/68cseckatsurai.pdf