SSHのセキュリテイ対策

SSHのセキュリテイ設定

新しいPCで、raspberry piに対してsshを行おうと思っています。
秘密鍵を作成する以外にセキュリティ面でsshをする前に行っておいた方がいいことはありますでしょうか？

scsi

2019/01/24 10:41

新しいpcに対する設定なのかラズパイに対する設定なのか、両方なのか、また、ラズパイに対することならsshログイン後に設定した方が楽だと思います。

Stan_Dma

2019/01/26 11:09

Best practice concerning security is to stop unnecessary services as much as possible.

行動規範の内容に同意します

回答1件

ベストアンサー

設定方法はサーバーやクライアントのソフトウェアやバージョンおよびOSや状況によって異なりますので具体的な方法は書けません。サーバーの場合は[S]、クライアントの場合は[C]、両方の場合は[SC]と表記します。

レベル0

対応が必須である設定です。

[SC] SSHバージョン1を無効にする。

SSHのプロトコルにはバージョン1とバージョン2の二つのバージョンがあります。バージョン1は脆弱性が発見されていますので、使用してはいけません。最新のソフトウェアであれば、バージョン1はデフォルトで無効にされていますが、絶対ではありません。

[SC] 最新バージョンのソフトウェア(または最新リビジョンのパッケージ)を使用する。

どんなに安全な設定を行っていても、ソフトウェア自身に脆弱性があれば意味がありません。古いバージョンのソフトウェアや現在保守されていないソフトウェアを使用してはいけません。

レベル1

対応しておくべき設定です。

[S] rootログインを制限する。

直接rootでログインできないようにします。しかし、システムの設計や運用上、どうしても直接rootログインが必要な場合があります。その場合はrootでのログインに対して次のように設定してください。

パスワードを用いたログインを禁止し、鍵交換のみに制限する。
ログイン時に実行可能なコマンドを特定のコマンドのみに制限する。可能なコマンドは鍵ファイル毎に設定する。
SCP/SFTP/シェル実行は禁止する。

[S] 接続可能なIPアドレスを制限する。

SSHを管理用に用いるのであれば、必要最低限のIPアドレスやネットワークのみ接続できるようにしてください。特に、インターネットに公開する場合は必須です。

利用者向けであるため制限が出来ない事もあるかも知れません。その場合はレベル2以降の設定を行って、セキュリティを高めてください。

[S] ログインできるユーザーを制限する。

サーバーにはログインして使用するユーザー以外のユーザー(サービス起動用等)も作成されています。SSHを使用する必要が無ければ、それらのユーザーがSSHでログインできないように設定してください。管理用であれば、管理者以外は禁止してください。

[S] サーバーの鍵を使い回さない。

サーバーをクローンした場合、サーバーの鍵をそのままにしている場合があります。クローン後は必ず鍵を再生成してください。同じ鍵を使用すると、一つのサーバーが乗っ取られただけで、全てのサーバーのSSH通信が盗み見られる危険性があります。

[C] クライアントの鍵を使い回さない。

クライアントの鍵もクライアント毎に作成し、必要に応じて登録してください。同じ鍵を使用すると、鍵が漏洩した場合、どのクライアントから漏れたのかがわからなくなります。

レベル2

対応しておいた方が良い設定です。

[S] ログインを鍵交換のみに制限する。

パスワードを用いたログインを禁止、ログインを鍵交換のみに制限します。

運用上、パスワードでのログインを禁止できない場合は、ブルートフォース攻撃などへの対策を行うようにします。

[SC] 安全では無い暗号アルゴリズムを無効にする。

脆弱性がみつかっている、または、bit数が少なくて安全ではないとされる暗号があります。暗号にも種類がありますので、注意してください。次はよく知られた脆弱であるとされるアルゴリズムです。これらのアルゴリズムは無効化しておきます。

暗号: RC4(ARCFOUR)、DES、3DES
ハッシュ: MD5、SHA1
公開鍵: RSA 1024bits以下

古い暗号アルゴリズムを無効にすると古いサーバーやクライアントで通信できなくなる場合があります。

[SC]公開鍵にRSAを使用する場合は、2048bits以上にする。

RSA 1024bitsは、bit数が少なく、安全ではありません。RSAは2048bits以上にしてください。

[S] X11 ForwardingやTCP Forwardingを無効にする。

必要で無ければ、SSHのトンネルを用いるX11通信やTCP通信を無効にしてください。サーバーの管理用であれば、これらが必要になることはほとんどありません。X環境が入ったクライアントへのログインや内部ネットワークへの踏み代に用いる場合は、この限りではありません。

レベル3

対応はオプションです。より安全になりますが、利便性とのトレードオフになります。

[SC] 公開鍵に楕円曲線暗号を用いる。

RSAより安全だと考えられている楕円曲線暗号を用いてください。現在、使える楕円曲線暗号は次の4つです。

ECDSA 256bits, ECDSA 384bits, ECDSA 521bits, Ed25519

Ed25519はバックドアの懸念が無く、安全と言われています。古いソフトウェアは対応していない場合がありますので、注意が必要です。

[S] SCP/SFTPのみに制限する、または、制限シェルを用いる。

Webサーバーのアップロード用などの利用者向けに公開している場合は、設定しておいた方が良い設定です。SCP/SFTPでファイルのアップロードしか使わせないのであれば、汎用シェルを用意する必要はありません。シェルを用意するにも、何でもコマンドを可能にするより、制限を掛けておくとより安全性が増します。

[S] チェンジルートを設定する。

Webサーバーのアップロード用などの利用者向けに公開している場合は、設定しておいた方が良い設定です。アップロード目的のSCP/SFTPのみに制限している場合は、設定しても問題ありません。しかし、汎用シェルが使える状態でチェンジルートを行うと、色々使えないコマンドがある等の利便性が落ちますので、注意が必要です。。

なお、管理者向けには設定してはいけません。sudoを用いてrootになっても一度チェンジルートした環境から抜け出す方法はありません。

[S] ポート番号を変える。

インターネット上に公開されているサーバーに対して、22番ポートは様々なところから常にスキャンされています。22番ポートに接続可能である場合、SSHログインが可能かも知れないサーバーであるとダークネット上のリストに追加され、ハッカーに攻撃される危険性が増加します。

IPアドレスを制限している場合や、ローカルネットワークにしか公開していない場合は、それほど意味がある設定ではありません。

投稿2019/01/26 11:45

編集2019/01/29 09:14

raccy

総合スコア21735

YK13

2019/01/29 03:37

手馴れておらず、あまりにブロードな質問に対して非常に徹底的に答えていただき、誠にありがとうございます。実践してみようかと思います！｀

doda

2019/01/29 05:44

・ECDSA 254bits ⇒ 256bits ・Ed25591 ⇒ Ed25519 ・「Ed25591が最もbit数が多く」⇒ Ed25519 は256bitなので間違いよく「ECDSAよりはEd25519の方が安全」と言われるのは、「現時点での通常の用途では十分な鍵長がある」と「ECDSAは使用する楕円曲線を策定したNISTによるバックドアの存在が懸念されている。Ed25519にはそれがない」という事からですね。