SSH脆弱性の歴史と対策｜過去の事例から学ぶ安全なSSH運用
KoAN
目次
SSH脆弱性の歴史を知り安全な運用に活かそう
SSH（Secure Shell）はLinuxやUNIXサーバ管理に欠かせないリモートアクセス技術です。
暗号化通信によって安全な管理を実現できるため、現在ではTelnetに代わる標準的な管理手段となっています。
しかしSSHは万能ではありません。
長い歴史の中で複数の脆弱性が発見され、そのたびに対策や改善が行われてきました。
実際の脆弱性事例を知ることで、なぜ現在のSSH設定が推奨されているのか理解しやすくなります。
本記事ではSSHの歴史的な脆弱性と、その対策について解説します。
SSHが誕生した背景
SSHが登場する以前はTelnetが広く利用されていました。
しかしTelnetには大きな問題がありました。
通信内容が平文で送信されるためです。
ユーザー名やパスワードも暗号化されません。
盗聴されると簡単に認証情報が漏洩してしまいました。
SSH-1の登場
1995年にSSH-1が公開されました。
SSH-1は通信の暗号化を実現し、大きな注目を集めました。
しかし後に設計上の問題が指摘されます。
SSH-1の脆弱性
SSH-1には複数のセキュリティ上の問題がありました。
- 認証方式の弱点
- 暗号アルゴリズムの問題
- プロトコル設計上の欠陥
現在では利用すべきではありません。
SSH-2への移行
SSH-1の問題を解決するためにSSH-2が開発されました。
現在利用されているSSHは基本的にSSH-2です。
OpenSSHでもSSH-1は既にサポート対象外となっています。
CRC32 Compensation Attack
SSH-1で有名な脆弱性の一つです。
1998年頃に報告されました。
細工したパケットによってリモートコード実行の可能性が指摘されました。
SSH-1が廃れた理由の一つです。
SSH-1無効化の確認
現在のOpenSSHでは以下の設定が推奨されます。
Protocol 2最近のOpenSSHではSSH-2のみ対応となっています。
弱い暗号アルゴリズムの問題
SSHそのものではなく、利用する暗号方式に問題が見つかることがあります。
代表例です。
- MD5
- SHA1
- DSA
- 3DES
現在は非推奨となっています。
SHA1の衝突問題
SHA1は長年利用されていましたが、衝突攻撃の現実性が高まりました。
そのため現在はSHA2系への移行が進んでいます。
SSHでも同様です。
DSA鍵の非推奨化
DSA（ssh-dss）は古くから利用されていました。
しかし鍵長の制限などの問題から非推奨になりました。
OpenSSHではデフォルト無効です。
Logjam攻撃
2015年に注目された脆弱性です。
Diffie-Hellman鍵交換の弱いグループが問題となりました。
SSHにも影響がありました。
現在は安全な鍵交換方式が利用されています。
推奨される鍵交換方式
現在は以下が推奨されています。
curve25519-sha256OpenSSHでも標準的に利用されています。
Terrapin攻撃
2023年に公開されたSSH関連の脆弱性です。
SSH接続初期段階における通信操作が問題となりました。
主にChaCha20-Poly1305やCBC系暗号との組み合わせで影響が指摘されました。
OpenSSH側で修正対応が行われています。
OpenSSHの脆弱性事例
OpenSSH自体にも過去に脆弱性が存在しました。
代表例です。
- 権限昇格
- 認証回避
- メモリ管理問題
- DoS攻撃
そのため定期的なアップデートが重要です。
Heartbleedとの違い
SSHと混同されることがあります。
HeartbleedはOpenSSLの脆弱性です。
SSHそのものの脆弱性ではありません。
ただしSSHでOpenSSLを利用していた環境では影響を受けました。
古いOpenSSHを利用する危険性
古いOpenSSHには既知の脆弱性が残っている可能性があります。
そのため以下が重要です。
- OS更新
- OpenSSH更新
- セキュリティパッチ適用
最も基本的な対策です。
脆弱性情報を確認する方法
OpenSSHのバージョン確認です。
# ssh -V
サーバ側です。
# sshd -V環境によって表示方法が異なります。
利用中の暗号方式を確認する
現在利用可能な暗号方式です。
# ssh -Q cipher
鍵交換方式です。
# ssh -Q kex古い方式が残っていないか確認しましょう。
脆弱性対策として推奨される設定
以下の設定が一般的です。
- SSH-2のみ利用
- ED25519鍵利用
- 公開鍵認証
- rootログイン禁止
- パスワード認証無効
現在の標準的な構成です。
Fail2banとの組み合わせ
脆弱性対策とは少し異なりますが、防御層として有効です。
攻撃者のアクセス試行を自動遮断できます。
実務ではよく利用されています。
MFAの導入
認証強化のためにMFAも推奨されます。
例えば以下です。
- 公開鍵認証
- Google Authenticator
- OTP認証
認証情報漏洩への耐性が向上します。
企業環境で重要な考え方
脆弱性を完全にゼロにすることはできません。
そのため以下が重要です。
- 最新化
- 監視
- ログ確認
- 多層防御
継続的な運用が求められます。
セキュリティ監査で確認される項目
- OpenSSHバージョン
- 古い暗号方式の利用有無
- SSH-1利用有無
- 公開鍵認証利用状況
- パッチ適用状況
企業環境では重要な監査項目です。
実務で推奨される構成
PermitRootLogin no
PasswordAuthentication no
PubkeyAuthentication yesさらにED25519やMFAを組み合わせることで安全性を向上できます。
まとめ
SSHは非常に安全なプロトコルですが、長い歴史の中で複数の脆弱性が発見されてきました。
SSH-1の廃止、SHA1やDSAの非推奨化、Terrapin攻撃への対応などを通じて、現在のSSHは大きく進化しています。
最も重要な対策はOpenSSHを最新状態に保ち、推奨される暗号方式や認証方式を利用することです。
過去の脆弱性事例を知ることで、安全なSSH運用を実現できるようになるでしょう。
