TelnetのセキュリティリスクとSSH移行ガイド｜平文通信が招く危険と現場での廃止手順

「まあ社内ネットワークだから大丈夫だろう」と、ルーターや古いLinuxサーバーへのアクセスにTelnetを使い続けていませんか。JPCERT/CCの定点観測レポート（2026年1～3月）では、TCP 23番ポート（Telnet）への探索パケットが国内で観測件数の1位を記録しています。攻撃者が今もTelnetを狙い続ける理由は単純です。「パスワードが平文で流れるから、盗聴するだけで認証情報が手に入る」からです。

この記事では、Telnetが抱えるセキュリティリスクを攻撃者の視点から整理し、SSHへの移行手順を現場で使えるレベルで解説します。Linuxサーバー・Windowsサーバーから、ネットワーク機器のCLIアクセスまでカバーします。

Telnetとは？なぜ今も残っているのか

Telnet（テルネット）は、TCP 23番ポートを使ってリモートマシンにコマンドラインで接続するプロトコルです。1969年に策定された歴史的なプロトコルで、インターネット黎明期のネットワーク管理の要でした。

しかし、Telnetには決定的な欠陥があります。通信内容をいっさい暗号化しないことです。ユーザー名・パスワード・コマンド・レスポンスのすべてが、ネットワーク上を平文（人間が読める状態）で流れます。

それでも2026年現在、Telnetが使われ続けている場面があります。
・レガシーネットワーク機器: 旧型のルーター・スイッチ・UTMがSSHを非対応、またはデフォルトでTelnetが有効なまま放置されている
・OT/制御システム: 製造ラインや設備制御に使う機器がTelnetしか対応していない
・テスト・開発環境: 「社内だから」とセキュリティを後回しにした環境がそのまま本番に移行している
・古いNASやIoT機器: ファームウェアが更新されず、Telnetが有効なままインターネットに接続されている

攻撃者から見たTelnetの危険性

1. 平文通信による認証情報の盗聴

Telnetの最大のリスクは、同一ネットワーク上の第三者がパケットキャプチャツールを使うだけで、ユーザー名とパスワードを取得できることです。

Wiresharkなどで23番ポートのパケットをフィルタリングすると、管理者がキーボードで入力した文字が1文字ずつパケットに現れます。実際の認証情報を読み取るのに、特別なスキルや道具は不要です。同一セグメントに接続できる環境さえあれば誰でも実行できます。

ARP スプーフィングや Evil Twin 攻撃でネットワークに「中間者」が侵入した場合も同様です。VLANで分離しているつもりでも、スイッチの設定ミスや物理的な接続点があれば突破される可能性があります。

2. セッションハイジャック

Telnetは認証後のセッションも暗号化しません。攻撃者は接続中のセッションを乗っ取り、管理者が操作しているサーバーに任意のコマンドを送り込むことができます。「接続さえ張られれば途中から参加できる」のがTelnetの構造的な脆弱性です。

3. 自動スキャンと辞書攻撃の常時標的

インターネット接続側でTelnetポートが開いていれば、Shodan・ZoomEye・Masscanなどの探索ツールに数分以内に検出されます。その後は自動化された辞書攻撃が24時間365日、途切れることなく試行を続けます。

JPCERT/CCの定点観測では、TCP 23番への探索は日本国内でも長年にわたり観測上位に位置しています。攻撃者のスクリプトは「Telnetが開いていたら認証情報を試す」をほぼ自動で実行します。デフォルトパスワードを変更していなければ、侵害まで数分かかりません。

4. 機器のデフォルト認証情報との組み合わせ

IoT機器・ルーター・NASのデフォルトパスワード（admin/admin、root/root、password など）はデータベース化されており、Telnetと組み合わせた自動攻撃に使われています。2016年に猛威を振るったMiraiボットネットは、まさにこの手口でTelnetポートを持つカメラやルーターを大量に感染させ、史上最大規模のDDoSインフラを構築しました。

Telnetが残っているかを確認する方法

まず自社環境のTelnetサービス稼働状況を確認します。

# Linuxサーバー上で23番ポートを待ち受けているプロセスを確認
ss -tlnp | grep :23

# inetd/xinetd経由のtelnetサービス確認
systemctl status telnet.socket
systemctl status xinetd

# telnetdパッケージのインストール有無
rpm -q telnet-server     # RHEL/CentOS/AlmaLinux
dpkg -l | grep telnetd   # Ubuntu/Debian

# ネットワーク機器の棚卸し（内部からのポートスキャン）
nmap -p 23 192.168.0.0/24 --open

ネットワーク機器（ルーター・スイッチ）側は、機器のCLIにログインして確認します。Cisco IOSの例：

# 現在の設定確認
show ip ssh
show running-config | include telnet|transport input
# line vty の transport input が "telnet" または "all" になっていれば要対処

SSH移行の具体的な手順

1. 環境の棚卸しと優先度付け

