「TLECのuser_prefs」 松田陽一
SpamAssassinとは POSIX系OSで稼動するオープンソースのspamフィ ルタ perlのスクリプト heuristicなルールベースのフィルタ+ベイジア ンフィルタ+DNSBL+URIBL+Razor2他+SPF+DKIM etc... 個々のルールのスコアを加算して閾値と比較 metaルール(複数ルールの論理演算) http://d.hatena.ne.jp/keyword/spamassassin
SAの問題点 英語圏で開発されているので、日本語圏特有 の事情が考慮されていない →デフォルト設定では日本語spamに対してほ ぼ無力 副作用を引き起こすルールが混じっている →ボランティアベース故に玉石混合
「TLECのuser_prefs」とは 松田が自分で設定して使用している、SAの ユーザ定義ファイルをそのまま公開 ~/.spamassassin/user_prefs 日本語spamに特化したルール アジア諸国のISPのIPアドレス範囲をルール として設定 他のルールとのmetaルールを多用して、 false positive(偽陽性)を回避 中小企業のサーバ管理に多く採用されている模様 /etc/spamassassin/local.cf
「TLECのuser_prefs」の仕組み 殆どのspamは動的IPから直接受信者のMTAへ 送信される 日本国内の殆どのISPはOP25Bでこの形態の spamを排除しつつあるが、諸外国のISPは全く 無策 spamを受信したら送信元IPを調べて、ISPの IPアドレス範囲をルールに登録 8/17時点で193個
「TLECのuser_prefs」の利点 DNSBL未登録の動的IPから来る日本語spamを 検出できる DNSBLは後追い spamは同一ISPの動的IPを移動する傾向あり DNSBL,Razor2等のスコアを低く設定し、 metaルールでスコアを嵩上げしているので、 false positiveが比較的少ない ISP説明文を定型化しているので、grepすれ ばspam送信元ISPがすぐわかる 統計処理に便利
ISP説明文 ・ISPルール ISP名行頭はアルファベット大文字 ISP名はアルファベット大文字と数字と_(アンダースコア) ・ISP説明文(describe) 左大括弧[ 二文字の国名コード 右大括弧] ISPの説明文
ISP説明文の一例 header GLOBALSPEED_PH X-Spam-Relays-Untrusted =~ /^\[ ip=180\.94\.(?:\d|[12]\d|3[01])\.\d{1,3} / describe GLOBALSPEED_PH [PH]GLOBALSPEED-PH score GLOBALSPEED_PH 1.5 Content analysis details: (74.8 points, 15.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 5.5 BAYES_99 BODY: Bayesian spam probability is 99 to 100% [score: 1.0000] -0.1 CONTENT_TYPE_PRESENT exists:Content-Type 1.5 SHIFT_JIS2 Content-Type: text/plain; charset="SHIFT_JIS" 1.5 GLOBALSPEED_PH [PH]GLOBALSPEED-PH 1.0 FORGED_RCVD_IP Invalid IP number, over 255. 10 MSGID_NUMONLY Message-ID: YYYYMMDDHHMM 1.1 MSGID_SHORT Message-ID is unusually short
「TLECのuser_prefs」の欠点 常に変動するIPアドレスの付与状況に対応す るため、常時spamを監視し続ける必要がある IPアドレスの登録が大変 IPアドレス誤登録に起因するfalse positive に対して弱い Webメイルサービスを悪用したspamに弱い ex.Gmail HTML spam 松田個人しかメンテナンス作業をしていない
X-Spam-Relays-Untrusted SAの機能「pseudo header(仮想ヘッダ)」 SAのデバッグモード(-D)で可視化 MTA毎に書式が異なる「Received:」ヘッダを 正規化 直近の送信元IPアドレスが先頭エントリに来 る http://wiki.apache.org/spamassassin/TrustedRelays
一例 あるspamのヘッダの一部(Received:行のみ抜粋) yahoo.co.jpのMTAは送信元IPの逆引きを行わない Received: from pop.mail.yahoo.co.jp [202.93.87.247] by vawr.pblnet.local with POP3 (fetchmail-6.3.9-rc2) for <yoh@localhost> (single-drop); Mon, 17 Aug 2009 08:10:07 +0900 (JST) Received: from 180.94.8.6 (HELO mx1.mail.yahoo.co.jp) (180.94.8.6) by mta155.mail.kcd.yahoo.co.jp with SMTP; Mon, 17 Aug 2009 08:09:42 +0900 yahoo.co.jpのMTAは送信元IPの逆引きを行わない
一例 $ whois 180.94.8.6 inetnum: 180.94.8.0 - 180.94.8.255 netname: Warpspeed-2-Tel descr: Wifi Provider in Djibouti country: PH admin-c: Gna30-AP tech-c: Gna30-AP status: ALLOCATED NON-PORTABLE mnt-by: MAINT-GLOBALSPEED-PH changed: globalspeed2010@gmail.com 20090811 source: APNIC $ whois 180.94.20.6 inetnum: 180.94.0.0 - 180.94.31.255 netname: GLOBALSPEED-PH descr: 5th Flr JY Square Bldg status: ALLOCATED PORTABLE mnt-by: APNIC-HM mnt-lower: MAINT-GLOBALSPEED-PH
一例 SAのデバッグ出力の一部抜粋 $ spamassassin -d < samplespam.txt|spamassassin -t -D [31190] dbg: metadata: X-Spam-Relays-Trusted: [31190] dbg: metadata: X-Spam-Relays-Untrusted: [ ip=180.94.8.6 rdns=180.94.8.6 helo=mx1.mail.yahoo.co.jp by=mta155.mail.kcd.yahoo.co.jp ident= envfrom= intl=0 id= auth= msa=0 ] [ ip=180.94.8.6 rdns= helo= by= ident= envfrom= intl=0 id= auth= msa=0 ] [31190] dbg: metadata: X-Spam-Relays-Internal: [31190] dbg: metadata: X-Spam-Relays-External: [ ip=180.94.8.6 rdns=180.94.8.6 helo=mx1.mail.yahoo.co.jp by=mta155.mail.kcd.yahoo.co.jp ident= envfrom= intl=0 id= auth= msa=0 ] [ ip=180.94.8.6 rdns= helo= by= ident= envfrom= intl=0 id= auth= msa=0 ]
一例 [31190] dbg: metadata: X-Spam-Relays-Untrusted: [ ip=180.94.8.6 rdns=180.94.8.6 helo=mx1.mail.yahoo.co.jp by=mta155.mail.kcd.yahoo.co.jp ident= envfrom= intl=0 id= auth= msa=0 ] [ ip=180.94.8.6 rdns= helo= by= ident= envfrom= intl=0 id= auth= msa=0 ] 上記仮想ヘッダを検出するルール header GLOBALSPEED_PH X-Spam-Relays-Untrusted =~ /^\[ ip=180\.94\.(?:\d|[12]\d|3[01])\.\d{1,3} / describe GLOBALSPEED_PH [PH]GLOBALSPEED-PH score GLOBALSPEED_PH 1.5
ルールの書き方 spamの特徴を見極める spamの特徴を捉えた正規表現を書く
spamの特徴を見極める 類似spamを複数用意して見比べる From:は殆ど無意味 bodyよりもheader grep,pager(jless等),エディタを使い慣れる From:は殆ど無意味 特定のメイルアドレスを登録してもいたちごっこになるだけ 但し、携帯電話を偽るspamを認識する場合は効果的 bodyよりもheader 日本語キーワードは意外に効果が薄い mimeheaderよりもfull mimeheaderを見るなら全てのコンテンツ定義文字列を見 るのが良い
spamの特徴を捉えた正規表現を書く どこからどこまでマッチングさせるかを明確 にする 少しずつ書き足すとよい なるべく厳密に書く →false positive防止の為 *(0文字以上マッチング)はなるべく避ける
ルール作成の注意点 ISO-2022-JP/Shift-JIS/UTF-8等をマッチン グさせる際はrawbodyルールを使う fullルールは行頭(^)行末($)を認識しない ^はメイル先頭、$はメイル終端 ISO-2022-JP/Shift-JIS/UTF-8等をマッチン グさせる際はrawbodyルールを使う bodyルールではマッチングしない (3.2.xの仕様変更らしい) 仮想ヘッダは偽Received:を変換しない SAはReceived:行の正当性をチェックする
ルールの一例 Multipart/Alternativeなmailなのに、bodyにはQuoted-PrintableエンコーディングされたShiftJISのプレインテキストしか付されていないspamを検出するルール full MPALTSJISQPONLY /\nContent-Type: multipart\/alternative;\n\tboundary=\"(--=.+(?:[a-zA-Z0-9]|=_)|--[0-9]{14,})\"\n(?:.+\n){2,}\n--\1\nContent-Type: text\/plain;(?: charset=\"shift_jis\"){0,1}\nContent-Transfer-Encoding: quoted-printable\n\n(?:(?!\1).+\n|\n){2,}--\1--\n/
ルールの一例 (?:(?!\1).+\n|\n){2,} ←本文 full MPALTSJISQPONLY / \n ←改行 Content-Type: multipart\/alternative;\n ←ヘッダの宣言文 \tboundary=\" (--=.+(?:[a-zA-Z0-9]|=_)|--[0-9]{14,}) ←バウンダリ文字列 \"\n (?:.+\n){2,} ←ヘッダ(空行でない) \n ←空行、つまりヘッダと本文との境界 --\1\n ←本文中最初のバウンダリ文字列 Content-Type: text\/plain;(?: charset=\"shift_jis\"){0,1}\n Content-Transfer-Encoding: quoted-printable\n ↑マルチパート宣言文 \n ←空行 (?:(?!\1).+\n|\n){2,} ←本文 --\1--\n ←本文中最後のバウンダリ文字列(行末の”--”) /
最近のspamの傾向 全spam中、アジア発(APNIC)spamとその他 (ARIN/LACNIC/RIPE_NCC/AFRINIC)とはほぼ 半々の比率 ALL:59869 ASIA:30889 NOTASIA:28980 (直近62日分) 日本語spamは24%程度 全日本語spam中、アジア発は98% →日本語spamのbotnet使用率は低い? 無料webメイルサービスを悪用したspamが僅 かながら増加傾向
最後に あくまでも個人の成果物なので、無保証で す。 何か不具合や疑問点或は改善提案等がありま したら、yoh@flcl.org に御一報願います。 質疑応答等は http://spamassassin.jp/ で 行っています。
御静聴有難うございました。