サーバでの実戦的スパム対策手法

話の流れ

まとめ
手法をSMTP解説交え説明
お勧めの構成
なぜかを状況交え説明
今後

この話の主な対象

メールサーバでのスパム受信
国内の企業や大学などの中規模メールサーバ
主にPostfixでの設定
具体的な設定はWeb見て下さい

まとめ

重視すること
- 誤検出が無い
- メンテコストが低い
しかし
- 誤検出は必ずある
- どんな手法も対抗策がある
- 誤検出＝ホワイトリスト必須
そのためには
- 一つで完璧を目指さない
- 複数の手法を組み合わせる
- SMTPセッション情報も活用

各種手法と代表的なもの

受けない手法と送らせない手法
どこで対策するか
- クライアント(PC)
- サーバ
- ネットワーク
受けない手法
- クライアント
  - ベイジアンフィルタ
    - (POPFile)
    - (ThunderBird)
- サーバ
- ネットワーク
  - IP25B？
送らせない手法
- クライアント
  - セキュリティ対策ソフト
- サーバ
  - スロットリング
- ネットワーク
  - OP25B

ここではサーバの対策手法

SMTPについておさらい
- 接続
  - クライアントのIP
    - ユーザが任意に変更不可
- HELO
  - クライアントの名前(FQDN)
    - ユーザが任意に変更不可
- MAIL FROM
  - 送信者名(Envelope From)
- RCPT TO
  - 送信先名(Envelope To)
- DATA
  - ヘッダと本文
- QUITで終了
参考
- やまぐちたかのり氏のページ MTA のアクセス制御
コンテンツフィルタ
- キーワードマッチング
  - (SpamAssassin)
    - 現在は複合型
  - 仕組みが簡単
  - きりがない
- ベイジアンフィルタ
  - (bsfilter)
  - (bogofilter)
  - (CRM114)
  - 精度が高い
  - 自動学習する
  - 非常に重い
  - 変動して誤検出の可能性
  - 日本語化の問題
- メールシグニチャ
  - (razor)
  - (pyzor)
  - 誤検出がほぼ無い
  - 検出率は低め
- URIBL
  - (rbl.jp)
  - 効果が高い
  - DNSだと「URIBL」じゃない
  - URIが漏れる
SMTPセッション情報
- HELOの確認
  - (check_helo_access)
  - (reject_invalid_hostname)
  - (reject_non_fqdn_hostname)
  - 誤検出が無い
  - メンテの問題
- MAIL FROMの確認
  - (check_sender_access)
  - (reject_non_fqdn_sender)
  - (reject_unknown_sender_domain)
  - メジャーな対策
  - ユーザも変更出来る情報なのであまり使えない
- NSのブラックリスト
  - (check_sender_ns_access)
  - うまく設定できれば効果大
  - 一般のDNS使われてるとダメ
- DNSBL
  - (Spamhaus)
  - (SORBS)
  - 排除率が強力
  - 正しいサーバが入る可能性
  - IPアドレスの汚染
  - DNSBLの負荷の問題
- 複合型
  - (SpamAssassin)
    - キーワードマッチング
    - ベイジアンフィルタ
    - DNSBL
    - メールシグニチャ
- 動的IPフィルタ
  - (dul.dnsbl.sorbs.net)
    - 誤検出が多い
  - (S25R)
    - 軽い
    - 変動しない
    - メンテの問題
    - 誤検出が多い
- 中韓フィルタ
クライアントの動作特徴
- Greylisting
  - (postgrey)
  - (policy daemon)
  - 排除率高い
  - 誤検出を拾えない
  - 遅延が起る
  - 他のサーバへの負荷
- Secondary MXに再送
  - (GION)
- Tarpitting
  - (greet pause)
  - (sleep)
- Pipeliningの確認
  - (reject_unauth_pipelining)
送信者確認
- SenderID
- DKIM

なぜこうしたのか

