_ でさぁ、 以前も書いたし、dnsops ML にも同じこと考えてる人いたけどさ(あれってそういう意味だよね？)、ヒントファイルの配布のしかたどうにかならんの？ ダメだよあんなのじゃ。以下、前回の繰り返しなので、べつに読まなくてよし。
_ ヒントファイル置き場は素の HTTP/FTP なんで、接続先をねじまげられて変なところに誘導させられても確認のしようがない。PGP の署名もあるけど、署名鍵がホンモノかどうか確認できないので意味ない(しかも前回更新のときと違う鍵が使われてる)。なんとびっくり、internic.net は DNSSEC による署名があるようだけど、上位に DS が登録されてなくて信頼の連鎖が切れてるから検証できない。HTTP/FTP を使わなくても、DNS で拾ってきた情報を DNSSEC で検証できればいんだろうけど、root-servers.net は署名されていないのでそれもできない(root-servers.net が DNSSEC に対応してしまうと、DNS 全体が net. の運用に依存してしまうことになるからだとかなんとか)。
_ つーことで、ヒントファイルが更新されたよー、といわれても、拾ってきたものが本物かどうか検証できないんだよ。万が一ニセモノを掴まされてしまったらそれを使ってるサイトには毒入れし放題なんだから、ちゃんと正当性を検証できるようにしなきゃいかんてば。こんなあたりまえのことができてないのに DNSSEC なんてちゃんちゃらおかしいよね。
_ chaos txt version.bind を聞くと CHAOS じゃなくて IN で応答しちゃうの？ へんなの。
_ dig だと
こんなメッセージが出てエラーになる。じゃあ、と ch じゃなくて in で聞くとちゃんと応答が返ってくる。dig じゃなくて drill だと ch で聞いて in で返ってきた結果を何事もなかったかのようにそのまま見せてくれちゃう。DNS のパケットをそのまま可視化するという意味では drill の挙動が間違ってるとはいえないし、クエリと違ってるものはおかしいとみなしてエラーにする dig も間違ってない。間違ってるのは PowerDNS の挙動。別にこんなの実害ないからどうでもいいけど。;; Question section mismatch: got version.bind/TXT/IN
_ Apache 2.3/2.4 のドキュメントを見てたら、 2.4 からの新モジュールとして mod_reqtimeoutなるものが。2.4 からという紹介なんだけど、実際にドキュメントを読んでみると 2.2.15 以降で使えることになってる。あれ、いつのまに。たしかに手元の 2.2 のホストにもあるわ。1年以上前なのにぜんぜん気がついてなかった。
_ 何をするモジュールかというと、クライアントからのリクエストに対してタイムアウトを設定できる、というただそれだけ。それだけなんだけど、これ、実はかなり重要な機能を提供してくれちゃってますよ。apache を動かしてる人なら、これが何を意味するかはとーぜんすぐに理解できるよね。2.4 からの新機能でありながら現行の 2.2 にも追加するだけの意義は十分ある。
_ ええと、調べてみたら slowlorisってちょうど2年前なんだな。apache およびその他いくつかの HTTPD 実装は、クライアントからのリクエストが完了するのをずーっと待ち続けるので、終了しない中途半端なリクエストを大量に送りつければ他からのリクエストを受けられなくなる、という DoS 攻撃を許す穴がある。穴なんだけど、apache の設計の根幹部分に問題があって修正が容易でないことから、この穴はいまだにふさがれていない。
_ 穴はふさげないけど、影響を緩和する方法として有効なのが TimeOut を小さくすること。slowloris は終了しないリクエストを送ってくるので、タイムアウトを小さくしてそういう接続をとっとと切断してしまえばいい。ただ、 TimeOut ディレクティブはいろんな場面で使われるタイムアウト値をごっちゃにしてひとつの値ですませていて、slowloris 対策のためだけに小さな値を設定するわけにはいかない。そこで mod_reqtimeout。TimeOut ディレクティブとは別に、リクエストにかかるタイムアウトを設定できる。
_ てなわけで、前置きは長くなったけど、mod_reqtimeout を設定した手元のサーバに slowloris で攻撃をしかけてみた。攻撃を開始してから RequestReadTimeout の時間が経過するまでの間は接続しづらくなったけど、まもなくタイムアウトで切断されてすんなりつながるようになった。根本的な解決策にはならないけど、mod_reqtimeout がない場合よりも影響をだいぶ小さくすることができる。かなーり安心度が上がるので、使える環境なら設定しておくとよさげ。
_ Linux の場合、デフォルトではタイムアウトのカウントが始まるのは TCP のコネクションが成立してからではなく HTTP の最初の1バイトを受けとってからで (*1)、よほど巨大なクッキーを食わされておらず、よほど MTU の小さな経路を通らなければリクエストヘッダはたいてい1パケットに収まる。よって正常なアクセスでは最初の1バイトの受信とリクエストヘッダ全体の受信は同時であり、ヘッダのタイムアウトはかなり小さな値にしても問題ないんじゃないかな、たぶん。POST だとボディのサイズが大きくなるのであんまり小さな値にするのはよろしくないけど。FreeBSD では GET であればこのモジュールなんかなくたってそもそも slowloris attack の影響を受けないんだけど、POST による攻撃を受けた場合を考えててきとーに設定しておくとよさげな感じ。
_ なお、 mod_antilorisなどの専用対策モジュールは、クライアントあたりの同時接続数を制限するものなので、攻撃側が大量の IP アドレスを確保できる場合(つまり botnet に組み込まれた場合)には対処のしようがない。逆に言えば、botnet が slowloris attack をするようなことがなければこれで十分対処可能ということでもあるが。そして今のところ botnet による slowloris attack という話は聞かない。……あー、将来的に large scale nat でたくさんのユーザがひとつの IP アドレスに相乗りするようになると、mod_antiloris だと誤爆してしまうかもしれんなぁ。
(*1): なぜなのかは AcceptFilter の説明を読むとわかる。