【実務・中級編】 SSHポートフォワーディングの制限 – インフラ・ネットワーク & クラウドセキュリティ防御ガイド

エンジニア諸君、日々お疲れ様。本番環境の構築で「SSH接続さえ許可していれば、鍵認証だし大丈夫だろう」と高を括っていないだろうか。

確かにSSHは強固だ。だが、攻撃者はその「強固なトンネル」を逆手に取る。今日は、実務において最も見落とされがちだが、侵入された後の被害を最小化するために不可欠な「SSHポートフォワーディングの制限」について、現場の泥臭い話を交えて解説しよう。

SSHのポートフォワーディング（トンネリング）は、本来便利な機能だ。ローカルのPCから、直接アクセスできない内部ネットワークのDBや管理画面を、SSH越しに操作できる。

しかし、攻撃者が一度でもサーバーに侵入（低権限のWebシェル実行や漏洩した鍵によるログイン）に成功した場合、この機能は「内部ネットワークへの侵入用ブリッジ」に変わる。

攻撃者は、侵入したWebサーバーを足掛かりに、内部の閉域網にある監視システムや開発用DBへアクセスを試みる。
攻撃者が行うコマンドはシンプルだ。

# 攻撃者が侵入先サーバーで実行するコマンド
# 内部DB(192.168.1.50:3306)を、攻撃者の手元(127.0.0.1:9999)へ転送させる
ssh -L 9999:192.168.1.50:3306 -N -f user@compromised-server

このコマンドが成功すれば、攻撃者は自分の手元のPCから、あたかも内部ネットワークにいるかのようにDBへ総当たり攻撃をかけられる。ファイアウォールの「外向き通信は許可」という甘いルールを突破する、最も古典的かつ強力な手法だ。

この攻撃を物理的に遮断する、最も確実でコストのかからない方法が、SSHの設定ファイルである /etc/ssh/sshd_config に以下の設定を加えることだ。

# /etc/ssh/sshd_config の設定
# サーバー全体でポートフォワーディングを禁止する
AllowTcpForwarding no

# 関連機能も念のため無効化
X11Forwarding no
PermitTunnel no

設定を反映したら、必ず sshd -t で構文チェックを行い、systemctl restart sshd で再起動しよう。これだけで、攻撃者がどれだけ頑張ってもSSHトンネルを構築できなくなる。

「いや、管理者はどうしてもトンネルが必要なんだ」というケースもあるだろう。その場合は、Match ブロックを使って「特定のユーザーやグループだけ」許可する、あるいは「特定のIPからだけ」許可するという粒度で制限をかけるのが、プロのエンジニアの流儀だ。

以下は、admin グループのみにフォワーディングを許可する設定例だ。

# 特定のグループのみフォワーディングを許可する設定例
AllowTcpForwarding no

Match Group admin
    AllowTcpForwarding yes

単に設定を変えて終わり、では不十分だ。インシデントハンドリングの経験則から言うと、「そもそも踏み台にされないこと」が最も重要だ。

以下のチェックリストを、今日のデプロイ作業の合間に確認してほしい。

鍵管理の棚卸し: ~/.ssh/authorized_keys に放置された、退職したメンバーや古い開発端末の公開鍵は残っていないか？
認証ログの監視: /var/log/auth.log に Failed password や Accepted publickey が不自然に記録されていないか？
クラウドIAMの活用: AWS等であれば、SSH接続ではなく AWS Systems Manager (SSM) Session Manager の利用を強く推奨する。これなら、ポートフォワーディングを完全に無効化しつつ、監査ログをすべてCloudWatch Logsに残せる。

セキュリティの本質は「何ができるか」ではなく「何を禁止できるか」にある。AllowTcpForwarding no は、地味だが、攻撃者の「横方向への移動（Lateral Movement）」を確実に封じ込める強力な一手だ。

もし君がインフラを触る立場なら、明日、自分の管理するすべてのサーバーで grep "AllowTcpForwarding" /etc/ssh/sshd_config を実行してくれ。もし設定がなければ、それは「鍵の掛かっていない勝手口」があるのと同じだ。

さあ、今すぐ設定を修正し、盤石な要塞を作り上げよう。何かあればまた相談に乗る。健闘を祈る。