完璧な手法の一つのフィルタだけを使うのが美しい
そんなふうに考えていた時期が俺にもありました
HELOやFROM、キーワードで
- メンテコストが掛かりすぎ
ベイジアンフィルタ(CRM114)
- 重い
- 学習の問題
- ユーザ毎のDBの問題
SpamAssassin
- さらに重い
明らかにスパムは捨てたい
- 負荷が無駄
  - ウイルスフィルタも
- ゴミ漁りがうっとおしい
Greylisting
- 軽い
- ゴミは捨てられる
- 誤検出の問題
- 遅延の問題
- 他のサーバへの負担
S25R
- 非常に軽い
- 誤検出が多い
- メンテコストが高い
- S25Rだけで拒否は高リスク
S25Rで人手でメンテしてる内容はGreylistingと同じ
- 動的IPっぽいとこから再送しないもののみ排除
GreylistからS25Rを考える
- 動的IPっぽくなければ素通し
- 一般化したホワイトリスト
- DNSBLのnotも同じく考えれる
  - S25Rは「正しいサーバ」を誤検出することが無い
抜けてきたものを見る
- Postfixやqmailを使い送信
- HELOやMAIL FROMが特徴的
- 業者(ツール)が限られている
- ねらい打ちに出来る
それでも抜けるもの
- 素直にコンテンツフィルタ使う
- セッション情報も活用出来る
- 2段それぞれ9割で99%になる
- 確実なものだけ落とせば良い
より誤検出・副作用を減らす
- Tarpitting
  - Tarpit分しか遅延しない
  - 再送は実装しなくてもタイムアウト時間は待つだろう
  - 一般のMTAで故意に短くしているのはスパムの可能性大
- スパムと同じ出し方だと誤検出
  - ポイント系メールマガジン等
  - Greylistingで救済
  - taRgrey

状況

スパム率
- 70〜80%
同一IPから出される期間
- 1時間以内が 75%
- 1日以内が 90%
IPあたりのスパムメール数
- 3.3通
- 10通までで 97%
動的IPっぽい(S25R)率
- ジャンクメール中 98%
HELOブラックリストでの排除率
- 51%
HELOでこちらのサーバのIPやFQDNを騙る率
- 34%
Greylisting排除率
- 93%
Tarpittingのみの排除率
- 90秒で80%
Tarpitting待ち時間との関連(Tarpittingで排除される内)
- 35秒で75%
- 65秒で95%

運用のコツ

warnでログをとる
- 緩く落として抜けたのを観察
全メールの検知
- SpamPD
ログを解析するツールを準備
- 同一IPからの接続期間
- 同一IPからのメール数など
確実なものはrejectでも可
- HELOでこちらのサーバを騙る場合など
セッション情報andで使うために
- smtpd_restriction_classes
- ホワイトリストと捉えOKにする
SpamAssassinでセッション情報
- PREPEND
- heloやclientのパラメータ有り
こちらに有利な点
- 送信業者やソフトは限られる
  - パターンが決まってくる
- 送信業者と依頼者とに分業
  - 法的に追求がしにくいというデメリット
  - しかし送信業者は対策されてもそれほど困らないため工夫しない
  - ちゃんとタイムアウト時間を調整してるマメな業者はTarpitで排除できる
捨てるかユーザに確認させるか
- 人間が誤検出する
  - 1万通中100通の正しいメール
- 精度が低ければ人が誤認
- 精度が高ければ確認しない
- 責任を人に転嫁してる
ポイント順にソート
- Maia Mailguard

モーグルとカバとパウダーの日記

モーグルやカバ(EXカービング)山スキー(BC)などがメインの日記でした。今は仕事のコンピュータ系のネタが主になっています。以前はスパム対策関連が多かったのですが最近はディープラーニング関連が多めです。

話の流れ

この話の主な対象

まとめ

各種手法と代表的なもの

ここではサーバの対策手法

おすすめ構成

なぜこうしたのか

状況

運用のコツ

今後のアイデア