お疲れ様です!IT業界で働くアライグマです!
先日、GitHubで「smtp-tunnel-proxy」というツールがトレンド入りしていました。これはTCPトラフィックをSMTPメール通信に偽装し、DPI(Deep Packet Inspection)ファイアウォールを回避するという興味深いツールです。
セキュリティエンジニアとして、こうした「攻撃者が使う可能性のあるツール」の仕組みを理解することは、検知・対策の設計において非常に重要です。本記事では、smtp-tunnel-proxyの動作原理を解説し、セキュリティ監視・対策の観点から何を見るべきかを整理します。
DPIファイアウォールとは何か
DPI(Deep Packet Inspection)ファイアウォールは、従来のパケットフィルタリングとは異なり、パケットのペイロード(データ本体)を解析して通信内容を判別する技術です。
従来のファイアウォールとDPIの違い
従来のファイアウォールは、送信元・宛先IPアドレスやポート番号だけを見て通信の許可・拒否を判断していました。しかしDPIは、パケットの中身を見て「これはHTTPなのか、SSHなのか、それとも別のプロトコルなのか」を判別します。
- パケットフィルタリング:ヘッダ情報(IP、ポート)のみを検査
- ステートフルインスペクション:コネクションの状態を追跡
- DPI:ペイロードを解析してアプリケーション層のプロトコルを識別
DPIにより、「ポート443を使っているが実際はVPNトラフィックである」といった偽装を検知できるようになりました。企業ネットワークや国家レベルの検閲システムで広く使われています。mongobleedで発覚したMongoDBの脆弱性と対策でも解説した通り、セキュリティの世界は攻防の連続です。
IT女子 アラ美smtp-tunnel-proxyの仕組み
smtp-tunnel-proxyは、任意のTCPトラフィックをSMTPプロトコルに見せかけて転送するツールです。GitHubで公開されており、DPIを回避する目的で設計されています。


アーキテクチャと動作フロー
smtp-tunnel-proxyの基本アーキテクチャは以下の通りです。
- クライアント側でローカルプロキシを起動
- アプリケーションのTCPトラフィックをローカルプロキシに向ける
- ローカルプロキシがTCPデータをSMTPコマンドに変換・エンコード
- SMTPサーバー(リモート側)がデータを受信し、元のTCPトラフィックに復元
- 復元されたトラフィックを実際の宛先サーバーに転送
SMTP偽装の技術詳細
SMTPは電子メール送信に使われるプロトコルで、テキストベースのコマンドでやり取りします。smtp-tunnel-proxyは、このSMTPコマンドの中にBase64エンコードされたデータを埋め込みます。
EHLO client.example.com
MAIL FROM:<tunnel@example.com>
RCPT TO:<target@example.com>
DATA
Subject: Tunnel Data
[Base64エンコードされたTCPペイロード]
.
QUIT
DPIから見ると、これは正規のSMTPメール送信に見えます。しかし実際には、メール本文にトンネリングされたTCPデータが隠されているのです。JSAnalyzerで静的解析を自動化するで紹介したように、静的解析だけでは見破りにくい手法が増えています。



