土曜日, 7月 31, 2010

rejhost.plの改良を反映

 7月19日「ツールをいくつか」で紹介したツールのうち、拒否されたホストをメールログから抽出するrejhost.plは、メールログをcatコマンドとパイプでSTDIN(標準入力)に流し込むことを前提とした作りだった。7月23日に、rejhost.plがメールログファイルを直接入力するようにする改良を紹介した。絶対にこの方が便利なので、この改良を7月19日の記事に反映した。7月23日の記事は削除した。

月曜日, 7月 19, 2010

ツールをいくつか

 前回、ルール0以外の一般規則をやめることによって偽陽性判定を減らし、スパムアクセスの前科があるドメインのエンドユーザー回線と推定されるホストをブラックリストで阻止する案を述べた。この方法をとる準備のために、現在S25Rやuser unknownなどでブロックされているホストやドメイン名を抽出したりFQDNでソーティングしたりするための補助ツールをいくつか作った。Perl記述で、シェルコマンドのパイプと組み合わせることを前提に機能を単純化している。よろしかったらお使いください。

1. rejhost.pl (Extract rejected hosts)
機能 引数で指定されたPostfixのログファイルから、拒否されたホストのFQDNとIPアドレスを抽出する。引数を省略したら、/var/logディレクトリの下の、過去と最新の全メールログファイルを入力する。ディレクトリを省略したファイル名を指定したら(「/」がないとき)、デフォルトのディレクトリを/var/logとする。

出力例
166-71-95-178.pool.ukrtel.net[178.95.71.166]

使用例
rejhost.pl # /var/logの下のmaillog.4~maillog.1とmaillogから入力
rejhost.pl maillog.1 maillog # /var/logの下のmaillog.1とmaillogから入力
rejhost.pl ~/maillog.save # ~/maillog.saveから入力

プログラムコード
#!/usr/local/bin/perl
$dir = "/var/log";
if (@ARGV == ()) {
    @ARGV = ("maillog.4", "maillog.3", "maillog.2", "maillog.1", "maillog");
}
foreach $file (@ARGV) {
    unless ($file =~ /\//) {
        $file = $dir . "/" . $file;
    }
}
while(<>) {
    if (/reject:.* from ([^]]+\])/) {
        print "$1\n";
    }
}

 デフォルトのディレクトリとデフォルトのメールログファイルを変更したい場合は、適当に手直ししてください。Perlプログラミングの経験のない人でも直し方はおわかりになると思う。

2. revfqdn.pl (Reverse FQDNs)
機能 sortコマンドを使ってFQDNを上位ドメインの文字コード順にソーティングするために、FQDNのラベルを逆順に並べる。結果をもう一度これに通すと元のFQDNに戻る。

変換例
166-71-95-178.pool.ukrtel.net[178.95.71.166] → net.ukrtel.pool.166-71-95-178[178.95.71.166]

使用例
(拒否されたホストを上位ドメインの文字コード順にソーティングし、重複を削除する。――同じサイトドメイン内のホストは連続して並ぶことになる。)
rejhost.pl | revfqdn.pl | sort -f | uniq | revfqdn.pl

プログラムコード
#!/usr/local/bin/perl
while (<STDIN>) {
    chop;
    $_ =~ /^([a-z0-9._-]+)(.*)$/i;
    @labels = split(/\./, $1);
    @labels = reverse(@labels);
    print join(".", @labels), $2, "\n";
}

3. sitedom.pl (Extract site domain names)
機能 FQDNを入力してサイトドメイン名を抽出する。トップレベルドメインが英字2文字(国ドメイン)で、第2レベルがcom、net、org、gov、edu、または英字2文字ならば第2レベルを属性ラベルと推定し(これは確かではないが)、第3レベルをサイトドメインとみなして、上位3階層を抽出する。それ以外の場合は上位2階層を抽出する。2階層以上でない名前(unknownを含む)は出力されない。

変換例
189-68-193-53.dsl.telesp.net.br[189.68.193.53] → telesp.net.br
vc-41-16-75-82.umts.vodacom.co.za[41.16.75.82] → vodacom.co.za
166-71-95-178.pool.ukrtel.net[178.95.71.166] → ukrtel.net
bl17-17-97.dsl.telepac.pt[188.82.17.97] → telepac.pt

