にしし らぼらとりー

悪質なBot対策とか、攻撃を試そうとする不正アクセス対策とかで、何らかのエラーメッセージを返すときには、単にメッセージを表示するだけではなくて、200以外のHTTPステータスコードも返す。これは単にエラーページがキャッシュされたりしないように、という理由だけではなくて、Webサーバのアクセスログにエラーの発生事実が残るからでもある。HTTPステータスコードはログに記録されるので。自前でエラー発生の履歴を残そうとすると無駄な処理が増えてしまうが、Webサーバのアクセスログならどうせ問答無用で記録されるので、それに頼るのが最も消費リソースが少なくて済む。ただ、何でもかんでも 403 Forbidden とかを返してしまうと、「どの対策に引っかかったアクセスなのか？」が判別できない。Webサーバのログに記録されるのは、本当にHTTPステータスコードの番号だけでしかないから。そこで、対策内容によって「400 Bad Request」とか「429 Too Many Requests」とか、使えそうなHTTPステータスコードを使い分ける。……のだが、それでも足りなさそうな場合に、もっと何か使えそうなHTTPステータスコードはないか……と探すことになる。そこでふと思い出したのが、エイプリルフールジョークから作られた「418 I'm a teapot」。これは無害そうなので、識別のために使っても問題なさそうな気がする。……と思ってMDNの418 I'm a teapotページを見てみたら、一部のウェブサイトでは、自動化されたクエリなど、処理したくないリクエストに対してこのレスポンスを使用しています。と書いてあってちょっと笑った。みんな、考えることは同じなのか。

以下の3記法を新設した。（全部、[設定]→[補助出力]で設定できる値を表示する機能。「状況に応じた見出し」の出力用途くらいにしか使っていなかった。）

• [[GALLERY:NAME]] :ギャラリーモードの名称を挿入
• [[PICTS:NAME]] :画像一覧モードの名称を挿入
• [[SITEMAP:NAME]] :サイトマップページモードの名称を挿入

要望を頂いて、そういえばその記法はなかったな、と気付いた。需要があるとは思っていなかった、というのもあるけども。広く需要があるのかどうかが分からないので、まあ検討リストに入れようかな、と一瞬思ったのだが、そもそも処理が極めて簡単だったので、何も考えずに実装した。

てがろぐ「画像の管理」画面から、画像ファイルのタイムスタンプを変更できる機能の実装ができた。この機能を使って画像ファイルのタイムスタンプを修正することによって、間接的に画像の並び順（＝画像一覧モードでの並び順や、新着投稿画像の並び順や、画像管理画面での並び順）を変更できる。

今日は、てがろぐの開発をずいぶん進んだ。ただ、あまり表には見えない部分の実装だけども。いろんなURLに対して短期間に絨毯爆撃してくるBotがサーバ負荷を高めてしまう問題に対処するには、やはりサーバ側の機能に頼るのでは不足なので、てがろぐ自体に『同一IPアドレスからxx秒間にxx回以上の頻度でアクセスがあったら一定時間ほど「429 Too Many Requests」エラーを返す』という負荷軽減機能を用意した。
負荷軽減策なので、極力何も処理しないうち（データファイルを読み込むよりも前なのはもちろん、設定ファイルすら読み込まないうち）にアクセス制限を施す必要があるので、tegalog.cgi と同じ位置に blackcheck.ini という設定ファイルを置いた場合にだけ実行されるようにした。（※管理画面から設定できるようにすると、「設定ファイルを読み込んだ後」のタイミングでしか実行できない問題があるので。）
このファイルに例えば、

• Duration=60
• LimitFreq=10

というような記述があれば、『同一IPアドレスから60秒間に10回を超えるアクセスがあったら、次の60秒間は「429 Too Many Requests」エラーだけを返す』というような制限になる。
あくまでも「様々なURLに対して絨毯爆撃してくるBot」（≒毎秒数件みたいな超人頻度でアクセスしてくるBot）への対策が目的なので、「何の表示条件も限定されていないページ」に対しては無制限に閲覧を許可するし、RSSの閲覧も無制限に許可する仕様になっている。もちろん、管理画面へのアクセスも制限の対象外である。それ以外の「サブコンテンツ」のURLに対してだけ、アクセス頻度をチェックして制限を掛ける。要るかどうか分からないが、一応はホワイトリスト的に任意のIPアドレスを制限から除外できる仕様も用意はした。
この機能でしばらく運用してみて、サーバ負荷の高まり(の防御具合)を確認してみるとする。

絨毯爆撃してくるBotによる負荷を軽減させるには、やはり「同一IPアドレスから30秒間に2回以上の頻度でアクセスがあったら一定時間ほど429を返す」みたいな処理が必要か……？

7時間経っても復旧しないとかある……？ うちのサイトが原因ではないよな……？ と若干心配になるのだが。

うーむ。5時間経っても復旧しないのか。まさか今日中には復旧できないとかそういうことはないよな……？

しかし、メインのドメインを運用しているサーバが落ちると、メールも使えなくなるので困るな……。今日は日曜日なので元々届くメールが少ないのが幸いだが。仕事の連絡はまず来ないし。

動作試験場（兼サポート場）が別サーバ（ここ）にあって良かった。とりあえず（気付かれるかどうかが分からない問題はあるが）アナウンスはできるので。

メインサイトで使っているサーバの障害回復に結構な時間が掛かっている……。2時間以上落ちている障害は、もしかして、さくらインターネット利用歴24年間の中でも最長なのではないか。てがろぐ新バージョンをリリースした翌日だが、今日TegUp等でバージョンアップしようとしている人々に情報が伝わっているかどうか。せっかくメインの .com とサブの .org で2サイトあるのだし、てがろぐの管理画面には動作試験場へのリンクも設けておく方が良いかもしれない。アナウンスの場として。

TegUpを置いている場合は、てがろぐ管理画面HOMEの「アップデートがあります」ボタンからTegUpに飛べる。現状では単に「TegUpにアクセスできるだけ」なので、TegUp上で1クリックが必要になる。それも省略できるようにして、てがろぐからTegUpへアクセスした場合には、ダイレクトにバージョンアップするようにしても良さそうな気もする。最新版の確認は、てがろぐ管理画面側で既にできているわけだし。