SSH。私たちはそれを知っています。私達はそれが大好き。使用する必要があります。
ネットワーク上でSSHサービスを保護するために、8つのステップを紹介します。 SSHの重要性は誰もが認めていると思います。これにより、Linuxデバイス、Unixサーバー、ネットワークアプライアンス、場合によってはWindowsボックスとの接続が可能になります。 SSHがどのくらいの頻度で使用されているか、またはSSHがどれほど重要であるかについては説明しません。ご使用の環境でSSHサービスがロックダウンされていることを確認するために使用できる確実なチェックリストを提供します。
1。構成ファイルをバックアップします
まず、大きな変更を加える前に、構成ファイルをバックアップします。これは一般的なアドバイスですが、実際のアドバイスです。それは簡単で、ほんの一瞬で、ファイルを編集するときに間違いがあった場合にあなたを保護します。そして、Vimで間違いを犯していないのは誰ですか？
# cp /etc/ssh/sshd_config ~/sshd_config_original ほら、それほど悪くはない。
課題-主要な編集を行う前に、構成ファイルを一貫してバックアップしていますか？
2。バナーメッセージを設定する
確かに、これは他の何よりも法的要件に関するものですが、繰り返しになりますが、この設定には少し時間がかかります。実際には、バナーメッセージでかなり良い情報を提供することもできます。まず、/etc/issue.netにバナーメッセージを書き込みます Vimを使用してファイルします。次に、sshd_configを開きます ファイルを作成し、issue.netのコンテンツを使用するように指示します バナーとして。
# vim /etc/issue.net
Warning! Authorized use only.
This server is the property of MyCompanyName.com [次のこともお勧めします：LinuxでのSSHパスワードの自動化とsshpass]
明らかに、あなたはあなたの組織に特有の何かを考え出したいと思うでしょう。すでにissue.netにある情報をすべて削除します ファイル。
次に、バナーメッセージを使用するようにSSHに指示します。 sshd_configを開きます Vimでファイルを作成し、バナーという行を見つけます。 。 Vimのコマンドモードでスラッシュ文字を使用してファイルをキーワード検索できることを覚えていますか？例：/banner
# vim /etc/ssh/sshd_config ＃デフォルトのバナーパスなしという行を見つけます 、次の行のコメントを解除します（バナーと表示されます） 。
# no default banner path
Banner /etc/issue.net ：wqを使用してVimに変更を保存します 次に、SSHサービスを再起動します：
# systemctl restart sshd 注：この時点からSSHを再起動するように通知するつもりはありません。構成ファイルに変更を加えるときはいつでも、サービスを再起動する必要があります。
課題-バナーメッセージはネットワーク上のすべてのSSHデバイスで一貫していますか？
3。空のパスワードを防ぐ
これは簡単なことのように思えますが、空のパスワードは明らかに悪い考えです。 Pluggable Authentication Modules（PAM）など、通常のパスワードを規制する他のユーティリティがある場合もありますが、SSHが責任あるセキュリティ設定を実施していることも確認することをお勧めします。
/etc/ssh/sshd_configを開きます Vimでファイルを作成し、 PermitEmptyPasswordsという行を見つけます。 。コメントを外し、はいを置き換えます いいえの値 。
PermitEmptyPasswords no それだけです。
4。 rootユーザーがSSH経由でネットワークを通過するのを防ぎます
ここでの考え方は非常に単純です。ルートクレデンシャルの代わりに、ネットワークを介して標準のユーザークレデンシャルを送信します。標準のユーザーアカウントを使用してSSH接続を確立したら、suを使用します またはsudo 特権を高めるため。
SSH構成ファイルを開き、 PermitRootLoginのコメントを解除します ライン。 はいから設定を編集します いいえ 。
PermitRootLogin no
課題-あなたの組織はsudoを採用しています 、そうですか？
5。特定のユーザーアカウントをホワイトリストに登録する
SSH全体でのrootユーザーアカウントの使用をすでに禁止している場合は、さらに一歩進んで、どのユーザーができるかを明示的に述べてください。 サーバーに接続しますか？おそらく、使用している通常の非root管理者アカウントを持っているか、sudoですでに構成されているアカウントを持っています。 特権。
SSH構成ファイルに、次の行を追加します（デフォルトではそこにはありません）：
AllowUsers user1 PermitRootLogin noの近くに置きます 設定。
ちなみに、実際には次のすべての設定でフィルタリングできます： AllowUsers 、 DenyUsers 、 AllowGroups 、 DenyGroups 。私は意図的にその順序でそれらを書きました—それはそれらが処理される順序です。詳細については、sshd_configのマニュアルページを参照してください。 。
課題-誰が許可されているかについて正確に注意してください。
注：iptablesを介して接続を制限することもできます。
6。ポート22はもうありません
もう1つの一般的な変更は、標準の 22 / tcpとは異なるポートでリッスンするようにSSHを構成することです。 私たち全員が覚えていること。 sshd_configにはすでにエントリがあります ファイル。
以下で行ったように、デフォルトのポート設定をコメントアウトして、別の行を追加できます。
#Run SSH on a non-standard port
#Port 22
Port 2222 多くの人が代わりのポート番号として2222を使用していると思われるので、もう少しユニークなものを標準化することをお勧めします。
この時点から、SSH接続の試行に新しい非標準のポート番号を追加することを忘れないでください。例：
# ssh -p 2222 [email protected] 課題-すべてのSSH宛先に同じ非標準のポート番号を設定していますか？一貫性はあなたの人生をはるかに楽にします。
7。時間切れです！
次のヒントでは、接続のタイムアウトについて説明します。 ClientAliveInterval アイドル状態のSSH接続を管理します。サーバーはクライアントにメッセージを送信し、応答を期待します。 ClientAliveInterval メッセージ間の時間のスペースです。 ClientAliveCountMax クライアントが実際にはもう存在しないと判断する前に、サーバーがこれを実行する回数を定義します。その時点で、接続は切断されます。
これは、60秒ごとにチェックし、3回チェックする構成例です。
ClientAliveInterval 60
ClientAliveCountMax 3 これらの値を、ご使用の環境に適したものに編集してください。
注：SSHを使用して他の接続をトンネリングしている場合は、他のアプリケーションが使用しているものを適切にサポートするために、間隔が十分に長いことを確認する必要があります。
ServerAliveIntervalがあります クライアント側でも構成できる値。これにより、クライアントは応答しないSSHサーバーへの接続を切断できます。
8。これが鍵です
最近のSSHの最も一般的なセキュリティ設定の1つは、キーベースの認証です。私がLinuxを教えてきた年月を経て、この認証方法はますます一般的になりました。実際、私はこのプロセスに自信がない限り、RedHat管理者試験を試みることはありません。幸い、それは難しいことではありません。
簡単なレビューをしましょう。キーベースの認証では、非対称暗号化を使用します。つまり、2つのキーがあり、異なるが数学的には相互に関連しています。 1つはプライベートであり、ネットワークを介して送信されることはありません。もう1つは公開されており、ネットワークを介して転送される場合があります。キーは関連しているため、SSH認証の試行などのIDを確認するために使用できます。
ローカルSSHクライアントコンピューターでキーペアを生成してから、ネットワークを介して公開キーを宛先SSHサーバーに転送する必要があります。つまり、キーは管理ワークステーションであなたを識別します。この構成が行われると、SSH接続を確立するときにパスワードの入力を求められることはなくなります。
このプロセスに必要な手順はわずかです。
まず、キーペアを生成します：
# ssh-keygen
キーは、ホームディレクトリの.sshという名前の隠しディレクトリに保存されます。 、およびデフォルトのキー名はid_rsa （秘密鍵）およびid_rsa.pub （公開鍵）。
次に、user1公開鍵をネットワーク経由で10.1.0.42にある宛先SSHサーバーに送信します。
# ssh-copy-id [email protected] 最後に、接続をテストします：
# ssh [email protected] パスワードの入力を求められないことに注意してください。
キーベースの認証を採用したので、sshd_configを編集できます。 パスワードに基づくログインを防ぐためのファイル。この設定を構成すると、キーベースの認証のみが受け入れられます。
ファイル内の次の2行を編集します：
PasswordAuthentication no
PublicKeyAuthentication yes [セキュリティについてもっと知りたいですか？ ITセキュリティとコンプライアンスのチェックリストを確認してください。 ]
まとめ
環境をより安全にするために、一般的で効果的なSSH構成をいくつかリストしました。セキュリティがあれば、デバイスを保護する設定は1つもないことを忘れないでください。目標はセキュリティの層であり、その組み合わせはセキュリティの脅威を軽減するのに役立ちます。キーベースの認証を実装する場合は、キーを慎重に整理することを強くお勧めします。一元化された/etc/ssh/sshd_configの使用を検討することもできます。 SSHサーバーで一貫したセキュリティ構成を維持するためのファイル。構成ファイルを変更するときはいつでもSSHを再起動することを忘れないでください。