使用例
(拒否されたホストのサイトドメインの数を数える。)
rejhost.pl | sitedom.pl | sort | uniq | wc

プログラムコード
#!/usr/local/bin/perl
while (<STDIN>) {
    $_ =~ /^(([a-z0-9_-]+\.)+[a-z0-9_-]+)/i;
    if ($1 =~ /(^|\.)([a-z0-9_-]+\.(((com|net|org|gov|edu|[a-z]{2})\.)?[a-z]{2}|[a-z0-9_-]+))$/i) {
        print "$2\n";
    }
}

木曜日, 7月 08, 2010

一般規則をやめるというのはどう?

 6月27日「常連さんからのスパムが減った」で、論文中のブラックリスト例に掲載したドメインからのスパムアクセスが非常に少なくなったことを述べた。また、6月6日から7月8日までの約1ヶ月のログから抽出した不正メール送信元ホストは2243個で、2006年11月には7245個だったのに比べて減っている。これらのことから、OP25Bが世界で普及しつつあることが推測される。国内では、ご存じのとおりOP25Bが普及したので、jpドメインからの不正メールアクセスは、皆無ではないもののまれにしか来ないようになっている。
 このような状況になったからには、ルール0以外の一般規則をやめて、エンドユーザー回線から不正メールを送って来るドメインのブラックリストだけでブロックする方法も運用可能ではないか。そうすれば、IPアドレス1個割り当てのメールサーバや、多数のサーバを持つ事業者の連番入りホスト名など、一般規則で偽陽性判定されるホストは、(ドメインブラックリストにない限り)逆引きできさえすれば偽陽性判定されなくなる。
 そう考えて、2243個の不正メール送信元ホストのうち、unknownのホストと、サーバと思われるホストを除いた616個に基づいて、何件のドメインブラックリストが必要になるかを調べてみた。その結果、232件になった。もっと観測すればこれ以外のドメインが発見されるかもしれないが、いつまでも増え続けることはないだろうと思う。公開ホワイトリストの登録数が現在1297件になっていることを思えば、200~300件程度のドメインブラックリストのメンテナンスは大した手間ではないだろう。
 一般規則を廃止すれば、ホワイトリストに登録するのは、逆引きできないホストだけで済むようになる。現在、公開ホワイトリストの中で逆引きできないホストの登録は726件。つまり、ホワイトリストは半分強の大きさに減ることになる。そして、逆引きできさえすれば(ドメインブラックリストにない限り)遅延なく受信するので、逆引き名がS25Rに引っかかっていたホストの持ち主が不満を持つこともなくなる。
 一般規則をやめるとしても、そのノウハウは、不正メールを送って来るドメインの中のエンドユーザー回線と思われるホストだけを選択的に蹴るようにするために役立つ。いくつか例を挙げる。

# 114-33-77-76.HINET-IP.hinet.net
/^[0-9].*\.hinet\.net$/ 450 S25R check, be patient

# host125-94-static.14-79-b.business.telecomitalia.it
/^[^.]*[0-9]-[0-9].*\.telecomitalia\.it$/ 450 S25R check, be patient

# S010600112f492db3.cg.shawcable.net
/^[^.]*[0-9]{5}.*\.shawcable\.net$/ 450 S25R check, be patient

 もっとも、一般規則をやめる設定方法を提案したとしても、乗り換えてくれる人は少ないかもしれない。一般規則は、OP25Bがほとんど導入されていなかった時期から、スパマーとのいたちごっこをいきなり終わらせるほどの効果を持ち、その後大幅な見直しが必要なかった。S25R方式を導入した人たちの間では、この拒否条件がスタンダードになっている。偽陽性判定を起こすとはいえ、公開ホワイトリストが協力者のおかげで充実したため、国内サイトに関する限り、偽陽性判定が起こる頻度は少なくなった。だから、あえて設定を変更する動機付けに欠ける。ただ、これからS25R方式を導入するサイトや外国のサイトでは、一般規則を使わない設定方法を採用する人がいるかもしれない。

# よろしかったらご意見ください。