アカウント名:
パスワード:
殆どのディストリビューションでは脆弱性が修正された glibc が出てるので、yum update や apt-get update をする。
CentOS 6.7 でやってみたところ、アップデートが来てました。
$ sudo yum update （略） ==================================================================================================== パッケージ アーキテクチャ バージョン リポジト
ディストリのオフィシャルなアップデートが来ないのでiptablesのフィルタを仕掛けてみたら、ちょっと前にほぼ同時に10個くらいひっかかった。でも、正しい（けど大きい）レスポンスなのか攻撃なのかよくわからない。保存まではしてないので。正規のレスポンスで2048超える事ってよくあるものなんだろうか。
#2966709 名前解決に使うDNSサーバ上で， 2048バイト以上のレスポンスが返らなければ とりあえずの対策になるんですかね？
DNSの通信がそもそも安全性が確保されていないことので、その場合でも成り済まし攻撃は防げません。
#2966719 正規のレスポンスで2048超える事ってよくあるものなんだろうか。
EDNS0 (RFC 2671 の改良版の RFC 6891）の仕様では、
A good compromise may be the use of an EDNS maximum payload size of 4096 octets as a starting point.
とあり、BINDなどの実装でもデフォルトで4096オクテットまで対応しているようです。
TXTレコードに迷惑メール対策の情報・公開鍵など様々なデータを入れるのが一般的に
> ファイアウォールにてフラグメント化されたパケットの結合後の容量を制限するか、フラグメント化されたDNS応答パケットを廃棄することで（MTUが2048以上ということは普通無いので）、とりあえずの対策にはなるかと思います。
ダメです。間違った対策を勧めないようにしましょう。TCPの場合、そもそも返答が１セグメントに収まってるという保証はありません。1つの返答が複数のTCPセグメントに別れて届き、それが2048バイトを越えていたらアウトです。ファイアウォールによる上記の制限では、防ぐことはできません。実際、http://qiita.com/kawaz/items/1b07429b28851f997dba#comment-c518b48fdcb9... [qiita.com]のコメントに、試したら制限できなかったという報告があります。> MSG SIZE 2048 以上の DNS Response を防げるわけでは無いようです。> 例えば、下記のコマンドで、大きな Response を受け取ることで確かめることが出来ます。>> $ dig jprs.jp any
またスレッドストーリーには以下のようにありますが
> それができない場合に向けてファイアウォールなどでレスポンスサイズを制限することで一時的な対象も可能だという。
この Google Online Security Blogで示唆されている DNSMasq でも実は対策にならない模様です。http://www.kunitake.org/chalow/2016-02-17-1.html [kunitake.org]によると、DNSMasq による制限は、TCP接続に対しては効かないようだと。
スレッドストーリーに誤った対策を書いておくのはとても危険なので、直した方が良いと思います。
今回の問題は、ファイアウォールの内側のマシンも攻撃可能ですし、影響範囲が広くて大変ですね。
TCPの場合、そもそも返答が１セグメントに収まってるという保証はありません。 1つの返答が複数のTCPセグメントに別れて届き、それが2048バイトを越えていたらアウトです。 ファイアウォールによる上記の制限では、防ぐことはできません。
ご指摘ありがとうございます。
「（iptablesで）フラグメント化されたパケットの結合後の容量を制限するか、フラグメント化されたDNS応答パケットを廃棄する」という対策は、UDPによるDNS通信（EDNS0 : RFC 6891 準拠、BIND9以降の初期設定で有効）には有効であっても、TCPフォールバック かつ 複数セグメントへ分割されたTCPパケット の攻撃は防げませんでした。お詫び申し上げます。
EDNS0（UDP）の場合は大きなデータの場合には、必ず IPフラグメンテーションが発生するので、iptables で制御可能です。
しかし、ご指摘いただいたとおり、TCPフォールバックの場合、TCPでは通信の効率化のために Maximum Segment Size（1452～1460バイトな場合が多い）ごとのセグメントに分割され、IPフラグメンテーションが発生しない2セグメントのTCPパケットとなることがあります。その場合、iptables で結合後のデータサイズをチェックしても複数セグメントの合算が行われない仕様となっているため（またフラグメンテーションされたIPパケットともみなされないため）、iptables では、TCPフォールバック かつ 複数セグメントへ分割されたTCPパケット による攻撃（2048バイト以上のDNS応答を受信してしまう）は防げませんでした。
iptables でこの攻撃を防ぐとしたら、TCPによるDNS通信を廃棄（TCPフォールバックの無効化）するしか無いようです。その場合であっても、TCPフォールバックは非効率（遅延に繋がる）であることからBIND9以降はEDNS0 がデフォルト有効なので問題が生じない場合も多いですが、EDNS0に対応していないサーバとの通信の場合には512 バイトを超える DNS メッセージを受信できなくなってしまうためTXTレコードの取得などの正常な通信にも影響が出てしまいます。弊害なく iptables のみで対策するのは不可能なようです。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
未知のハックに一心不乱に取り組んだ結果、私は自然の法則を変えてしまった -- あるハッカー
対処方法 (スコア:4, 参考になる)
殆どのディストリビューションでは脆弱性が修正された glibc が出てるので、yum update や apt-get update をする。
CentOS 6.7 でやってみたところ、アップデートが来てました。
Re: (スコア:0)
ディストリのオフィシャルなアップデートが来ないのでiptablesのフィルタを仕掛けてみたら、ちょっと前にほぼ同時に10個くらいひっかかった。
でも、正しい（けど大きい）レスポンスなのか攻撃なのかよくわからない。保存まではしてないので。
正規のレスポンスで2048超える事ってよくあるものなんだろうか。
Re: (スコア:3)
DNSの通信がそもそも安全性が確保されていないことので、その場合でも成り済まし攻撃は防げません。
EDNS0 (RFC 2671 の改良版の RFC 6891）の仕様では、
とあり、BINDなどの実装でもデフォルトで4096オクテットまで対応しているようです。
TXTレコードに迷惑メール対策の情報・公開鍵など様々なデータを入れるのが一般的に
間違った対策は危険。スレッドストーリーも直した方が (スコア:0)
> ファイアウォールにてフラグメント化されたパケットの結合後の容量を制限するか、フラグメント化されたDNS応答パケットを廃棄することで（MTUが2048以上ということは普通無いので）、とりあえずの対策にはなるかと思います。
ダメです。
間違った対策を勧めないようにしましょう。
TCPの場合、そもそも返答が１セグメントに収まってるという保証はありません。
1つの返答が複数のTCPセグメントに別れて届き、それが2048バイトを越えていたらアウトです。
ファイアウォールによる上記の制限では、防ぐことはできません。
実際、
http://qiita.com/kawaz/items/1b07429b28851f997dba#comment-c518b48fdcb9... [qiita.com]
のコメントに、試したら制限できなかったという報告があります。
> MSG SIZE 2048 以上の DNS Response を防げるわけでは無いようです。
> 例えば、下記のコマンドで、大きな Response を受け取ることで確かめることが出来ます。
>
> $ dig jprs.jp any
またスレッドストーリーには以下のようにありますが
> それができない場合に向けてファイアウォールなどでレスポンスサイズを制限することで一時的な対象も可能だという。
この Google Online Security Blogで示唆されている DNSMasq でも実は対策にならない模様です。
http://www.kunitake.org/chalow/2016-02-17-1.html [kunitake.org]
によると、DNSMasq による制限は、TCP接続に対しては効かないようだと。
スレッドストーリーに誤った対策を書いておくのはとても危険なので、直した方が良いと思います。
今回の問題は、ファイアウォールの内側のマシンも攻撃可能ですし、影響範囲が広くて大変ですね。
TCPフォールバック ＆ 複数セグメントへ分割されたTCPパケット の攻撃は防げませんでした (スコア:2)
ご指摘ありがとうございます。
「（iptablesで）フラグメント化されたパケットの結合後の容量を制限するか、フラグメント化されたDNS応答パケットを廃棄する」という対策は、UDPによるDNS通信（EDNS0 : RFC 6891 準拠、BIND9以降の初期設定で有効）には有効であっても、TCPフォールバック かつ 複数セグメントへ分割されたTCPパケット の攻撃は防げませんでした。お詫び申し上げます。
EDNS0（UDP）の場合は大きなデータの場合には、必ず IPフラグメンテーションが発生するので、iptables で制御可能です。
しかし、ご指摘いただいたとおり、TCPフォールバックの場合、TCPでは通信の効率化のために Maximum Segment Size（1452～1460バイトな場合が多い）ごとのセグメントに分割され、IPフラグメンテーションが発生しない2セグメントのTCPパケットとなることがあります。その場合、iptables で結合後のデータサイズをチェックしても複数セグメントの合算が行われない仕様となっているため（またフラグメンテーションされたIPパケットともみなされないため）、iptables では、TCPフォールバック かつ 複数セグメントへ分割されたTCPパケット による攻撃（2048バイト以上のDNS応答を受信してしまう）は防げませんでした。
iptables でこの攻撃を防ぐとしたら、TCPによるDNS通信を廃棄（TCPフォールバックの無効化）するしか無いようです。その場合であっても、TCPフォールバックは非効率（遅延に繋がる）であることからBIND9以降はEDNS0 がデフォルト有効なので問題が生じない場合も多いですが、EDNS0に対応していないサーバとの通信の場合には512 バイトを超える DNS メッセージを受信できなくなってしまうためTXTレコードの取得などの正常な通信にも影響が出てしまいます。弊害なく iptables のみで対策するのは不可能なようです。