ケーススタディ:smtp-tunnel-proxyの実際の動作検証
状況(Before)
ある企業のセキュリティチームから「ファイアウォールを回避する新しい手法が登場しているらしい」という情報が入り、検証を行うことになりました。検証環境として、DPIファイアウォール(Suricata)を設置したネットワークを用意しました。このファイアウォールは、OpenVPNやSSHトンネルを検知してブロックする設定になっています。
- 環境:Ubuntu 24.04上に構築した検証用LAN(192.168.100.0/24)
- ファイアウォール:Suricata 7.0 + ET Openルールセット + カスタムDPIルール15件
- 目的:smtp-tunnel-proxyが標準的なDPIを回避できるか検証
- 検証対象:SSHセッション(ポート22)のトンネリング
- 事前確認:OpenVPN、WireGuard、SSH直接接続はいずれもブロックされることを確認済み
行動(Action)
smtp-tunnel-proxyをGitHubからクローンし、クライアント・サーバー両方を設定しました。
# サーバー側(外部VPS)
git clone https://github.com/x011/smtp-tunnel-proxy.git
cd smtp-tunnel-proxy
python3 server.py --port 25 --target-host localhost --target-port 22
# クライアント側(DPIファイアウォール内)
python3 client.py --server vpn.example.com --server-port 25 --local-port 2222
クライアント側で ssh -p 2222 localhost を実行すると、トラフィックがSMTPに偽装されてファイアウォールを通過し、外部VPSのSSHサーバーに接続されます。
結果(After)
検証結果は以下の通りでした。
- DPIバイパス:Suricataの標準ルールではsmtp-tunnel-proxyを検知できず、通信が成立
- 帯域幅:Base64エンコードにより約33%のオーバーヘッドが発生
- レイテンシ:SMTPのハンドシェイクにより、初回接続に約200ms追加
SSHトンネルやOpenVPNは即座にブロックされましたが、SMTP偽装は検知されませんでした。Goで実装するヘッドレスワークフローエンジンで解説したアーキテクチャ設計と同様に、プロトコルの選択が重要であることが分かります。



検知・対策のアプローチ
smtp-tunnel-proxyのような隠密通信を検知するために、セキュリティエンジニアが取るべきアプローチを整理します。
異常検知ベースのアプローチ
SMTPトラフィックの「正常な振る舞い」から逸脱するパターンを検知します。
- メールサイズの異常:通常のメールと比較して異常に大きいペイロード
- 送信頻度の異常:同一サーバーへの高頻度なSMTP接続
- 宛先の異常:社外の未知のSMTPサーバーへの接続
ペイロード解析によるアプローチ
SMTP本文の内容を解析し、Base64デコード後のデータパターンを検査します。
# メール本文のエントロピー計算(異常なバイナリデータを検知)
import math
from collections import Counter
def calculate_entropy(data: bytes) -> float:
if not data:
return 0.0
counter = Counter(data)
length = len(data)
return -sum((count/length) * math.log2(count/length) for count in counter.values())
# 通常のテキストメール: エントロピー約4.5
# バイナリトンネルデータ: エントロピー約7.5以上
ネットワークフローベースのアプローチ
SMTPセッションの時間的特性を分析します。Ghosttyで開発効率を上げるで触れたように、ツールの挙動を理解することが対策の第一歩です。
- セッション持続時間:通常のメール送信は短時間で完了するが、トンネルは長時間接続を維持
- 双方向通信パターン:通常のSMTPは一方向だが、トンネルは頻繁に双方向通信が発生
さらなる年収アップやキャリアアップを目指すなら、ハイクラス向けの求人に特化した以下のサービスがおすすめです。
| 比較項目 | TechGo | レバテックダイレクト | ビズリーチ |
|---|---|---|---|
| 年収レンジ | 800万〜1,500万円ハイクラス特化 | 600万〜1,000万円IT専門スカウト | 700万〜2,000万円全業界・管理職含む |
| 技術スタック | モダン環境中心 | Web系に強い | 企業によりバラバラ |
| リモート率 | フルリモート前提多数 | 条件検索可能 | 原則出社も多い |
| おすすめ度 | 技術で稼ぐならここ | A受身で探すなら | Bマネジメント層向け |
| 公式サイト | 無料登録する | - | - |



まとめ
smtp-tunnel-proxyは、SMTPプロトコルを悪用してDPIファイアウォールを回避する高度なツールです。本記事のポイントを振り返ります。
- DPIの限界:正規プロトコルに偽装されると、標準的なDPIルールでは検知が困難
- SMTP偽装の仕組み:Base64エンコードされたTCPデータをメール本文に埋め込む
- 検知アプローチ:異常検知・ペイロード解析・フロー分析の組み合わせが有効
- 防御の心構え:攻撃者のツールを理解することが、効果的な対策設計の第一歩
セキュリティは終わりのない攻防です。新しい手法が登場したら、その仕組みを理解し、検知・対策を設計する。このサイクルを回し続けることが、セキュリティエンジニアの価値を高めていきます。













