パスワードを忘れた? アカウント作成
この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。

glibcに脆弱性」記事へのコメント

    1. 再起動できるサーバの場合の対処方法

      殆どのディストリビューションでは脆弱性が修正された glibc が出てるので、yum update や apt-get update をする。

      CentOS 6.7 でやってみたところ、アップデートが来てました。

      $ sudo yum update

      (略)

      ====================================================================================================
      パッケージ               アーキテクチャ    バージョン                     リポジト

    • by Anonymous Coward

      ディストリのオフィシャルなアップデートが来ないので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セグメントに収まってるという保証はありません。
          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セグメントに収まってるという保証はありません。
            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 のみで対策するのは不可能なようです。

            親コメント

普通のやつらの下を行け -- バッドノウハウ専門家

処理中...