移行対象を洗い出したら、インターネット側に露出しているもの→社内でも多くのユーザーが使うもの→隔離された検証環境の順で優先度を付けます。影響範囲が広いものから手を付けることで、リスクの高いものを早期に塞げます。

2. LinuxサーバーのTelnet廃止とSSH移行

# telnetdの停止と無効化（systemd環境）
sudo systemctl stop telnet.socket
sudo systemctl disable telnet.socket

# xinetd経由の場合
sudo systemctl stop xinetd
# /etc/xinetd.d/telnet の disable = yes に変更してから再起動

# telnet-serverパッケージを削除（RHEL系）
sudo dnf remove telnet-server

# SSHサービスの起動・自動起動設定
sudo systemctl enable --now sshd

# ファイアウォールでTelnetポートを閉じる
sudo firewall-cmd --remove-port=23/tcp --permanent
sudo firewall-cmd --reload

# 移行後の確認：23番が開いていないことを検証
ss -tlnp | grep :23  # 何も表示されなければOK

SSHの詳細な設定（鍵認証・ポート変更・rootログイン禁止）については、Linuxのsshd_config設定完全ガイドを参照してください。

3. ネットワーク機器のSSH移行（Cisco IOS の例）

# SSHを有効化するために必要な設定
ip domain-name example.local
crypto key generate rsa modulus 2048
ip ssh version 2

# VTY回線でSSHのみ許可（Telnetを無効化）
line vty 0 4
 transport input ssh
 login local

# ユーザー認証の設定（パスワードのみの認証は避ける）
username admin privilege 15 secret StrongPass123!

# Telnetが無効化されたか確認
show ip ssh
show running-config | section line vty

4. WindowsサーバーのTelnet廃止

Windows Server でTelnetサーバー機能（オプション機能として提供）を有効にしている場合は、以下で無効化します。

# PowerShellでTelnetサーバー機能の確認
Get-WindowsFeature -Name Telnet-Server

# 無効化
Remove-WindowsFeature -Name Telnet-Server

# Windowsファイアウォールで23番を閉じる
New-NetFirewallRule -DisplayName "Block Telnet" `
  -Direction Inbound -Protocol TCP -LocalPort 23 `
  -Action Block

WindowsへのリモートアクセスはOpenSSH（Windows Server 2019以降で標準提供）または RDP（適切なVPN・IP制限下で）に移行してください。

SSHへの移行が難しい場合の暫定対策

一部のレガシー機器や制御システムでは、すぐにSSH移行ができない場面もあります。その場合の暫定措置を示します。

・ネットワーク分離: Telnetが動く機器を専用の管理用VLANに閉じ込め、管理端末からのみアクセス可能にする
・ファイアウォールでソースIPを制限: 23番ポートへのアクセスを特定の管理端末IPのみに絞る
・インターネットからの疎通を遮断: 最低限、外部（インターネット）からTCP 23番に到達できないことを確認する
・接続ログの監視: Telnetへの接続試行を記録し、異常なアクセスを早期に発見する

ただし、これらはあくまでも暫定措置です。平文通信のリスクそのものは残ります。SSHへの移行計画を立て、期限を決めて廃止することを強くお勧めします。

ネットワーク機器全体のハードニングについては、ネットワーク機器のハードニング実践ガイドも参照してください。

よくある誤解と注意点

「社内LANだから盗聴されない」は誤り
同一ネットワークにある端末がマルウェアに感染していれば、その端末がパケットキャプチャの起点になります。また、内部不正のリスクも考えると、社内であっても暗号化通信は必須です。

「VPNを使っているから安全」も過信は禁物
VPN内部でTelnetを使っていれば、VPNトンネルの内側は暗号化されますが、VPN終端からサーバーまでの区間が平文のままです。SSHはエンドツーエンドで暗号化するため、VPNとSSHは用途が異なります。

「Telnetクライアントを削除すれば良い」は不十分
クライアント側の削除はサーバー側に影響しません。Telnetのリスクはサーバー（待ち受け側）のサービスにあります。サーバー側のTelnetサービスを停止・削除しなければ意味がありません。

SSH鍵認証への移行も同時に検討する
SSHに移行しても、パスワード認証のままでは辞書攻撃のリスクが残ります。SSH鍵認証の設定とあわせて、パスワードのみの認証を無効化することを推奨します。

Linuxサーバーのセキュリティ管理全般については、姉妹サイトLinuxMaster.JPでも実践的な設定手順を詳しく解説しています。

本記事のまとめ

Telnetのリスクは「古くから知られている」だけに軽視されがちですが、実際の攻撃者は今この瞬間も23番ポートを探し続けています。「後でやろう」ではなく、今日の棚卸しから始めてください。まず ss -tlnp | grep :23 と nmap -p 23 <社内セグメント> --open を実行し、Telnetが動いているサーバーや機器を把握することが第一歩です。