アカウント名:
パスワード:
> 今回の問題は、クライアントごとにプロセスを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]
「クライアントごとにプロセスを fork」って、別に UNIX の流儀じゃないし。そういったデーモンが多いのは事実ですけどね。
元々、apache は prefork しかなかったはず。記憶に間違いが無ければ、Apache 2.0 から、MPM を選択できるようになったが、*nix 系では、prefork がデフォルトになる。configure 時に --with-mpm={beos|event|worker|prefork|mpmt_os2} が選べる（実際に自分の OS で使えるかどうかは不明）ので、試しに worker で作って slowloris.pl で遊んでみたが、少なくとも prefork よりは強そうだった。
ただ、MPMの説明 [apache.org]にもあるように、安定性や古いソフトウェアとの互換性を 必要とするサイトでは prefork でないとまずい場合もあるかもしれない。
同じようにこの攻撃で陥落するという squid は大昔から prefork ではないですよ。
squid bug 2694 [squid-cache.org]へのコメントを読むと、Squid 開発グループの見解は、「脆弱ではない」のようです。
> MPMを使ったとしても、接続しているクライアントの数に比例して、プロセスやスレッドの消費が増えることには、変りがないと思う。
そりゃあ当たり前です。
> MPMによって許容量は増えるけど、そうやって増えたキャパシティはすでに通常稼働で使ってしまっていると思う。
今回の脆弱性の原因(あるいは要因)って、キャパシティの問題だったんですか?!で、IIS はキャパシティが大きいから大丈夫ってこと?
違うんじゃないの?本当の原因を調べてないので実際のところは知らないですが、「IIS はクライアントごとに fork しないから大丈夫」ってのは違うんじゃないかと思うのですが。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
※ただしPHPを除く -- あるAdmin
防御方法は？ (スコア:3, 参考になる)
http://synflood.at/tmp/anti-slowloris.diff
負荷に応じてタイムアウト時間を自動調整、みたいな感じでしょうか。IISとかはどういう防御しているんですかね？
Re:防御方法は？ (スコア:3, 参考になる)
今回の問題は、クライアントごとにプロセスをforkする、というunixの流儀が問題なので、
Windowsの流儀、すなわち、1プロセスで多数のクライアントの相手をし、I/O完了ポートとワーカースレッドのプーリングのしくみを使ってスレッド数をCPUコア数に沿った数に抑えるという流儀では、
今回のような悪意あるクライアントによって消費させられるリソースは、問題になりにくいのだと思う。
Re:防御方法は？ (スコア:1)
> 今回の問題は、クライアントごとにプロセスを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]
「クライアントごとにプロセスを fork」って、別に UNIX の流儀じゃないし。
そういったデーモンが多いのは事実ですけどね。
Re:防御方法は？ (スコア:1)
元々、apache は prefork しかなかったはず。記憶に間違いが無ければ、Apache 2.0 から、MPM を選択できるようになったが、*nix 系では、prefork がデフォルトになる。configure 時に --with-mpm={beos|event|worker|prefork|mpmt_os2} が選べる（実際に自分の OS で使えるかどうかは不明）ので、試しに worker で作って slowloris.pl で遊んでみたが、少なくとも prefork よりは強そうだった。
ただ、MPMの説明 [apache.org]にもあるように、安定性や古いソフトウェアとの互換性を 必要とするサイトでは prefork でないとまずい場合もあるかもしれない。
Re:防御方法は？ (スコア:1, 興味深い)
同じようにこの攻撃で陥落するという squid は大昔から prefork ではないですよ。
Re:防御方法は？ (スコア:1)
squid bug 2694 [squid-cache.org]へのコメントを読むと、Squid 開発グループの見解は、「脆弱ではない」のようです。
Re: (スコア:0)
MPMによって許容量は増えるけど、そうやって増えたキャパシティはすでに通常稼働で使ってしまっていると思う。
自分が新人だった頃、
1スレッドで可能なのだから、安易にスレッドを作るな、ましてや子プロセスなんてもってのほか
って叩き込まれました。
Re:防御方法は？ (スコア:1)
> MPMを使ったとしても、接続しているクライアントの数に比例して、プロセスやスレッドの消費が増えることには、変りがないと思う。
そりゃあ当たり前です。
> MPMによって許容量は増えるけど、そうやって増えたキャパシティはすでに通常稼働で使ってしまっていると思う。
今回の脆弱性の原因(あるいは要因)って、キャパシティの問題だったんですか?!
で、IIS はキャパシティが大きいから大丈夫ってこと?
違うんじゃないの?
本当の原因を調べてないので実際のところは知らないですが、
「IIS はクライアントごとに fork しないから大丈夫」ってのは違うんじゃないかと思うのですが。
Re: (スコア:0)
そうです。
> で、IIS はキャパシティが大きいから大丈夫ってこと?
違います。
同時に接続しているクライアントの数が増えても、プロセスやスレッドは増えません。
ゆえに、プロセス数やスレッド数の上限に達してしまう、というようなことは発生しません。
もちろん、クライアント数が増えて行けば、ソケットやメモリという別の資源が足りなくなります。
そういう点では、Apacheよりキャパシティが大きいとは言えますが。
Re: (スコア:0)
クライアントと一対一でスレッドが対話するというのは、クライアントごとにプロセスをforkするスタイルの、プロセスをスレッドに変えたものですね。
プロセスやスレッドを無制限に作っても問題がなければ、こういうやり方でも構わないでしょうが、
しかし、現実はそうではないので、設定ファイルに上限値を書くところがあったりするのです。
一方、IISはどうかというと、クライアントと一対一で対話するスレッドを使うスタイルをとっていないと思います。
おそらくメッセージ・ドリブンのような方式になっているのでしょう。
クライアントから何か受信した後にワーカースレッドに渡されるのであれば、ワーカースレッドはクライアントからの受信を待たないので、そこがボトルネックにならないのでしょう。