2008.05.21

FreeBSD 7.0とMysql・・・(Database)

サーバを2台動かしているが、最近はただ動かしているだけで、弄り回す興味をなくしていた。ところが、ディスクが壊れて、1台のサーバがあえなくダウン。
スペアーのサーバを立ち上げるべくRELEASE-6.2のCDを入れて立ち上げ、便利なツール類をftp接続してpackageで入れようとするが、packageがないとのメッセージ。
別途FreeBSDのftpサイトにアクセスして調べたら、FreeBSDは6.3に加えて7.0がリリースされていた。最初6.3を入れたのだが、7.0の性能改善がすばらしいと言う記事があり、自信作のようなので7.0-RELEASEを入れた。
isoイメージのdisc1のみダウンロードしてCDRを作成して基本のみ入れた後に、ftpでports、packageなどを入れて、環境を整えた。方法は6.xと何も変わらない。
mysqlもportsからmysql51-serverとmysql51-clientを入れた。

# cd /usr/ports/databases/mysql51-server
# make WITH_CHARSET=ujis WITH_XCHARSET=all install clean
# cd ../mysql51-client
# make WITH_CHARSET=ujis WITH_XCHARSET=all install clean

ここで、mysql51-clientを入れたとき、最後にmysql51-clientは既にあるとのメッセージが出てエラーになる。
ここで、make deinstallしてやり直すのが重要らしい。

# make deinstall
# make WITH_CHARSET=ujis WITH_XCHARSET=all install clean

以前に、portsで入れて文字コードがujisにならず、sourceからコンパイルしたことがあったが、このdeinstallしてinstallし直すことをしなかったのが敗因のようだ(確かめたわけではないが)。
入れた以降の設定は以前と同じなのでそちらを参照願いたい。
php5もportsからで問題なし。


2008.01.22

Movabletypeの3.25から3.35へのUpdate・・・(Movabletype)

MovabletypeはMT4が出て賑やかだが、大幅なUpdateで従来細工していた内容を入れ込むのは大変だし、デザインなども用意されているのを選んで使う場合は便利であるが、自分でデザインするのはかえって不便にも感じられた。もちろん慣れの問題であろうが。
3.25に加えて、修正したのはMT/tmpl/cms/upload.tmplで、アップロードしたときに格納するデフォルトのディレクトリーを入れたことぐらいである。

<input name="extra_path" id="extra_path" value="archives"/>

value=”archives”を追加した。


2007.02.10

コメントスパム攻撃・・・(Movabletype)

攻撃、そう正に攻撃です。

昨年暮れに、HDDがおかしくなり、大急ぎで新しいHDDでサーバを立て直し、やれやれと安心していたら、年が明けてしばらくしてから、どうも調子が悪い。
日に2?3回、外からWebページにアクセスしても無応答で、サーバがダウンしたかと思っていると1時間ぐらいで回復することが繰り返されていた。 最初のうちは、外からアクセスするばあいのproxy serverがbusyかなにかだろうと思っていたが、どうもそうでは無いらしいと気づいた。 が、しばらくすると回復するので忙しさにもかまけて放っておいたが、終に我慢の限界に達して、本格的に調べる決心をして待ち構えていた。

そして、それは起こった。 HDDのアクセスランプは点きっぱなしでなにやら激しくアクセスしている音が聞こえる。
早速、ログインしてtopでプロセスを見ようとしたが、ログインも出来ない。 pingには応答する。
以前にDOS攻撃やられたこともあり、とにかく、何かの攻撃らしいとみて、LANケーブルを抜いて、Localでログインしようとするが、一向に回復しない。 30分ぐらい経過して何とかログインできてtopコマンドを打って驚いた。
wwwが起動するperlプロセスのオンパレードで、まだキューに350ほど溜まっている。
もちろん、メモリーは全部食いつぶされて、HDDのswapを使って必死に実行しようとしているのだ。

1. 対策

ここで、ブログに対するコメントスパムの攻撃だろうと気づいたが、どう対策するか考える必要に迫られた。
MTに対するコメントスパムに対する対策はネットで調べると、沢山引っかかり、日本語文字の含まれていないコメントはリジェクトするとか、コメントの投稿formにhidden属性でキーワードを仕込んでおき、それをチェックすることで、ちゃんと投稿欄に書き込んだかをみるなどの方法が書かれている。

これらは有効な方法で過去には見事にスパムを撃退することも出来たが、今回はこれらは役に立たない。
何故なら、以前に取った対策は有効に機能していて、まったくコメントの投稿を防いでいるのだが、あまりのも激しい攻撃で、コメントの妥当性をチェックするに要する時間より短い間隔での攻撃だからだ。
ログを見ると1秒間に30回ぐらいの攻撃が延々と続く。

最初に思いつくのはコメント処理のcgiのファイル名を変えることであるが、ネットで調べると1週間ぐらいしか持たないらしい。 たしかにブログページを解析すれば、直ぐにcgiの新しいファイル名は知れるのだから、そうかも知れない。 1週間に1回の割合でファイル名を変え、mt-config.cgiのScript名を、それに直してすべてのブログを再構築するなどやっていられないですよね。

ここで、見つけたのが、
Junk Slowdownというページです。
mt-comment.cgiの名前を変えると同時にmt-comment.cgiにアクセスしてきたら.htaccessのredirect機能で別のところに飛ばし、受け付けない旨のメッセージを返し、また30秒のDelayを入れることだ。

