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

Apacheに新たな脆弱性発見」記事へのコメント

  • Apacheのメーリングリストで「Mitigating the Slowloris DoS attack」というタイトルでproof-of-conceptなパッチが投稿されているのを見つけました。根本対処ではないみたいですが。パッチはこれ↓

    http://synflood.at/tmp/anti-slowloris.diff

    負荷に応じてタイムアウト時間を自動調整、みたいな感じでしょうか。IISとかはどういう防御しているんですかね?
    • Re: (スコア:3, 参考になる)

      by Anonymous Coward
      IISは、たぶん、防御が必要ないと思う。

      今回の問題は、クライアントごとにプロセスをforkする、というunixの流儀が問題なので、
      Windowsの流儀、すなわち、1プロセスで多数のクライアントの相手をし、I/O完了ポートとワーカースレッドのプーリングのしくみを使ってスレッド数をCPUコア数に沿った数に抑えるという流儀では、
      今回のような悪意あるクライアントによって消費させられるリソースは、問題になりにくいのだと思う。
      • > 今回の問題は、クライアントごとにプロセスをforkする、というunixの流儀が問題なので、

        たぶん、違うと思います。
        Apache MPM って御存じないですか? worker MPM とか、prefork MPM とか。

            http://httpd.apache.org/docs/2.2/ja/mod/worker.html [apache.org]
            http://httpd.apache.org/docs/2.2/ja/mod/repfork.html [apache.org]

        「クラ

        • by Anonymous Coward on 2009年06月24日 22時33分 (#1593188)
          MPMを使ったとしても、接続しているクライアントの数に比例して、プロセスやスレッドの消費が増えることには、変りがないと思う。
          MPMによって許容量は増えるけど、そうやって増えたキャパシティはすでに通常稼働で使ってしまっていると思う。

          自分が新人だった頃、
          1スレッドで可能なのだから、安易にスレッドを作るな、ましてや子プロセスなんてもってのほか
          って叩き込まれました。
          親コメント
          • > MPMを使ったとしても、接続しているクライアントの数に比例して、プロセスやスレッドの消費が増えることには、変りがないと思う。

            そりゃあ当たり前です。

            > MPMによって許容量は増えるけど、そうやって増えたキャパシティはすでに通常稼働で使ってしまっていると思う。

            今回の脆弱性の原因(あるいは要因)って、キャパシティの問題だったんですか?!
            で、IIS はキャパシティが大きいから大丈夫ってこと?

            違うんじゃないの?
            本当の原因を調べてないので実際のところは知らないですが、
            「IIS はクライアントごとに fork しないから大丈夫」ってのは違うんじゃないかと思うのですが。

            親コメント
            • by Anonymous Coward
              > 今回の脆弱性の原因(あるいは要因)って、キャパシティの問題だったんですか?!

              そうです。

              > で、IIS はキャパシティが大きいから大丈夫ってこと?

              違います。

              同時に接続しているクライアントの数が増えても、プロセスやスレッドは増えません。
              ゆえに、プロセス数やスレッド数の上限に達してしまう、というようなことは発生しません。

              もちろん、クライアント数が増えて行けば、ソケットやメモリという別の資源が足りなくなります。
              そういう点では、Apacheよりキャパシティが大きいとは言えますが。
            • by Anonymous Coward
              今回の問題は、クライアントからヘッダが送られてくるのを、スレッドの実行を止めて待つ、というのが原因でしょう。
              クライアントと一対一でスレッドが対話するというのは、クライアントごとにプロセスをforkするスタイルの、プロセスをスレッドに変えたものですね。

              プロセスやスレッドを無制限に作っても問題がなければ、こういうやり方でも構わないでしょうが、
              しかし、現実はそうではないので、設定ファイルに上限値を書くところがあったりするのです。

              一方、IISはどうかというと、クライアントと一対一で対話するスレッドを使うスタイルをとっていないと思います。
              おそらくメッセージ・ドリブンのような方式になっているのでしょう。
              クライアントから何か受信した後にワーカースレッドに渡されるのであれば、ワーカースレッドはクライアントからの受信を待たないので、そこがボトルネックにならないのでしょう。

長期的な見通しやビジョンはあえて持たないようにしてる -- Linus Torvalds

処理中...