BIND OPT Record Large UDP DDoS

先週末、6/5 20時ごろから6/7までDNS（BIND8のなかでも8.3.3)を標的したDDoSが発生していました。何を狙っていたのかというとこんな感じです。

まぁ本来の目的は置いておいて、実質「UDP53向けにでかいパケットを投げつける」という典型的なDNS向けのDDoSになってました。

かなりの量の攻撃が広範囲に渡り行われていたようです。

パケットのサンプルはこんな感じです。

 Source: x.x.x.x
 Destination: *.*.*.*
 User Datagram Protocol, Src Port: 62348 (62348), Dst Port: 53 (53)
    Source port: 62348 (62348)
    Destination port: 53 (53)
    Length: 36
    Checksum: 0x3492 [correct]
        [Good Checksum: True]
        [Bad Checksum: False]
 Non-authenticated data is unacceptable
    Questions: 1
    Answer RRs: 0
    Authority RRs: 0
    Additional RRs: 1
    Queries
        <Root>: type ANY, class IN
            Name: <Root>
            Type: ANY (Request for all records)
            Class: IN (0x0001)
    Additional records
        <Root>: type OPT
            Name: <Root>
            Type: OPT (EDNS0 option)
            UDP payload size: 65535
            Higher bits in extended RCODE: 0x0
            EDNS0 version: 0
            Z: 0x0
            Data length: 0

そしてDNSへのDDoSの際に常に発生する事象が今回も発生していました。

つまり、「DNS queryとして成立していないパケット」にもかかわらず、namedは無理矢理DNS queryとして解読して、そのアドレス解決を行おうと上位のRootDNS等に問い合わせるqueryを乱発するというものです。これはこれで上位DNSへのDDoSとして成立しまう。また、今回の攻撃のsource addressは一つのIPアドレスでしたが、攻撃を受けた各DNSがこのアドレスに向けてQuery Response（今回はアドレス解決できないのでServer Failure等）を送り返しますので、ここにもDDoSの効果が現れます。この攻撃元となったIPアドレスが無実の被害者のものだったのか、なんの改竄もせずここから攻撃が行われたものかわかりませんが。

まとめるとDNSへのDDoSは常に以下の三つの効果を生みます。

• 直接のターゲットへのDDoS
• 上位DNSへのDDoS
• ソースアドレスを改竄していた場合、このソースアドレスへのDDoS

通常のDDoSと違って2番目の問題を伴うことが特徴ですが、これはnamedがUDP53向けのパケットを何でもかんでもDNS Queryと考えて処理する残念な仕様だから発生します。

フォーマットエラーを認識するDNSやIDS等にてDNSをガードしたいものです。

[カテゴリ:botnet観察日記]

by jyake