アカウント名:
パスワード:
殆どのディストリビューションでは脆弱性が修正された glibc が出てるので、yum update や apt-get update をする。
CentOS 6.7 でやってみたところ、アップデートが来てました。
$ sudo yum update (略) ==================================================================================================== パッケージ アーキテクチャ バージョン リポジトリー 容量====================================================================================================更新: glibc x86_64 2.12-1.166.el6_7.7 updates 3.8 M glibc-common x86_64 2.12-1.166.el6_7.7 updates 14 M glibc-devel x86_64 2.12-1.166.el6_7.7 updates 986 k glibc-headers x86_64 2.12-1.166.el6_7.7 updates 615 k トランザクションの要約====================================================================================================アップグレード 4 パッケージ 総ダウンロード容量: 20 Mこれでいいですか? [y/N]y
アップデート後は、glibc を使っているプロセスを全部再起動する必要があるので、可能であるならば OS ごと再起動(reboot)するのが確実です。
(glibcの脆弱性対策 より引用) [qiita.com]
どうしても再起動したくない場合は最低限外に通信しそうな sshd, nginx, httpd, php-fpm, mysqld, postgresql-server, postfix, dovecot, sendmail, vsftpd, elasticsearch, node, java, docker, etc, etc… あたりは個別に再起動しといたほうがいいかもねっていうかやっぱ全部だからサーバごと再起動するのが早いね!
どうしてもすぐにパッチあてや再起動ができないサーバの場合には、glibcの脆弱性対策(取り急ぎiptables/firewalldで叩き落とす!)for CVE-2015-7547 [qiita.com] を参考に、2048バイト以上のDNSレスポンスパケットをUDP/TCP共に廃棄するファイアウォールの設定を速やかに行っておきましょう。
一時的な対処ですが,名前解決に使うDNSサーバ上で,2048バイト以上のレスポンスが返らなければとりあえずの対策になるんですかね?
ディストリのオフィシャルなアップデートが来ないので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レコードに迷惑メール対策の情報・公開鍵など様々なデータを入れるのが一般的になってきているので、2048オクテット以上のDNS応答を廃棄することで、正当な通信も一部阻害されてしまう可能性もあり得ますね。
なお、glibcの脆弱性対策(取り急ぎiptables/firewalldで叩き落とす!)for CVE-2015-7547 [qiita.com] のはてブコメントでは、
「長いDNSメッセージは、複数のIPパケットで送るだけなので、iptablesで落とすって無理じゃないの?? / アプリ層のデータを複数のIPパケットで送るのはIPフラグメントとは全然別の処理だよ!」みたいに書かれていましたが、 DNS では、EDNS0 の仕様により、DNS のプロトコル自体でパケット分割行うことなく(NTPとかとは違う仕様です)、MTU (一般に1454~1500バイト)を超えるパケットの分割は下のレイヤーに任せているわけなので(TCPフォールバックの場合も同様)、 ファイアウォールにてフラグメント化されたパケットの結合後の容量を制限するか、フラグメント化されたDNS応答パケットを廃棄することで(MTUが2048以上ということは普通無いので)、とりあえずの対策にはなるかと思います。
> ファイアウォールにてフラグメント化されたパケットの結合後の容量を制限するか、フラグメント化されたDNS応答パケットを廃棄することで(MTUが2048以上ということは普通無いので)、とりあえずの対策にはなるかと思います。
ダメです。間違った対策を勧めないようにしましょう。TCPの場合、そもそも返答が1セグメントに収まってるという保証はありません。1つの返答が複数のTCPセグメントに別れて届き、それが2048バイトを越えていたらアウトです。ファイアウォールによる上記の制限では、防ぐことはできません。実際、 http://qiita.com/kawaz/items/1b07429b28851f997dba#comme [qiita.com]
TCPの場合、そもそも返答が1セグメントに収まってるという保証はありません。 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)に設定を変更する必要があります。
UNIXはシンプルである。必要なのはそのシンプルさを理解する素質だけである -- Dennis Ritchie
対処方法 (スコア:4, 参考になる)
殆どのディストリビューションでは脆弱性が修正された glibc が出てるので、yum update や apt-get update をする。
CentOS 6.7 でやってみたところ、アップデートが来てました。
アップデート後は、glibc を使っているプロセスを全部再起動する必要があるので、可能であるならば OS ごと再起動(reboot)するのが確実です。
(glibcの脆弱性対策 より引用) [qiita.com]
どうしてもすぐにパッチあてや再起動ができないサーバの場合には、glibcの脆弱性対策(取り急ぎiptables/firewalldで叩き落とす!)for CVE-2015-7547 [qiita.com] を参考に、2048バイト以上のDNSレスポンスパケットをUDP/TCP共に廃棄するファイアウォールの設定を速やかに行っておきましょう。
Re: (スコア:0)
一時的な対処ですが,
名前解決に使うDNSサーバ上で,
2048バイト以上のレスポンスが返らなければ
とりあえずの対策になるんですかね?
Re: (スコア:0)
ディストリのオフィシャルなアップデートが来ないのでiptablesのフィルタを仕掛けてみたら、ちょっと前にほぼ同時に10個くらいひっかかった。
でも、正しい(けど大きい)レスポンスなのか攻撃なのかよくわからない。保存まではしてないので。
正規のレスポンスで2048超える事ってよくあるものなんだろうか。
Re:対処方法 (スコア:3)
DNSの通信がそもそも安全性が確保されていないことので、その場合でも成り済まし攻撃は防げません。
EDNS0 (RFC 2671 の改良版の RFC 6891)の仕様では、
とあり、BINDなどの実装でもデフォルトで4096オクテットまで対応しているようです。
TXTレコードに迷惑メール対策の情報・公開鍵など様々なデータを入れるのが一般的になってきているので、2048オクテット以上のDNS応答を廃棄することで、正当な通信も一部阻害されてしまう可能性もあり得ますね。
なお、glibcの脆弱性対策(取り急ぎiptables/firewalldで叩き落とす!)for CVE-2015-7547 [qiita.com] のはてブコメントでは、
「長いDNSメッセージは、複数のIPパケットで送るだけなので、iptablesで落とすって無理じゃないの?? / アプリ層のデータを複数のIPパケットで送るのはIPフラグメントとは全然別の処理だよ!」みたいに書かれていましたが、
DNS では、EDNS0 の仕様により、DNS のプロトコル自体でパケット分割行うことなく(NTPとかとは違う仕様です)、MTU (一般に1454~1500バイト)を超えるパケットの分割は下のレイヤーに任せているわけなので(TCPフォールバックの場合も同様)、
ファイアウォールにてフラグメント化されたパケットの結合後の容量を制限するか、フラグメント化されたDNS応答パケットを廃棄することで(MTUが2048以上ということは普通無いので)、とりあえずの対策にはなるかと思います。
間違った対策は危険。スレッドストーリーも直した方が (スコア:0)
> ファイアウォールにてフラグメント化されたパケットの結合後の容量を制限するか、フラグメント化されたDNS応答パケットを廃棄することで(MTUが2048以上ということは普通無いので)、とりあえずの対策にはなるかと思います。
ダメです。
間違った対策を勧めないようにしましょう。
TCPの場合、そもそも返答が1セグメントに収まってるという保証はありません。
1つの返答が複数のTCPセグメントに別れて届き、それが2048バイトを越えていたらアウトです。
ファイアウォールによる上記の制限では、防ぐことはできません。
実際、
http://qiita.com/kawaz/items/1b07429b28851f997dba#comme [qiita.com]
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 のみで対策するのは不可能なようです。