進化するスパムフィルタ【後編】
フィルタだけでは減らないスパム、その撲滅に向けてすべきこと
いくら判定精度が高くても、単一のスパム対策では押し寄せるスパムは減らせない。正規メールの誤判定や判定後の対応など、見えにくい問題を取り上げながらスパム対策製品の導入ポイントを探っていく。
前編「IPレピュテーションはスパムの抜本対策となり得るか」ではスパムメール送信側の技術の進化について説明した。だが、スパムフィルタの技術ももちろん進化している。
現在、さまざまなタイプのアンチスパムフィルタが存在しているが、ベンチマーク結果や実際の運用時などにおいて特に評価が高いのが、ネットワークフィードバック型のフィルタである(図1)。
実際に受信したスパムやハニーポットなどで収集したスパムのデータをリアルタイムにベンダーのセンターに蓄積し、それを参照してスパムをフィルタリングするという技術だ。フィードバックされたスパムの情報を解析し、スパムの特徴を抽出して、フィルタ用のデータを作成する。フィードバックからデータ作成までの時間を可能な限り短かくすることで、一般的なスパムはもとより、まったく新種のスパムが現れても数分以内にスパムと判断されるようになる。この方式の最大の利点は、実際のスパムのデータを基にしているため、ほかの方式に比べ誤判定が少ないということである。データの収集方法や特徴の抽出方法はベンダーごとに多種多様だ。
スパムフィルタ導入のポイントを考える
実際にスパムフィルタを導入する場合、どのような点に注意して選択すべきだろうか。やはり最も重要なのは、スパムフィルタの「判定精度」だ。スパムの精度の違いで結果にどれだけの差が出るのかを図2に示す。受信するメールの80%(正規メール50通に対してスパムが200通の世界)以上がスパムであるといわれる現在、フィルタの精度80%と98%とでは、メールボックスに届くスパムの量がまったく違うことが分かるだろう。精度が低いフィルタを導入すると、一般ユーザーがそのスパムフィルタの効力をまったく体感できない場合もある。
さらにメンテナンスという点も重要だ。特にベイジアン方式のフィルタ(※)では、スパム判定の基にするデータを収集するためにトレーニングが必要な場合がある。サイトごとやユーザーごとにスパムの判断をトレーニングできるという利点はあるものの、世の中に出回るスパムは刻一刻と変化していくので、高い精度を保つために常にトレーニングをしていかなければならない。それが管理者の負荷となる場合を考慮しておくべきだろう。
※ ベイズ(統計的予測)理論を利用したフィルタ。スパム/非スパムメールの中に使われる単語の出現率を基にスパム判定する。繰り返し学習をさせることで判定精度が向上するが、最近はベイジアンフィルタを巧妙にくぐり抜けるスパムも増えてきた。
スパムフィルタにも特徴がある
最近の商用スパムフィルタの精度は向上しており、精度が高ければどの製品を選んでも同じように見える。しかし実際には、どういうメールをスパムと判断するか、また新種のスパムが出てからどのくらいの時間で対応するかなどの点で、ベンダーごとに特徴がある。従って、スパムフィルタを選択するときは、可能であれば自分のサイトで実際のメールトラフィックを流して評価試験を実施すべきだ。
例えば、メールマガジンや各種アナウンスメール、Webコマースサイトからのキャンペーンメールなど、スパムではないが一斉に大量送信されてくる場合がある。商品の説明などについてのメールだと、内容的にもスパムに近く、判断が難しいところだ。こうした配信メールの扱いについては、スパムフィルタの各製品ごとに判断が分かれやすく、それぞれのスパムフィルタの特徴が出る部分である。これ以外にも、自分のサイトではどういうメールをスパムとして扱い、あるいはスパムとしたくないかという意向もあるだろう。導入に当たっては実際に評価試験を実施して、サイトに合ったフィルタリングが行われているかチェックしよう。
考慮しておきたいスパム誤判定の問題
高精度なスパムフィルタでも、やはり誤判定はどうしても起きてしまう。根本的に、スパムの判断というのは“グレーゾーン”が存在している。例えば同じ1つのメールマガジンを受け取ったとして、受信者がそれを購読していれば正規メールだが、購読していなければスパムとなる。そもそもどのようなメールが迷惑なのかというのも、受信者の主観に依存するところがある。
スパムの誤判定には、「擬陽性(FP:False Positive)」と「疑陰性(FN:False Negative)」の2種類がある。FPは正規のメールを間違ってスパムであると判定することで、FNはスパムを正規メールと判断してしまうことだ。一般的に、企業システムで問題とされるのはFPの方である。特に、特定の個人から特定の個人に送信したメールがスパムと判断されることを「False Critical(FC)」とも呼び、重大な問題であると受け取られがちだ。そのほか、会社が顧客などに向けて送信するアナウンスメールがスパムと判断される場合も問題となる。
誤判定として報告されるメールもさまざまで、中には本当に誤判定なのか微妙なものもある。例えば、空白メールだ。空のスパムメールは近年増加傾向にあるといわれているが、実際に件名も本文もないと、一体どのような意図で送信してきているのかが不明だ。この空メールは、スパム送信者が送信失敗した場合、またはディレクトリハーベストアタック(DHA)の副産物として発生すると考えられている。こうした空のスパムは、件名や本文以外に何か特徴的なデータ(例えばヘッダなど)が存在しなければ、スパムかそうでないかを判断するのは難しくなる。
さらに、相手に自分のメールアドレスを知らせたい場合や、特に携帯電話メール向けのサービスで、ユーザー登録の際に空メールの送信を要求する場合など、正規の理由で空メールを送信する場面においても扱いが難しい。
誤判定への対応も導入ポイント
誤判定の中でも、正規メールがスパムとして判断されるFPの発生は、企業において想像以上に問題となる。筆者の経験上、実際に自分あての重要なメールでFPが発生すると、何十万通に1つの誤判定でも大騒ぎとなることが多い。スパムフィルタ導入の際には、たとえ精度が高くても誤判定が発生する可能性はあることを周知するとともに、発生した場合の報告方法や対処方法もはっきりと事前に決めておくことをお勧めする。
その点フィードバック型のスパムフィルタでは、ベンダー側が簡単に誤判定メールを報告できるような手段が提供されており、それを利用することで早期に解決できる場合が多い。さらに、自サイトからのフィードバックの状態をWebから確認できるようなサービスを同時に提供しているベンダーもある。単にフィードバックがうまく行われているかを確認できるだけでなく、スパムフィルタの判断についてエンドユーザーがどのような印象を持っているのかを判断できるので、こうしたサービスも利用するとよい。
スパムメールの保留
スパムの誤判定が一切発生しなければ、スパムと判定されたメールはすべてその場で廃棄したい。なぜなら、スパムをすべて受信し、ユーザーのメールボックスに格納していると、メールサーバのデータ量が限りなく増加していくからだ。一般にメールシステムではメールデータを格納するために高信頼性、高性能のストレージ装置を利用することが多いが、用意した高価なストレージがスパムでいっぱいになってしまってはたまらない。メールデータのバックアップや、監査目的でメールをアーカイブしている場合も、スパムデータのために時間やストレージ装置を無駄に消費してしまう(図3)。しかしFPの発生を考えると、残念ながらその場で削除するということは難しいだろう。
この場合に有効となるのが、スパムメールの保留(隔離)という機能(図4)である。スパムフィルタによりスパムらしさが高いと判断された場合、それをユーザーのメールボックスに配送するのではなく、いったん保留サーバに保存する。この保留サーバでは、到着してから一定時間(例えば2週間など)経過したメールを自動的に削除するため、スパムでストレージ容量が浪費されることを防げる。また、FPが発生した場合でも、一定時間は保留サーバにあるので、保留サーバの中で必要なメールを見つけることができる。1日に一度、スパムとして判断されたメールの一覧を受信者に送る機能を持つ製品であれば、正規メールがスパムと判断されたことがすぐに分かり、誤判定の悪影響を最小限にとどめることが可能だ。こうした保留サーバを運用する際は、エンドユーザーが直接、自分あてのメールを確認できるようなインタフェースを提供する製品を導入することをお勧めする。スパムの数は予想外に膨大であり、システム管理者のグループが保留メールのチェックを毎日行うことは現実的に難しいのだ。
スパムフィルタをより有効にするIPレピュテーション
IPレピュテーションは、前回解説した通り、その情報をトラフィック制御と組み合わせて利用することで、メールの誤判定を減少させることが可能だ。危険度の高い接続元でも即座に受信拒否するのではなく、トラフィック監視のしきい値を低くし、危険度が高くとも実際に何か不審なトラフィックが発生しないかぎり受信の制限を掛けないように運用する。
IPレピュテーションで危険度が高いと見なした場合、接続元への対応はSMTPの通信中で行われるが、この対応方法については各種選択できる製品がよいだろう。一律に接続拒否するような対応方法しか実施できないと、誤判定の発生時にメールが受信できないことになる。
メールが危険だと見なされた場合、一般的には一時的な受信拒否(4xx番エラー)を返して、送信元に再送を促す。スパム送信者はほとんどの場合、再送をしてこないからである。正常なメールであれば、大体数十分後に再送を試みるはずだ。また、常に一時的な受信拒否を行っていては受信拒否するのと変わらないので、前述のようなトラフィック制御を併用して、しきい値を超えてから一定時間は一時的な受信拒否を返し、一定時間経過した後は受信拒否のアクションを解除するようにする(図5)。その結果、ある程度スパムがすり抜けてしまうかもしれないが、その対処は後段のスパムフィルタに任せればよい。IPレピュテーションとトラフィック制御で80%程度のスパムをゲートウェイのメールサーバ上で排除できれば、スパムフィルタで扱うスパムメールの総数を削減し、すり抜けるスパムの数を相対的に減少させることができる。また、前述の空メールスパムやDHAなどについては、まさに送信者の情報が判断の要になるIPレピュテーションを使って対応できる。
サイトの要求には複数機能の組み合わせで応える
残念ながら、より巧妙になっていくスパム送信には、1つの対策だけでは立ち向かえない。スパムフィルタ、IPレピュテーション、ホワイトリスト、トラフィック制御などのソリューションを効果的に組み合わせて対応していこう。スパムを排除し、信頼性が高く適切な規模の電子メールシステムを運用するのが理想だが、個々の機能をなし崩し的に取り入れているとメールシステムが複雑になり、管理コストの増大やシステムの信頼性の低下といった問題を招いてしまうので気を付けよう。自身のサイトの要求や解決すべき問題を考えた上で、なるべくシンプルな構成で複数の機能をうまく統合できる製品を選ぶべきだろう。
<筆者紹介>
末政延浩
センドメール テクニカルディレクター
米国Sendmail,Inc設立時より商用版sendmail製品を扱い、同社日本法人立ち上げメンバーとして参加。センドメールではISPおよび企業向け大規模電子メールシステム構築のコンサルタントとして従事。Japan E-main Anti-abuse Group(JEAG)にて送信ドメイン認証の勧告書作成に協力。
Copyright © ITmedia, Inc. All Rights Reserved.
この記事の著者
関連記事
新着ホワイトペーパー PR
-
製品資料
[株式会社MatrixFlow] 「物流リソース最適化」ガイド:人員・配車・傭車を出庫依頼の確定前に決めきる -
製品資料
[株式会社キーエンス] なぜRPA導入は頓挫する? シナリオ作成の壁を乗り越える解決策とは -
製品資料
[株式会社セールスフォース・ジャパン] 「CRMは設計と無関係」は本当か? PLMとの融合で実現する高速開発 -
事例
[日本ヒューレット・パッカード合同会社] AIエージェントの時代にどう備える? 「新たな働き手」を支える3要素とは -
製品資料
[日本ヒューレット・パッカード合同会社] “横並びの自動化”から脱却、AI活用で生産性と競争力を高める秘訣
こんなメディアも見られています
TechTargetジャパンに関連する情報をお探しであれば、こちらのメディアもお役に立てるかもしれません。
ベンダーコンテンツ PR
From Informa TechTarget
SpecialPR
アクセスランキング
-
1
なぜ「全社配布Copilot」は使われないのか? 失敗に学ぶAI定着
-
2
法務と開発者で「言葉が通じない」問題 トヨタやソニーが語るOSS管理の真実
-
3
なぜ「Gemini 4 Argon」は出遅れたのか? Googleが狙う“逆転のシナリオ”
-
4
損保ジャパンはなぜ「COBOL」を捨てなかったのか? 脱メインフレームの真相
-
5
情シスの約8割が転職や退職を意識 調査で分かった“辞めたくなる最大の理由”
-
6
ChatGPTは“検索しまくり”でGeminiは“淡泊”? データが明かすAIの裏側
-
7
情報漏えいはなぜ繰り返されるのか 今すぐ見直すべき「境界」
-
8
「Wi-Fi 7」経由でWindowsが乗っ取られる? 最高権限奪取の恐怖
-
9
「結局使わなくなる」Microsoft 365 Copilotを半年で定着 キリンの3施策
-
10
「中堅・中小企業のネットワーク・セキュリティ運用実態」に関するアンケート
ホワイトペーパーランキング PR
-
1
不審メールの経路や見せ方に変化? 2026年夏の3事例から見えた動向と対処方法
-
2
家庭用Wi-Fiルーターの業務利用は危険? 避けるべき理由と具体的な対策
-
3
Microsoft 365を安全に運用 うっかりミスやサイバー攻撃に備えるデータ保護術
-
4
財務部門がAIを最大限に活用する方法 無駄のない戦略的リーダーシップへの道
-
5
LLMが兵器化? 元FBI高官が鳴らす警鐘とセキュリティツール統合のポイント
-
6
「オンプレミス回帰」せざるを得ない“合理的な理由”
-
7
なぜRPA導入は頓挫する? シナリオ作成の壁を乗り越える解決策とは
-
8
生成AIを開発に導入しても効果が見えない? 実証実験で分かった成果と課題
-
9
経産省DX指針から読み解く、受発注業務デジタル化ロードマップ
-
10
HDDを使わない「SSDオンリー」が無謀なのはなぜ?
TechTargetジャパン SNS
インフォメーション
注目情報をチェック
TechTargetジャパンをフォロー