透過型SMTPプロキシによる送信メールの可観測性向上 / Improved observability of outgoing emails with transparent smtp proxy

さくらの夕べ in 福岡 Jun 17, 2024 で使用した資料です。

Transcript

1. Tomohisa Oda — さくらインターネット研究所 Software Engineer @さくらの 夕 べ in 福岡 Jun 1 7 , 2 0 2 4 透過型SMTPプロキシによる送信メールの 可観測性向上
2. https://tomohisaoda.com • 福岡在住 🍜 • A ffi liation: さくらインターネッ ト、COGNANO • Community: Fukuoka.go主催 • Weight Trainingとテニスが趣味 Tomohisa Oda / @linyows
3. Outline 1 . メールシステムの現状 2 . メールホスティングの事情と課題 3 . 透過SMTPプロキシによる送信メール可観測性向上の提案 4 . 経路暗号化強制対応と複数IP使い分けの課題
4. メールシステムの現状
5. 複数のプロトコルと多くのサーバーコンポーネントが必要 メールを送信して相 手 が受信するまでの全体像
6. メールにおけるセキュリティの問題 • メールの送信者は正しいか？ • メールに盗聴や改ざんはされていな いか？ • 自 分のフリをしてメールを送られて いないか？ • 送信ドメイン認証（SPF、DKIM、 DMARC） • 経路暗号化（TLS、MTA-STS） • 転送対応（SRS、ARC） GmailやOutlook使っていれば何も考え(ry
7. 長 い年 月 をかけメールセキュリティを向上中 歴史的経緯とはいえ、複雑すぎますね…
8. メールに対する信頼性の低下 メールInboxは未読で溢れていませんか？ • メール配信が安価なマーケティングツールとなっていて、 大 量の広告メールが メールInboxを占有している • 利 用 しているサービスがセキュリティインシデントにより 自 分のメールアド レスが流出しており、 大 量のスパムメールが着信する • そもそも、Instagram、X、Slack、LINEといったSNSやメッセージングプラ ットフォームで 生 活しているのでメールに問題があっても問題とは思わない
9. 一 般的なスパムメール対策 • スパムフィルター（SpamAssassin、Amavis … ） • DNSBLを使った受信拒否 • メール流量によりIPスロットリング（受信拒否）やタールピット（レスポン ス遅延） • グレイリストを使った再送要求
10. Gmailのスパムメールの削減施策 2024年2 月 から • 送信ドメイン認証の強制 • 経路暗号化の強制 • ワンクリック配信解除の強制 （New）
11. メールホスティングの事情と課題
12. メールホスティングの事情（送信のみ） • ドメイン単位にIPv 4 を割り振ることはできな いため、メール送信に使 用 するIPは集約したい • とはいえ、集約しすぎるとIPスロットリングの 影響範囲が 大 きくなる • メール送信キューも集約しすぎると滞留時に影 響範囲が 大 きくなり運 用 が 大 変になる • つまり、メールキューは分散しIPは適切な分量 に集約するのが良い example.com example.jp example.org example.net example.us example.gov xxx.xxx.xxx.xxx yyy.yyy.yyy.yyy example.com example.jp example.org example.com example.jp example.org
13. 送信MTAのコンテナ化でIP集約とメールキュー分散 xxx.xxx.xxx.xxx yyy.yyy.yyy.yyy example.com example.jp example.org example.net example.us example.gov
14. 分散MTAの可観測性が低い • MTAが出 力 するログを集約しパースすることによってメールシステム全体で 何が起きているか把握出来るようにはなる • しかしシステムで何が起きていたかを確認することはできても、リアルタイム に問題を検知して修復することは難しい • 例えばIPスロットリングが発 生 していることを検知し、発 生 の引き 金 となっ たドメインの送信を 止 め、送信に使うIPを付け替えるといった運 用 の 自 動化 などを 行 える環境にしたい
15. 透過プロキシによる送信メール可観 測性向上の提案
16. • 透過プロキシなのでメールキュー はコンテナ側で管理し、ルーティ ングだけを変える • SMTPプロトコルレベルでDBに 通信情報蓄積し何が発 生 している かリアルタイムで検知できるよう にする • 同 一 ホストのためコンテナのMTA とプロキシ間はTLSを使わない コンテナホストごとに透過プロキシを導 入 する xxx.xxx.xxx.xxx example.com example.jp example.org example.net example.us example.gov Proxy DB
17. 透過型SMTP送信プロキシ: WARP https://github.com/linyows/warp • 一 般的なSMTPプロキシで送信 用 に使えるものはないためGoで 自 作 • MTAプロセスからの25番宛先のパケットをiptablesでDNATし、本当の宛先を システムコールから取り出して使っている • 相 手 MXからのEHLOレスポンスに含まれるSTARTTLSを削除してMTAに返却 しプロキシは相 手 MXとTLS接続する • フックイベントを作っているのでプラグインから処理追加が可能 • カナリアリリースで本番導 入 検証済み
19. 取得できるデータ例 MySQLとSQLiteプラグインで は、Connectionsテーブルと Communicationsテーブルが あり、SMTPのやりとりが後者 にレコードとして保存される
20. 検証環境での事例：1, 2 SMTPセッション数10で100通を 大手 メールサービス宛に送る実験 1 . 同時最 大 接続数制限に引っかかった 4 5 1 4 . 7 . 6 5 2 The mail server [xxx.xxx.xxx.xxx] has exceeded the maximum number of connections. 2 . レピュテーションの低さから受信拒否の判断をされた 5 5 0 - 5 . 7 . 1 [xxx.xxx.xxx.xxx] Our system has detected that this message is likely suspicious due to the very low reputation of the sending domain. To best protect our users from spam, the message has been blocked.
21. 検証環境での事例：3 SMTPセッション数10で100通を 大手 メールサービス宛に送る実験 3. 実験途中からMAIL FROMとRCPT TOの間で20秒ほどの応答遅延が観測された
22. 経路暗号化強制対応と複数IP使い分けの課題 • 相 手 MXとTLS通信するのは透過SMTPプロキシなので、経路暗号化の強制は 透過SMTPプロキシの役 目 となり、MTA-STSの実装が必要である • IPスロットリング時の運 用自 動化や内部レピュテーションによる複数IP使い 分けのための機能追加が必要である
23. 謝辞： 本研究は JSPS科研費20K 1 1 7 9 1 「軽量コンテナによる 大 規模 高 集積メールホスティング基盤における送信機能の 高 機能化」の 助成を受けたものです。