telnet

遠隔端末プロトコルと、任意TCPポートへの簡易試験通信を別の用途として理解する平文盗聴、SSHトンネル、接続成立とアプリケーション成功、TLS保護サービスを分ける

二つの使われ方を分ける

NVTと選択肢交渉

端末ごとに改行、echo、文字コード、画面制御が異なるため、Telnetは共通のNVTデータ表現を基準にします。双方は特別な制御バイトで、echo、端末種類、時間窓大きさ等の選択肢を提案・受諾・拒否します。

したがってTelnetは「TCPへ文字を流すだけ」の仕様ではありません。バイナリーデータ中に制御バイトと同じ値が現れる場合のエスケープ等もあり、任意バイナリープロトコルを手動試験するツールには向きません。

暗号化も強い相手認証もない

標準Telnetセッションは平文で、同じLAN、Wi-Fi、途中ネットワーク、侵害されたルーター等から内容を読まれ、書き換えられる可能性があります。パスワードログインでも、パスワード自体が保護されません。

SSHは暗号化、サーバーホスト鍵による確認、完全性保護を提供します。古い機器がTelnetしか持たない場合は、隔離管理ネットワーク、物理アクセス制限、短期間だけの有効化、ファームウェア更新・機器更新を検討します。

TCPポート確認として分かること

指定したホスト・ポートへ接続できれば、名前解決、そこまでの経路、TCPのthree-way handshake（スリーウェイ・ハンドシェイク）、サーバー側の待ち受け、途中のフィルターについて、少なくともその試行に必要な部分は通ったと分かります。

接続refusedなら宛先ホストから拒否応答が届いた可能性、タイムアウトならパケット損失、ファイアウォール破棄、誤アドレス、戻り値パス不良等が候補です。メッセージはクライアント実装とOSで違い、原因を一意に決めません。

接続成立はサービス成功ではない

待受けプロセスが接続を受け入れた後でも、アプリケーションプロトコルのエラー、認証失敗、バックエンド停止、リソース不足で処理できない場合があります。接続時の案内メッセージが返っても、その後のコマンドが成功するとは限りません。

負荷分散装置やプロキシへ接続している場合、奥のサーバーまで達したとも限りません。目的プロトコルのクライアント、アプリケーションヘルスチェック、サーバーログを組み合わせます。

テキストプロトコルは慎重に会話する

SMTP、POP3、IMAP、HTTPの平文ポート等は、プロトコル構文を知れば手入力で応答を観察できます。ただし改行形式、タイムアウト、状態順序、データterminatorを誤ると正しいサービスでもエラーになります。

本番環境サーバーへメール送信・データ変更コマンドを送らないよう、読み取り専用な挨拶と終了手順だけにします。入力したトークンやメール内容が端末履歴・recordingへ残る点にも注意します。

TLSサービスにはTLSクライアントを使う

HTTPS、SMTPS、IMAPS等へtelnetクライアントで接続するとTCPまでは成立しても、その後はTLSハンドシェイクのバイナリーメッセージが必要です。文字でHTTP要求を送っても通常の応答は得られません。

OpenSSL s_クライアントならSNI、証明書連鎖、プロトコルバージョン、暗号スイートを確認でき、curlならTLS後のHTTPまで確認できます。STARTTLS型サービスも、平文開始後にTLSへ切り替える専用クライアントを使います。

Telnetは平文の遠隔端末プロトコルで、クライアントコマンドはTCP接続の簡易試験通信にも使われます。本来用途と診断用途を分け、接続成立、アプリケーション応答、TLS、認証を別段階として確認します。

TelnetのNVT、双方向byte通信、option negotiation：RFC 854「TELNET Protocol Specification」