Archive for the ‘Perl’ Category
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で弾いて配送数を制御してしまおうと思ったのです。
こうしておけば正常なメールが弾かれてしまっても再送されてきたときに許容数を超えていなければちゃんと要求を通すことができるというのが今回の目玉。
最初はコンフィグでのチューニングがとても大変かもしれませんが、それはこのサービスのサーバー管理者が担当するのでキニシナイ！
サーバー監視スクリプトを修正しました。
以前作成したサーバー監視スクリプトにバグが見つかったので修正しました。
Socketで接続後にレスポンスから取得した文字列が静的コンテンツと動的コンテンツの場合で違うことが判明したのです。
これは常識？( ゜Д゜ )
■静的コンテンツの場合
・HTTPヘッダー終了後にコンテンツのソース
■動的コンテンツ（CGIやPHP）の場合
・HTTPヘッダー終了後にコンテンツのサイズ？らしき数字（英数字の時もある）
・次行にコンテンツのソース
・最後に0
というようなレスポンスだったので、これに対応させるよう修正を加えました。