Slide 1

Slide 1 text

Tomohisa Oda — さくらインターネット研究所 Software Engineer @さくらの 夕 べ in 福岡 Jun 1 7 , 2 0 2 4 透過型SMTPプロキシによる送信メールの 可観測性向上

Slide 2

Slide 2 text

https://tomohisaoda.com • 福岡在住 🍜 • A ffi liation: さくらインターネッ ト、COGNANO • Community: Fukuoka.go主催 • Weight Trainingとテニスが趣味 Tomohisa Oda / @linyows

Slide 3

Slide 3 text

Outline 1 . メールシステムの現状 2 . メールホスティングの事情と課題 3 . 透過SMTPプロキシによる送信メール可観測性向上の提案 4 . 経路暗号化強制対応と複数IP使い分けの課題

Slide 4

Slide 4 text

メールシステムの現状

Slide 5

Slide 5 text

複数のプロトコルと多くのサーバーコンポーネントが必要 メールを送信して相 手 が受信するまでの全体像

Slide 6

Slide 6 text

メールにおけるセキュリティの問題 • メールの送信者は正しいか? • メールに盗聴や改ざんはされていな いか? • 自 分のフリをしてメールを送られて いないか? • 送信ドメイン認証(SPF、DKIM、 DMARC) • 経路暗号化(TLS、MTA-STS) • 転送対応(SRS、ARC) GmailやOutlook使っていれば何も考え(ry

Slide 7

Slide 7 text

長 い年 月 をかけメールセキュリティを向上中 歴史的経緯とはいえ、複雑すぎますね…

Slide 8

Slide 8 text

メールに対する信頼性の低下 メールInboxは未読で溢れていませんか? • メール配信が安価なマーケティングツールとなっていて、 大 量の広告メールが メールInboxを占有している • 利 用 しているサービスがセキュリティインシデントにより 自 分のメールアド レスが流出しており、 大 量のスパムメールが着信する • そもそも、Instagram、X、Slack、LINEといったSNSやメッセージングプラ ットフォームで 生 活しているのでメールに問題があっても問題とは思わない

Slide 9

Slide 9 text

一 般的なスパムメール対策 • スパムフィルター(SpamAssassin、Amavis … ) • DNSBLを使った受信拒否 • メール流量によりIPスロットリング(受信拒否)やタールピット(レスポン ス遅延) • グレイリストを使った再送要求

Slide 10

Slide 10 text

Gmailのスパムメールの削減施策 2024年2 月 から • 送信ドメイン認証の強制 • 経路暗号化の強制 • ワンクリック配信解除の強制 (New)

Slide 11

Slide 11 text

メールホスティングの事情と課題

Slide 12

Slide 12 text

メールホスティングの事情(送信のみ) • ドメイン単位に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

Slide 13

Slide 13 text

送信MTAのコンテナ化でIP集約とメールキュー分散 xxx.xxx.xxx.xxx yyy.yyy.yyy.yyy example.com example.jp example.org example.net example.us example.gov

Slide 14

Slide 14 text

分散MTAの可観測性が低い • MTAが出 力 するログを集約しパースすることによってメールシステム全体で 何が起きているか把握出来るようにはなる • しかしシステムで何が起きていたかを確認することはできても、リアルタイム に問題を検知して修復することは難しい • 例えばIPスロットリングが発 生 していることを検知し、発 生 の引き 金 となっ たドメインの送信を 止 め、送信に使うIPを付け替えるといった運 用 の 自 動化 などを 行 える環境にしたい

Slide 15

Slide 15 text

透過プロキシによる送信メール可観 測性向上の提案

Slide 16

Slide 16 text

• 透過プロキシなのでメールキュー はコンテナ側で管理し、ルーティ ングだけを変える • SMTPプロトコルレベルでDBに 通信情報蓄積し何が発 生 している かリアルタイムで検知できるよう にする • 同 一 ホストのためコンテナのMTA とプロキシ間はTLSを使わない コンテナホストごとに透過プロキシを導 入 する xxx.xxx.xxx.xxx example.com example.jp example.org example.net example.us example.gov Proxy DB

Slide 17

Slide 17 text

透過型SMTP送信プロキシ: WARP https://github.com/linyows/warp • 一 般的なSMTPプロキシで送信 用 に使えるものはないためGoで 自 作 • MTAプロセスからの25番宛先のパケットをiptablesでDNATし、本当の宛先を システムコールから取り出して使っている • 相 手 MXからのEHLOレスポンスに含まれるSTARTTLSを削除してMTAに返却 しプロキシは相 手 MXとTLS接続する • フックイベントを作っているのでプラグインから処理追加が可能 • カナリアリリースで本番導 入 検証済み

Slide 18

Slide 18 text

No content

Slide 19

Slide 19 text

取得できるデータ例 MySQLとSQLiteプラグインで は、Connectionsテーブルと Communicationsテーブルが あり、SMTPのやりとりが後者 にレコードとして保存される

Slide 20

Slide 20 text

検証環境での事例: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.

Slide 21

Slide 21 text

検証環境での事例:3 SMTPセッション数10で100通を 大手 メールサービス宛に送る実験 3. 実験途中からMAIL FROMとRCPT TOの間で20秒ほどの応答遅延が観測された

Slide 22

Slide 22 text

経路暗号化強制対応と複数IP使い分けの課題 • 相 手 MXとTLS通信するのは透過SMTPプロキシなので、経路暗号化の強制は 透過SMTPプロキシの役 目 となり、MTA-STSの実装が必要である • IPスロットリング時の運 用自 動化や内部レピュテーションによる複数IP使い 分けのための機能追加が必要である

Slide 23

Slide 23 text

謝辞: 本研究は JSPS科研費20K 1 1 7 9 1 「軽量コンテナによる 大 規模 高 集積メールホスティング基盤における送信機能の 高 機能化」の 助成を受けたものです。