Archive for the ‘Perl’ Category
TortoisesvnでcommitしたらWWWのDocumentRootに自動で反映させる方法(+ポートフォワーディング)
掲題のことを実現するために、まずwebdav経由の方法を考えたのですが、自宅サーバーはcgiはsuexec、phpはsuphpにより実行権限がディレクトリのオーナー(ユーザ)権限で実行されるため、webdavは現実的ではないと判断。（webdav経由だとcommit等がapacheユーザで実行されてしまうため、権限の問題が出てしまうので・・・）
次に、ssh経由の方法を考えたのですが、これも難点があって現実的ではないと判断。
何故かというと、自宅サーバーは外部から接続する場合、ゴニョゴニョして接続元のIPを許可した後、秘密鍵を使ってログインできるようになっています。これだけならいいのですが、許可したIPは一定時間経過すると自動的に無効になるようにしてあるため、commit等を行う度に毎回ゴニョゴニョしてIPを許可して・・・なんて面倒なことをやっていられないわけです。
で、最終的に、sshでポートフォワーディングさせる方法に行き着いたわけです。
■サーバー側の準備
1.svn管理+WWW公開用のアカウントを作成(以下svnuser)
2.svnuserでパスワード無しの公開鍵と秘密鍵を作成
3.公開鍵をリネーム
4.秘密鍵(id_rsa)をTortoisesvnを使うクライアントPCに持ってくる
5.svn管理用ディレクトリを作成
6.svnリポジトリを作成
7.WWWのドキュメントルートが自動更新されるようpost-commitを設置
8.自動更新の対象となるWWWディレクトリを作成
9.自動更新対象のディレクトリをチェックアウト
■クライアント側の準備
1.Puttyの公式から「putty.exe」「pageant.exe」「puttygen.exe」をダウンロードしてTortoisesvnのbinフォルダに保存
2.TortoiseSVNの設定メニューからネットワークの設定メニューを出して、SSHクライアントをTortoisePlink.exe(若しくはPuttyの公式からダウンロードしたplink.exe)を選択しておく
3.puttygen.exeを起動して「Load」をクリックしサーバーで作成した秘密鍵(id_rsa)を読み込む(Putty用にコンバートするか？聞かれるのでYesを選択)
4.3が完了したら「save private key」をクリックして適当な名前で保存
5.putty.exeを起動して下記を設定
6.Sessionの項目に戻り「Save」をクリックして保存
7.putty.exeで続いて下記を設定
8.Sessionの項目に戻り「Save」をクリックして保存
9.pageant.exeを起動して「Saved Sessions」から「svnssh」>「svntunnel」の順に接続する
これでTortoisesvnでcommitすると「/home/svnuser/public_html/hoge」も自動で更新されるようになるし、毎回パスワードを聞かれることもありません。
これで開発が楽になりました( ´ー`)
See Also
Subversionへポートフォワード+puttyで自動ログイン
【Subversion】mod_dav_svn(apache)経由でCommitした時に自動的にupdateを行う
APNICのdelegated-apnic-latestが無くなったと思ったら復活してた件
今朝方、Postfixのスパムメール対策で使っているCIDRのリストが12月11日を最後に更新されていないことに気が付きました。
なんでだろー？？？と思いcronで1日1回自動取得するスクリプトを手動で動かしてみても更新されず・・・
結局のところhttp://ftp.apnic.net/stats/apnic/delegated-apnic-latestがNot Foundになっていたのが原因だったようです。
で、いろいろ調べてみたらどうやらdelegated-apnic-latestの大元？？？ならFTPでアクセスできるということで、cronのスクリプトをすべてFTP経由で取得するように変更して無事に解決しました( ´ー`)
しかしhtaccessで国内ホストのみアクセス可能にするスクリプトの方はFTPプロトコルに対応していないのでどうしたものか・・・
と思っていたいのですが、ついさっきhttp://ftp.apnic.net/stats/apnic/delegated-apnic-latestにアクセスしてみたら復活してました！！
よかったよかった( ´ー`)
milter manager
これ読んでいてふと思いついたというかやってみようかなと思ったこと。
DNSBLの判定がNGだった場合にグレイリスティングで救済するようにreceivegreyも改良すればもうちょっといい感じになるかもしれない！
まぁ～時間があればやってみようと思います( ´ー`)
ホスト名がドットのみ
レンタル掲示板サービスには毎日ものすごい数のスパム投稿があるわけですが、そのスパム投稿の中に前々から気になっていることがあったのです。
ホスト名がドット（.）のみ
そんなの有り？
ドットで正引きしても当然ながらIPを引ける訳もないので、掲示板スクリプトの中にトラップを仕込んでIPを割り出してみました。
IPアドレス：92.48.122.3
逆引き結果
> nslookup 92.48.122.3
whoisの結果
> whois 92.48.122.3
国コードRSってどこだ？？？
調べてみたらどうやらセルビアらしい( ´ー`)
排除率99.97%のスパムメール対策 for postfix
排除率99.97%のスパムメール対策 for postfixをアップしました。
この記事書くのに今日丸1日費やしてしまった・・・
疲れた・・・orz
Postfixのスパムメール対策第3段の途中経過
ウチに来るスパムメールは相変わらず減り続けている。で書いたスパム対策の途中経過を報告します。
■postfixの設定は以下のようになっています（細かい説明は後日）
■統計（2008/06/22現在）
■REJECTの各項目
1はreject_unlisted_recipientで拒否した数
2はreject_unverified_senderで拒否した数
3はreject_non_fqdn_senderで拒否した数
4はreject_unauth_destinationで拒否した数
5はcheck_policy_serviceで拒否した数
6はsleepで諦めた数
7はブラックリストでピンポイントで拒否した数
8はprocmail側（dnsbl、urldb、ベイジアンスパムフィルタ）でspam判定された数
■OKは配送されたすべてのメール数
■TRUE JUDGEはOKの中で配送されたスパムの数
■FALSE JUDGEは拒否した非スパムの数
■REJECT RATE（postfix）はpostfixのみの拒否率
■REJECT RATE（ALL）はpostfix、procmailをあわせた拒否率
■1番下のREJECT RATEは設定毎の拒否率
というわけで現在の拒否率はpostfixのみで99.44％、procmailをあわせると99.96％となっています。
reject_non_fqdn_senderとsleepの出番がまったくありません・・・
（唯一6月9日にsleepで6というのがありますが、これは一時的にcheck_policy_serviceの前にsleepを置いてみた結果で、現在はcheck_policy_serviceの後に戻しています。）
見てのとおりreject_unlisted_recipient（User Unknown）だけで40％を拒否しています。
これが最近多いBackscatterというヤツです。
まだ途中ですが概ね合格点といったところでしょうか。
1年前とは比べ物にならない程スパムが減っているのがなにより。
Backscatter対策を考えてみた結果導入は諦めたのです。
あれからいろいろ考えてみた結果問題が2つ見つかったのです。
問題その壱
sendmail経由で送信されたメールはポリシーサービスに渡せないので送信履歴（キャッシュ）が残せない
問題其の弐
ウチのサーバー外からウチのドメインを使って送信した場合も送信履歴（キャッシュ）が残せない
つまり上記のメールが宛先不明でバウンスしてウチのサーバーに戻ってきた場合、送信履歴（キャッシュ）が無いので受け取りを拒否してしまうということ。
ということで導入はヤメっ！
まぁ〜reject_unlisted_recipientを入れてるのでほとんどのBackscatterは550で拒否してるからいいんですけどね・・・
たまぁ〜に実在するアドレスに配送されてくることがあるのでいろいろ考えてみたのですが、導入するメリットよりもデメリットの方が大きいので・・・┐(´д｀)┌
ウチに来るスパムメールは相変わらず減り続けている。
なんでしょうね？
ここ2、3ヶ月は平均200/日程度しか来ていません。
まぁ〜いいことなんですが、せっかく新サーバー機にして新しいスパム対策を施したというのに、なんか張り合いがなくなってしまってちょっとつまらない・・・┐(´д｀)┌
perlで改行せずにカウントダウンさせる
つい最近知ったのですが、UNIXではCR（\r）は行頭に戻るという意味だったのね( ´ー`)
↑をコンソール上で実行すると改行しないでカウントダウンしてくれます。
check_policy_serviceで自作のスクリプトへ渡すことに。
先週の土曜日あたりから親知らずがコンニチハしてきて若干痛いです(´；ω；｀)
さて先日のsmtpguardですが、元々はqmail用だったみたいですね・・・
ubuntuのリポジトリにはpostfix-smtpguardっていうのがありますが。
で、肝心の会社のフィルタリングサーバーの件ですが、結局check_policy_serviceを通して自分で書いたスクリプトでフィルタリングすることにしました。
先日書いたように、本来はGateWay的なポジションにあるサービスなのでスパムをゴリゴリ弾くわけにもいかないので以下のような運用ポリシーにしました。
1．逆引き不可＆逆引きしたホスト名が動的IPっぽいとこからきたものであった場合にcheck_policy_serviceでスクリプトに渡す。
2．スクリプトはエンベロープのFROMとTOのFQDNを組み合わせたキーにして値にリクエスト時間を記録する（同一キーの記録数はコンフィグで指定）。
3．スクリプトは2のキーからのリクエストが一定時間内（この時間もコンフィグで指定）にコンフィグで指定した回数を超えた場合は450で要求を拒否する。
4．スクリプトはリクエストがある毎にコンフィグで指定した時間を越えた2のキーは削除していく。
5．チェック対象のFROM、TOのFQDNはコンフィグで定義しておいてこれに該当しないものはスルーする。
といった感じ。
上記のスクリプトはperlで作成してデータの記録にはDB_File（BTREE）を使用。
正確には4→3→2の順番で2は3の条件を満たしていない場合のみ実行されます。
このスクリプトはすでに作成済みで後はpostfixに組み込んでテストするだけです。
ちなみにコンフィグは以下のようなフォーマットに
[FROM FQDN][TAB|SPACE][TO FQDN][TAB|SPACE][LIMIT TIME][TAB|SPACE][LIMIT COUNT]
example.com example.jp 5 10
上記の場合example.comからexample.jpへの送信は5分間に10通まで要求を受け付けるという設定。
前回はお客さんのメールサーバーからリレーされてくるだけだと思っていたのですが、このサービスのサーバー管理者から詳細を聞いてみたところお客さんのメールサーバー（お客さんのエンドユーザーが外部へ送信する場合）だけでなく外部（お客さんのエンドユーザー宛）からも送信されてくるみたいで、さらに外部からのスパムが今回の悩みのタネだったというオチ。
そこで、上記スクリプトで外部からのFROM（スパマーがよく使うフリーのメアド）とTO（お客さんとこ）のFQDNをキーにして短時間に大量にスパムが送られてきてもコンフィグで指定した一定時間の間に一定数に達した時点で450で弾いて配送数を制御してしまおうと思ったのです。
こうしておけば正常なメールが弾かれてしまっても再送されてきたときに許容数を超えていなければちゃんと要求を通すことができるというのが今回の目玉。
最初はコンフィグでのチューニングがとても大変かもしれませんが、それはこのサービスのサーバー管理者が担当するのでキニシナイ！