具体的に方法は、
(1) Movabletypeがインストールされているディレクトリーの.htaccessに次の2行を追加

RewriteEngine on
RewriteRule ^(mt-comments|mt-tb|mt-comcom|mt-tbtb)\.cgi$ /xyz/sand-trap.php [LAST]

/xyz/sand-trap.phpは、飛ばし先である。
(2) comments.cgiとmt-tb.cgiの名前を変更
ここでは、comments.cgi → mt-koment.cgi, mt-tb.cgi → mt-back.cgi として例示する。
mt-config.cgiのコメントとトラックバックのScriptを変更。 もし、コメントとトラックバックに関するScript指定の記述がmt-config.cgiに無ければ、下記の2行を追加する。

CommentScript mt-koment.cgi
TrackbackScript mt-back.cgi

そして、全てのブログページを再構築
(3) sand-trap.phpを作って /xyz/ディレクトリーに入れる。 もちろん、phpの実行環境がない場合は、perlで記述してもよい。 下記はphpの例である。

<body>

<div style="font-size:200%;
            text-align:center;
            background:#822;
            color:white;
            border:2px solid red;
            padding:1ex;
            margin-bottom:1ex;
            ">
Sand Trap
</div>

<p style="border:2px solid red;
          padding:1ex;
          ">
You have been redirected to this script because
you have used an obsolete resource to which
no references exist on this website. This makes
you presumably a junker, and therefore your
session has been bogged down with this webpage.
</p>

<?php
ob_flush();
flush();
sleep(30);
?>

<p style="text-align:center;
          border:2px solid red;
          padding:1ex;
          margin-top:1ex;
          ">
If you are going to abuse me, I will abuse you right back.
</p>

</body>

適用したら、効果テキメン。 やっとサーバを安定稼動状態に保つことができた。
どうも、スパム対策は、妥当性のチェックの精度を上げることに血道をあげてもダメで、DOS攻撃ライクの集中攻撃に対する対策を考える必要の段階にきたようだ。
今回の方法も破られる時がくるのではと心配である。 次の対策もいまから策を練っておく必要がありそうだ。


2007.01.13

Movabletype関係のperlライブラリー・・・(Movabletype)

昨年末にFreeBSDでswap領域を拡張する方法を書いた。
しかし、やはりHDDがあやしく、結局HDDを交換する羽目になった。
そこで、Movabletypeを動かすために、いくつかのperlライブラリーを入れる必要があるが、筆者はmysqlを使っているので、このためにも更にいくつかのperlライブラリーが必要である。
以前にも断片的にかいたが、ここで再度まとめておく。
下記は入れたperlライブラリーである。

(1) p5-Class-DBI-mysql          (/usr/ports/databases)
(2) p5-DBI-DBD                    (/usr/ports/databases)
(3) p5-Image-Info                  (/usr/ports/graphics)
(4) p5-Image-Size                  (/usr/ports/graphics)
(5) p5-SOAP-Lite                  (/usr/ports/net)
(6) p5-Crypt-DSA                 (/usr/ports/security)
(7) p5-POE-Component-Server-XMLRPC     (/usr/ports/devel)

これらをmake install clean で次々に入れる。
p5-SOAP-Liteはnet関係のライブラリーがたくさん含まれているので、post2blogは、
これとImage-Info, Image-Sizeを入れると動作可能となる。
あと、StyleCacherが動かなくて、はまってしまったが、設定は2箇所必要なのです。
 ・メインメニューのページでシステムメニューのところのプラグインをクリックして
  styleCacherを選択して設定
 ・個別エントリーの設定でプラグインでStyleCacherを選択して設定両方に

Theme Root URL: http://uls.fam.cx/mt/mt-static/
Theme Root URL: /web/data/mt/mt-static/themes

とすると、うまく動作した。


2006.12.18

Swapスペース不足・・・(FreeBSD)

10日ほど前から、下記のログが大量に出て、Apacheが落ちる問題に悩まされていた。

swap_pager_getswapspace: failed
swap_pager_getswapspace: failed
swap_pager_getswapspace: failed
          ・
          ・

最初、ハードディスクが壊れかかっているのだろうと思い込んで、新しいHDDを買ってきたが、新しく立ち上げる間の代替機でも同じ現象が発生した。
どうも、mysqlを5.0.27に上げてからのようで、これは本当にスワップ領域が足りないのではと思い、スワップ領域を増やしたらビンゴー!!。 ぴったり安定した。
実は、古いPCで380MBほどのメモリで、色々なサービスを起動していてスワップ領域も512MBなので、mysqlを新しくして、ついに足りなくなったのだろう。
しかし、スワップ領域は最初にインストールするときに確保するが、後から増やすことなどできるのか。
どうすればよいのか? 色々と調べたら簡単に増やせることがわかった。
まず、/usrに

# dd if=/dev/zero of=/usr/SWAPFILE bs=1m count=2000

として、2GBの領域を/usrに確保。 少し時間がかかる。 そして、/etc/rc.confに次の1行を追加した。

swapfile="/usr/SWAPFILE"

これだけである。 マシーンを再起動どうなったか調べるために次のコマンドを打つ

# pstat -s
Device          1K-blocks     Used     Avail Capacity
/dev/ad0s1b        524288      120   524288      0%
/dev/md0           2048000      136  2048000     0%
Total                   2572288      256  2572032     0%

となって、最初に確保してあった512MBも加わり2.5GBのスワップ領域となった。
1週間悩み続けたのが、簡単に氷解した。


« Previous | Next »