12月 14
今朝方、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にアクセスしてみたら復活してました!!
よかったよかった( ´ー`)
3月 11
milter manager はじめに
これ読んでいてふと思いついたというかやってみようかなと思ったこと。
DNSBLの判定がNGだった場合にグレイリスティングで救済するようにreceivegreyも改良すればもうちょっといい感じになるかもしれない!
まぁ~時間があればやってみようと思います( ´ー`)
9月 14
レンタル掲示板サービスには毎日ものすごい数のスパム投稿があるわけですが、そのスパム投稿の中に前々から気になっていることがあったのです。
ホスト名がドット(.)のみ
そんなの有り?
ドットで正引きしても当然ながらIPを引ける訳もないので、掲示板スクリプトの中にトラップを仕込んでIPを割り出してみました。
IPアドレス:92.48.122.3
逆引き結果
> nslookup 92.48.122.3
Non-authoritative answer:
3.122.48.92.in-addr.arpa name = .
Authoritative answers can be found from:
122.48.92.in-addr.arpa nameserver = a.ns.as29550.net.
122.48.92.in-addr.arpa nameserver = b.ns.as29550.net.
whoisの結果
> whois 92.48.122.3
[whois.ripe.net]
% This is the RIPE Whois query server #3.
% The objects are in RPSL format.
%
% Rights restricted by copyright.
% See http://www.ripe.net/db/copyright.html
% Note: This output has been filtered.
% To receive output for a database update, use the “-B” flag.
% Information related to ‘92.48.122.0 – 92.48.122.31′
inetnum: 92.48.122.0 – 92.48.122.31
netname: PH-V3SERVERS-28069
descr: v3servers
country: RS
admin-c: SA4464-RIPE
tech-c: SA4464-RIPE
status: ASSIGNED PA
mnt-by: blueconnex-mnt
mnt-routes: blueconnex-mnt
source: RIPE # Filtered
remarks: ******************************************************
remarks: Please contact abuse@v3servers.net for any abuse issues
remarks: E-mail sent to other addresses may not be acted upon.
remarks: ******************************************************
person: Sogreev Anton
address: v3Servers.net
address: 12 Knez Mihailova
address: apt. 18
address: Belgrade
address: 11000
address: Serbia
phone: +381 (0)11 124-1264
nic-hdl: SA4464-RIPE
mnt-by: blueconnex-mnt
source: RIPE # Filtered
e-mail: mail@v3servers.net
e-mail: abuse@v3servers.net
% Information related to ‘92.48.64.0/18AS29550′
route: 92.48.64.0/18
descr: Blueconnex Networks Ltd
origin: AS29550
remarks: ***********************************
remarks: * *
remarks: * Abuse: abuse@blueconnex.net *
remarks: * *
remarks: * Peering: peering@blueconnex.net *
remarks: * *
remarks: ***********************************
mnt-by: blueconnex-mnt
source: RIPE # Filtered
国コードRSってどこだ???
調べてみたらどうやらセルビアらしい( ´ー`)
7月 20
排除率99.97%のスパムメール対策 for postfixをアップしました。
この記事書くのに今日丸1日費やしてしまった・・・
疲れた・・・orz
6月 22
ウチに来るスパムメールは相変わらず減り続けている。で書いたスパム対策の途中経過を報告します。
■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年前とは比べ物にならない程スパムが減っているのがなにより。
6月 05
Backscatter対策を考えてみた。
あれからいろいろ考えてみた結果問題が2つ見つかったのです。
問題その壱
sendmail経由で送信されたメールはポリシーサービスに渡せないので送信履歴(キャッシュ)が残せない
問題其の弐
ウチのサーバー外からウチのドメインを使って送信した場合も送信履歴(キャッシュ)が残せない
つまり上記のメールが宛先不明でバウンスしてウチのサーバーに戻ってきた場合、送信履歴(キャッシュ)が無いので受け取りを拒否してしまうということ。
ということで導入はヤメっ!
まぁ〜reject_unlisted_recipientを入れてるのでほとんどのBackscatterは550で拒否してるからいいんですけどね・・・
たまぁ〜に実在するアドレスに配送されてくることがあるのでいろいろ考えてみたのですが、導入するメリットよりもデメリットの方が大きいので・・・┐(´д`)┌
5月 24
なんでしょうね?
ここ2、3ヶ月は平均200/日程度しか来ていません。
まぁ〜いいことなんですが、せっかく新サーバー機にして新しいスパム対策を施したというのに、なんか張り合いがなくなってしまってちょっとつまらない・・・┐(´д`)┌
近々新しいスパム対策を公開する予定なのですが、その前に概要だけ説明すると、
1.逆引き不可or逆引きFQDNが動的IPっぽいときorドメインがcom/net/jp以外の場合のみCIDRテーブルにより国内or海外からのクライアントか判定します。
2.CIDRテーブルの結果が国内の場合はポリシーサービススクリプトへ渡します。(ポリシーサービススクリプトの検査結果がDUNNOの場合はsleep 35の配送遅延を実施します)
3.CIDRテーブルの結果が海外の場合はポリシーサービススクリプトへ渡します。(ポリシーサービススクリプトの検査結果がDUNNOの場合はsleep 125の配送遅延を実施します)
4.ポリシーサービススクリプトはクライアントIP、エンベロープのFROM及びTOをキーにして値にはリクエスト時間を記録
5.4のキーが無い場合はDEFER_IF_PERMITで拒否します。
6.4のキーがあった場合でもm分以上m分以内の間にN回以上のリクエストが無い場合はDEFER_IF_PERMITで拒否します。
という感じのことをしています。
まぁ〜単純にtaRgreyと同じ理屈???のものをオレ流に作成したものです( ´ー`)
ポリシーサービススクリプトはreceivegreyと名づけたスクリプトを作ったのです( ´ー`)
使い方はmaster.cfに
127.0.0.1:10027 inet n n n – 16 spawn
user=nobody argv=/usr/local/bin/receivegrey --DEBUG=0 --DBFILE=/tmp/receivegrey-jp.db --TYPE=1 --COUNT=1 --BEGIN=5 --END=120
127.0.0.1:10028 inet n n n – 16 spawn
user=nobody argv=/usr/local/bin/receivegrey --DEBUG=0 --DBFILE=/tmp/receivegrey-na.db --TYPE=1 --COUNT=2 --BEGIN=10 --END=120
ってな感じで呼び出します。
--DEBUGはmaillogに詳細のログを出力するか否か
--DBFILEはキャッシュを記録するファイルのパス
--TYPEは0の場合は許可したキーをm分以上m分以内の間なら何通でも許可する(1は1通許可したらキーを削除する)
--COUNTは1なら1度拒否してm分以上m分以内の間で一度リクエストがきたら許可する(2ならm分以上m分以内の間で二度目のリクエストから許可)
--BEGINはm分以上
--ENDはm分以内
とまぁ〜こんな感じです( ´ー`)
まだ運用して5日しか経っていないのでもう少し様子をみてから公開しようと思います。
4月 07
つい最近知ったのですが、UNIXではCR(\r)は行頭に戻るという意味だったのね( ´ー`)
#!/usr/bin/perl
$| = 1;
for (my $C = 1,my $D = 30; $C < = $D; $D--) {
print "Please wait for " . sprintf("%02d",$D) . " seconds more";
sleep 1;
print "\r";
}
exit;
↑をコンソール上で実行すると改行しないでカウントダウンしてくれます。
3月 04
先週の土曜日あたりから親知らずがコンニチハしてきて若干痛いです(´;ω;`)
さて先日の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で弾いて配送数を制御してしまおうと思ったのです。
こうしておけば正常なメールが弾かれてしまっても再送されてきたときに許容数を超えていなければちゃんと要求を通すことができるというのが今回の目玉。
最初はコンフィグでのチューニングがとても大変かもしれませんが、それはこのサービスのサーバー管理者が担当するのでキニシナイ!
2月 16
以前作成したサーバー監視スクリプトにバグが見つかったので修正しました。
Socketで接続後にレスポンスから取得した文字列が静的コンテンツと動的コンテンツの場合で違うことが判明したのです。
これは常識?( ゜Д゜ )
■静的コンテンツの場合
・HTTPヘッダー終了後にコンテンツのソース
■動的コンテンツ(CGIやPHP)の場合
・HTTPヘッダー終了後にコンテンツのサイズ?らしき数字(英数字の時もある)
・次行にコンテンツのソース
・最後に0
というようなレスポンスだったので、これに対応させるよう修正を加えました。
この機能は監視対象のサーバーのベータベース接続のチェックやロードアベレージのチェックなどに使うことを目的としています。(つまりスクリプトによる動的コンテンツということ)
このバグになぜ気が付いたのかというとload averageが22を突破したという出来事があったので、自宅サーバーにロードアベレージをチェックしてステータスを返すスクリプトを設置して、このスクリプトをサーバー監視スクリプトで監視しようと思ったのです。
以下がロードアベレージをチェックするスクリプト
#!/usr/bin/perl -w
use strict;
$ENV{‘LANG’} = ‘en’;
my $UPTIME = `uptime`;
$UPTIME =~ s/.*load average: ([0-9\.]+), [0-9\.]+, [0-9\.]+.*/$1/;
$UPTIME =~ s/\s+//g;
print “Content-type: text/plain\n\n”;
if ($UPTIME > 10) {
print “Load average is Unhealthy!($UPTIME)”;
} else {
print “Load average is Healthy”;
}
exit;
でサーバー監視スクリプトのHttpdChk.confは以下のように設定
www.example.jp/uptime.cgi hoge@example.jp Load average is Healthy
これで自宅サーバーのロードアベレージが10を超えると携帯にメールがくるようになりました。( ´ー`)