Secure Shell
| TCP/IP群 | |
|---|---|
| アプリケーション層 | |
|
BGP / DHCP / DNS / FTP / HTTP / IMAP / IRC / LDAP / MGCP / NNTP / NTP / POP / RIP / RPC / RTP / SIP / SMTP / SNMP / SSH / Telnet / TFTP / TLS/SSL / XMPP カテゴリ |
|
| トランスポート層 | |
|
TCP / UDP / DCCP / SCTP / RSVP / ECN カテゴリ |
|
| ネットワーク層 | |
|
IP (IPv4, IPv6) / ICMP / ICMPv6 / IGMP / IPsec カテゴリ |
|
| リンク層 | |
|
ARP/InARP / NDP / OSPF / トンネリング (L2TP) / PPP / MAC (イーサネット, IEEE 802.11, DSL, ISDN, FDDI) カテゴリ |
Secure Shell（セキュアシェル、SSH）は、暗号や認証の技術を利用して、安全にリモートコンピュータと通信するためのプロトコル。パスワードなどの認証部分を含むすべてのネットワーク上の通信が暗号化される。
目次 |
[編集] 概要
Secure Shell は、そもそもTelnetやrsh、rloginなどといった、リモートホストのシェルを利用するための既存のプロトコルを代用する手段として考えられていた。TelnetやFTPは、ネットワーク上に平文でパスワードを送信してしまうため、パスワードをネットワーク経路上でのぞき見されてしまう（これを盗聴と呼ぶ）危険性が高く、商業的なインターネット空間では問題が大きかった。Telnet同様に、リモートホスト間でのファイルコピー用のコマンドrcpを代用するscpや、FTPを代用するためのsftpも用意されている。
SSHの暗号通信は、公開鍵暗号（RSAやDSA）を用いて共通鍵暗号（トリプルDES、AESなど）の共通鍵を暗号化して鍵交換を行い、通信自体は高速な共通鍵暗号を用いる、いわゆるハイブリッド暗号である。また、なりすましを防止するための認証の仕組みも充実している。パスワード認証、公開鍵認証、ワンタイムパスワードなどが提供されており、個々の情報セキュリティポリシーに合わせて選択できる。
現在は、バージョン1とバージョン2の2種類のプロトコルが共存している。脆弱性が発見されているため、バージョン1の利用は推奨されない。商用アプリケーションやフリーソフトウェアなど幾つかの実装があり、特許や互換性の問題などでやや混乱があったが、2006年にSSHのプロトコルおよびその関連技術がRFCとして制定された[1]。ただ、2008年の時点でもっとも一般に普及しているのは、オープンソースで開発されているOpenSSHで[2]、Linuxなどでも標準的に利用されているため、現在では単にSSHと言った場合、OpenSSHの実装系を指すことが多い。
[編集] SSHサーバ
- OpenSSH (マルチプラットフォーム)
- SSH Tectia Server (マルチプラットフォーム)
- Reflection for Secure IT (マルチプラットフォーム)
[編集] SSHクライアント
- OpenSSH (マルチプラットフォーム)
- PuTTY (Windows, UNIX)
- Tera Term (Windows)
- Poderosa (Windows)
- SSH Tectia Client (マルチプラットフォーム)
- Reflection for Secure IT (マルチプラットフォーム)
[編集] SSHのセキュリティリスク
SSHクライアントの利用者がサーバ鍵の指紋を確認しない場合、意図しないリモートコンピュータに接続していても気づかず、通信内容を盗聴される恐れがある。
また、SSHサーバには、設定値が適切でないために発生するセキュリティリスクがある。一例として、OpenSSHにおける以下のような設定があげられる。
- PasswordAuthenticationが既定で有効である
- PermitRootLoginが既定で有効である
- Protocolが既定でssh1を許可している
- 既定のPortが22で既知である
- ChallengeResponseAuthenticationが既定で有効である
- AllowUsersにおいて既定ですべてのユーザーに許可されている
- 認証にたびたび失敗するホストからの接続を制限しない
- 認証に失敗しても再認証を受け入れるまでウエイト時間を設けない
- 既定ではないが、X11 port forwardingが有効にできる
- 認証が通るとシェルへのアクセスが認められる
これらの状態では、たとえばブルートフォースアタックでセキュリティを突破することが可能である。実際にセキュリティを破られたサーバが存在し、IPAではこの問題について危険性があることを勧告している。
OpenSSHを採用しているサーバOSの中には、上記の値をデフォルト値としていないものもある。しかし、デフォルトのsshd_configに対してなんら対策を施していない場合、非常に多くの情報が既知である。攻撃者はパスワードを見つけることだけに専念してセキュリティを破り、またスーパーユーザー特権を獲得することができる。
この問題に対してのソリューションは、SSHサーバの設定のデフォルト値には危険なものがあることを認識して対策することである。
- PasswordAuthentication noにする
- PermitRootLogin noにする
- Protocol 2にする
- Portは22以外にする
- ChallengeResponseAuthentication noにする
- AllowUsersにおいて特定のユーザーのみ接続を許可する
- authlogなどで認証失敗を検出したら、そのホストからの接続を遮断する
- X11 port forwardingは無効にする
- シェルが不要であれば、passwdファイルからシェルを取り除く
[編集] 脚注
- ^ RFC 4250、RFC 4251、RFC 4252、RFC 4253、RFC 4254、RFC 4255、RFC 4256を参照。
- ^ “Statistics from the current scan results”. 2009年3月8日閲覧。
