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

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

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

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

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

      $ sudo yum update

      (略)

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

    • by Anonymous Coward

      ディストリのオフィシャルなアップデートが来ないのでiptablesのフィルタを仕掛けてみたら、ちょっと前にほぼ同時に10個くらいひっかかった。
      でも、正しい(けど大きい)レスポンスなのか攻撃なのかよくわからない。保存まではしてないので。
      正規のレスポンスで2048超える事ってよくあるものなんだろうか。

      • by Printable is bad. (38668) on 2016年02月18日 18時48分 (#2966779)

        #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 のみで対策するのは不可能なようです。

            親コメント

身近な人の偉大さは半減する -- あるアレゲ人

処理中...