Apacheに新たな脆弱性発見 39
ストーリー by hylom
Slowlorisはワシントン条約で保護されている小型のサルだそうで 部門より
Slowlorisはワシントン条約で保護されている小型のサルだそうで 部門より
あるAnonymous Coward 曰く、
Apacheに、DoS攻撃に繋がる脆弱性が新たに見つかったそうだ（本家/.記事より）
この脆弱性は、これを利用したHTTP DoSツール「Slowloris」がリリースされたことから明らかになったとのこと。この攻撃ツールはApacheに不完全なリクエストヘッダーを送り続けるもので、Apacheが最後のヘッダが送られてくるのを待つ間、偽のヘッダを送ることで接続をオープンにし続け、Apacheのプロセスを一杯にさせるものだという。
脆弱性はApache 1.x、 2.x、 dhttpd、 GoAhead WebServer、そしてSquidにて確認されているが、IIS6.0、 IIS7.0、およびlighttpdでは確認されていないとのこと。
SANSでは詳細のレポートが挙がっており、TimeOutディレクティブでタイムアウト値の設定を変えることでこの攻撃を軽減することが可能とのことで、今のところ対策はこれくらいしかないそうだ。
ローカルでアタックしてみました (スコア:4, 参考になる)
けっこう強力ですね。
デフォルトのconfのapache2.2.11にslowlorisでDDoSをかけてみましたが、ものの数秒でプロセスがパンクしました。
servser-statusをみると
RRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRR
("R" Reading Request)
で埋め尽くされて、アタックを中断しても
_______________________________________________________
("_" Waiting for Connection)
と待ちうけ中になってしまうので、apacheを再起動するか、タイムアウトするまで気長に待つかしないと正常な状態に戻らないみたいです。
KeepAliveTimeout 5 にしてみましたが、ほとんど効果はありませんでした。
ためしに、mod_evasiveでブロックを試みてみましたが、こちらもまったくスルーされてしまいました。
Re:ローカルでアタックしてみました (スコア:3, すばらしい洞察)
> KeepAliveTimeout 5 にしてみましたが、ほとんど効果はありませんでした。
KeepAliveTimeoutではなくてTimeoutディレクティブなんでは？
Your 金銭的 potential. Our passion - Micro$oft
Tsukitomo（月友）
Re:ローカルでアタックしてみました (スコア:1, 参考になる)
(適当に試してみただけですが、) Apache 単体は即無応答になりましたが、
リバースプロキシとして Pound を間に挟むと快適に動作するようでした。
現在運用中のサイトは Pound 使ってるので、なんとかなる予感。よかったよかった。
Re: (スコア:0)
するとapacheでならmod_limitipconとかでIPアドレスごとの接続数を絞るしかない？
DDoSされたらだめか。
現在、実行中 (スコア:0)
Re: (スコア:0)
全くの素人なんですが、プロセスの最大数を制限するってのはダメなんですか?
MaxSpareServers とかで。
Re: (スコア:0)
[error] server reached MaxClients setting, consider raising the MaxClients setting
接続数が多くなってきたらLRUっぽく接続の長いものを切ってしまうようにすべきかな、という気がします。
楯と矛 (スコア:4, おもしろおかしい)
そのDoSツールの配布してるサイトはヘッダ見る限りApacheなのですが、そこにAttackするとどうなるでしょうね?
もう対策済み?
防御方法は？ (スコア: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はどうかというと、クライアントと一対一で対話するスレッドを使うスタイルをとっていないと思います。
おそらくメッセージ・ドリブンのような方式になっているのでしょう。
クライアントから何か受信した後にワーカースレッドに渡されるのであれば、ワーカースレッドはクライアントからの受信を待たないので、そこがボトルネックにならないのでしょう。
Timeoutを減らすには注意が必要 (スコア:2, 参考になる)
CGI処理に掛かる時間も含まれているので、5秒にしてしまったら、
検索などの負荷がかかるCGIがエラーで中断されてしまいます。
Re:Timeoutを減らすには注意が必要 (スコア:3, 参考になる)
http://httpd.apache.org/docs/2.2/ja/mod/core.html#timeout [apache.org]
将来には別々の設定をすることが可能にできるよう考慮中です。
Apache 1.2 以前はタイマーは 1200 がデフォルトでしたが、 300 に下げられました。
300 でもほとんどの場合は十分すぎる値です。
コード中の変な場所にまだパケットを送る際にタイマをリセットしない 場所があるかもしれないので、デフォルトをより小さい値にはしていません。
Apache砦の攻防 (スコア:2, おもしろおかしい)
ちょっと細かいところがいい加減だが、こんなものか。と。
ここから：
ttp://movie.goo.ne.jp/movies/PMVWKPD412/story.html
TimeOut ディレクティブ (スコア:1, すばらしい洞察)
教えてエライ人！
Re:TimeOut ディレクティブ (スコア:3, 参考になる)
短くするようですよ。
SANSの詳細レポートに詳しく書いてあります。
通常の運用で影響が出たりしないのか等、
きっちりテストして慎重に設定しろと書いてありました。
参考値として5秒と言うのが提示されてましたが・・・
とりあえず、本運用前に自分で最適だと思う値を試せってことなんでしょうね。
#何ら根本的な解決にならないあたりが何ともいえない。
おぱんつ！！
Re:TimeOut ディレクティブ (スコア:2, 参考になる)
リンク先斜め読みした感じでは、300秒を5秒にしているようです。
＃まぁパッチ待ちかな…
Re:TimeOut ディレクティブ (スコア:2, 参考になる)
なので，コネクション数を食いつぶされる前にtimeOutになるよう，短めにすれば？ってことだと思う．
リンク先では5秒に設定しているみたいだけど，それだと2MB/分のトラフィックが必要になるとのことです．
Re: (スコア:0)
> 偽のヘッダを送ることで接続をオープンにし続け、Apacheのプロセスを一杯にさせるものだという。
からタイムアウトを大きくすればいいのか小さくすればいいのか論理的に導けないなら今すぐ管理者止めたほうがいいよ、マジな話。
Re: (スコア:0)
>論理的に導けないなら
「接続をし続け」から持続性が想像できれば、「TimeOut」って英語の意味から直感でも推測可能だね。
本当にそんな事が解らなかったのだろうか、そんな答えが欲しかったのだろうか。
おそらく、「（今の設定値は3000なんですがこれより）高くしたらいいのか低くしたら良いのか」
という風に聞いていたら、本来欲しかった答えが得られたかもしれない。
あるいは、「（今の設定値は3000なんですが）環境による最適値ってどう出せば良いでしょうか」
という方向なら、もうちょっと幅の広い答えが期待できるかもしれない。
デカルト曰く「最も重要なのは、正しい答えを見つけることではなく正しい質問を見つけることである」
Re: (スコア:0)
＞風に聞いていたら、本来欲しかった答えが得られたかもしれない。
同じだよぉ
不完全なヘッダーで処理を待たせておいて不正な情報を送りつけてパンクさせるって部分で
早めに破棄するようにしないと駄目だと、読んだ流れで普通に理解するだろ
素人ならまだしも、嘘でも管理してんだろ
解らにゃあかんって（苦笑）
新人プログラマのような事を言う奴に
サーバーの管理なんてして欲しくないね迷惑だよ
Re: (スコア:0, フレームのもと)
遅い回線を仕方なく使っている人もいます。
3600秒くらいにしておくのが礼儀でしょう。
Re: (スコア:0)
Re:TimeOut ディレクティブ (スコア:1)
対処しておかなかったんだ」と言われるんだよ。
Re: (スコア:0)
まあ、運を天にまかせるしかないってのはあるよね。
でも、落とし穴に嵌まったらそれまでだよ。
Re: (スコア:0)
今回はたまたま Apache 系列で発見されたけど、IIS で発見されたときはどうするの？
IIS ならば即座にパッチが提供されるという保証はどこにも無いよ。そのときには Apache に乗り換えるのを薦めるんだろうか。
実運用を考えるならば、Web サーバのみならず WAF(Web Application Firewall) で対応することも考えられるね。構成の一部分（例えばWebサーバだけ）を見て判断するのは早計でしょ。
Re:とりあえず泥縄で (スコア:1, 興味深い)
IISなら、IISを選んだことを批判されることはあっても、
自分でソースを読んでパッチを当てられないことを批判されることはない。
なお今のIISは、使い方さえ間違わなければ、Apacheよりも問題は少ないと思う。
Re: (スコア:0)
> なお今のIISは、使い方さえ間違わなければ、Apacheよりも問題は少ないと思う。
先刻も0dayの攻撃があったばかりだと思いますが。
Apacheなら即座にパッチが提供される保証があるのか？ (スコア:1)
自分ですべて開発しているか，特別な保守契約を結んでいるのでない限り，
どんなソフトウェアで問題が出た時にも修正版が即座に提供される保証なんてありません．
高トラフィックの環境ではおそらくリバースプロキシやロードバランサーを
導入しているでしょうから，おっしゃる通りウェブサーバの前段で対処
することもできるでしょうね．
屍体メモ [windy.cx]
スローロリスって (スコア:0)
サルの仲間なんですね。リスかと思ってました。
Re: (スコア:0)