Ubuntu20.04でOpenSSHを強化する方法
このチュートリアルの以前のバージョンは、 JamieScaifeによって作成されました。
序章
Linuxサーバーは、 OpenSSH サーバーに接続することにより、SSHを使用してリモートで管理されることがよくあります。これは、Ubuntu、Debian、CentOS、FreeBSD、およびその他のほとんどのLinux/BSDベースのシステムで使用されるデフォルトのSSHサーバーソフトウェアです。
OpenSSHサーバーはSSHのサーバー側であり、SSHデーモンまたはsshd
とも呼ばれます。 OpenSSHクライアントを使用して、特にssh
コマンドを実行することにより、OpenSSHサーバーに接続できます。 SSHクライアントサーバーモデルの詳細については、 SSH Essentials:SSHサーバー、クライアント、およびキーの操作を参照してください。 OpenSSHサーバーはサーバーへの正面玄関またはエントリポイントとして機能するため、OpenSSHサーバーを適切に保護することは非常に重要です。
このチュートリアルでは、さまざまな構成オプションを使用してOpenSSHサーバーを強化し、サーバーへのリモートアクセスが可能な限り安全になるようにします。
前提条件
このチュートリアルを完了するには、次のものが必要です。
- Ubuntu 20.04を使用した初期サーバーセットアップに従ってセットアップされたUbuntu20.04サーバー(sudo非rootユーザーを含む)。
これを準備したら、root以外のユーザーとしてサーバーにログインして開始します。
ステップ1—一般的な硬化
この最初のステップでは、SSHサーバーの全体的なセキュリティを向上させるために、いくつかの初期強化構成を実装します。
独自のサーバーに最適な正確な強化構成は、独自の脅威モデルとリスクしきい値に大きく依存します。 ただし、この手順で使用する構成は、大部分のサーバーに適した一般的な安全な構成です。
/etc/ssh/sshd_config
でメインのOpenSSH構成ファイルを編集して、このチュートリアルの強化オプションの大部分を設定します。 続行する前に、既存の構成ファイルのバックアップを作成して、万が一問題が発生した場合に復元できるようにすることをお勧めします。
次のcp
コマンドを使用して、ファイルのバックアップを作成します。
- sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bak
これにより、ファイルのバックアップコピーが/etc/ssh/sshd_config.bak
に保存されます。
次に、/etc/ssh/sshd_config
の設定に対応する現在のデフォルトのOpenSSH構成オプションを確認します。 これを行うには、次のコマンドを実行します。
- sudo sshd -T
これにより、OpenSSHサーバーが拡張テストモードで実行され、完全な構成ファイルが検証され、有効な構成値が出力されます。
これで、nano
またはお気に入りのテキストエディタを使用して構成ファイルを開き、初期の強化対策の実装を開始できます。
- sudo nano /etc/ssh/sshd_config
注: Ubuntu 20.04とともにインストールされるOpenSSHサーバー構成ファイルには、多くのデフォルトのオプションと構成が含まれています。 既存のサーバー構成によっては、推奨される強化オプションの一部がすでに設定されている場合があります。
構成ファイルを編集する場合、一部のオプションは、行の先頭に単一のハッシュ文字(#
)を使用してデフォルトでコメント化される場合があります。 これらのオプションを編集する、またはオプションを有効にするには、ハッシュを削除してコメントを解除する必要があります。
最初の強化オプションは、rootユーザーとしてSSH経由でのログインを無効にすることです。 次の行のコメントを解除または編集して、PermitRootLogin
オプションをno
に設定します。
PermitRootLogin no
このオプションは、潜在的な攻撃者がrootとしてサーバーに直接ログインするのを防ぎます。 また、非特権ユーザーとして操作したり、sudo
を使用して絶対に必要な場合にのみ特権を昇格したりするなど、運用上の適切なセキュリティ対策を促進します。
次に、MaxAuthTries
オプションを構成することにより、特定のログインセッションの認証試行の最大数を制限できます。
MaxAuthTries 3
3
の標準値はほとんどのセットアップで許容されますが、独自のリスクしきい値に応じて、これを高くまたは低く設定することをお勧めします。
必要に応じて、ログイン猶予期間を短縮することもできます。これは、ユーザーがSSHサーバーに最初に接続してから認証を完了する必要がある時間です。
LoginGraceTime 20
構成ファイルは、この値を秒単位で指定します。
これを低い値に設定すると、複数の認証セッションが長期間開いたままになる特定のサービス拒否攻撃を防ぐのに役立ちます。
パスワードを使用するのではなく、認証用にSSHキーを構成した場合は、SSHパスワード認証を無効にして、漏洩したユーザーパスワードが攻撃者にログインを許可しないようにします。
PasswordAuthentication no
パスワードに関連するさらなる強化策として、空のパスワードによる認証を無効にすることもできます。 これにより、ユーザーのパスワードが空白または空の値に設定されている場合、ログインが防止されます。
PermitEmptyPasswords no
ほとんどのユースケースでは、SSHは、唯一の使用中の認証方法として公開鍵認証を使用して構成されます。 ただし、OpenSSHサーバーは他の多くの認証方法もサポートしており、その一部はデフォルトで有効になっています。 これらが不要な場合は、無効にしてSSHサーバーの攻撃対象領域をさらに減らすことができます。
ChallengeResponseAuthentication no
KerberosAuthentication no
GSSAPIAuthentication no
SSH内で利用可能な追加の認証方法のいくつかについて詳しく知りたい場合は、次のリソースを確認することをお勧めします。
X11転送では、SSH接続を介したリモートグラフィカルアプリケーションの表示が可能ですが、これが実際に使用されることはめったにありません。 サーバーでグラフィカル環境を実行していない場合は、無効にします。
X11Forwarding no
OpenSSHサーバーを使用すると、接続しているクライアントがカスタム環境変数を渡すことができます。 たとえば、クライアントは独自の$PATH
を設定したり、端末設定を構成したりすることができます。 ただし、X11転送と同様に、これらは一般的に使用されないため、ほとんどの場合、このオプションを無効にできます。
PermitUserEnvironment no
このオプションをno
に設定して制限する場合は、ハッシュ(#
を追加して、構成ファイル内のすべての参照をAcceptEnv
にコメントアウトする必要があります。 ])そのオプションを指定する行の先頭まで。
次に、サーバーでこれらを使用しない場合は、トンネリングと転送に関連するいくつかのその他のオプションを無効にすることができます。
AllowAgentForwarding no
AllowTcpForwarding no
PermitTunnel no
最後に、オペレーティングシステムのバージョンなど、システムに関するさまざまな情報が表示されるため、デフォルトで有効になっている冗長SSHバナーを無効にすることができます。
DebianBanner no
このオプションは構成ファイルにまだ存在していない可能性が高いため、手動で追加する必要がある場合があることに注意してください。 完了したら、ファイルを保存して終了します。 nano
を使用している場合は、CTRL+O
を押してファイルを保存し、ファイル名の入力を求められたらENTER
を押します。 次に、CTRL+X
を押してエディターを終了します。
次に、-t
フラグを指定してテストモードでsshd
を実行し、新しい構成の構文を検証します。
- sudo sshd -t
構成ファイルに有効な構文がある場合、出力はありません。 構文エラーが発生した場合は、問題を説明する出力が表示されます。
構成ファイルに問題がなければ、systemd
を使用してsshd
をリロードし、新しい設定を適用できます。
- sudo systemctl reload sshd.service
このステップでは、OpenSSHサーバー構成ファイルの一般的な強化を完了しました。 次に、IPアドレス許可リストを実装して、サーバーにログインできるユーザーをさらに制限します。
ステップ2—IPアドレス許可リストの実装
IPアドレス許可リストを使用して、IPアドレスごとにサーバーへのログインを許可されているユーザーを制限できます。 このステップでは、OpenSSHサーバーのIP許可リストを構成します。
多くの場合、少数の既知の信頼できるIPアドレスからのみサーバーにログオンします。 たとえば、自宅のインターネット接続、企業のVPNアプライアンス、データセンター内の静的なジャンプボックスまたは要塞ホストなどです。
IPアドレス許可リストを実装することで、事前に承認されたIPアドレスの1つからのみログインできるようになり、秘密鍵やパスワードが漏洩した場合の侵害のリスクを大幅に減らすことができます。
注:許可リストに追加する正しいIPアドレスを特定するように注意し、たとえば消費者向けインターネットサービスプロバイダーでよく見られるように、これらが定期的に変更される可能性のあるフローティングアドレスまたは動的アドレスでないことを確認してください。
w
コマンドを使用して、現在サーバーに接続しているIPアドレスを特定できます。
- w
これにより、次のようなものが出力されます。
Output 14:11:48 up 2 days, 12:25, 1 user, load average: 0.00, 0.00, 0.00
USER TTY FROM LOGIN@ IDLE JCPU PCPU WHAT
your_username pts/0 203.0.113.1 12:24 1.00s 0.20s 0.00s w
リストでユーザーアカウントを見つけて、接続しているIPアドレスをメモします。 ここでは、203.0.113.1
のIPの例を使用します
IPアドレス許可リストの実装を開始するには、nano
またはお好みのテキストエディターでOpenSSHサーバー構成ファイルを開きます。
- sudo nano /etc/ssh/sshd_config
AllowUsers
構成ディレクティブを使用してIPアドレス許可リストを実装できます。これにより、ユーザー名やIPアドレスに基づいてユーザー認証が制限されます。
独自のシステム設定と要件によって、どの特定の構成が最も適切かが決まります。 次の例は、最も適切な例を特定するのに役立ちます。
- すべてのユーザーを特定のIPアドレスに制限します。
AllowUsers *@203.0.113.1
- クラスレスドメイン間ルーティング(CIDR)表記を使用して、すべてのユーザーを特定のIPアドレス範囲に制限します。
AllowUsers *@203.0.113.0/24
- すべてのユーザーを特定のIPアドレス範囲に制限します(ワイルドカードを使用)。
AllowUsers *@203.0.113.*
- すべてのユーザーを複数の特定のIPアドレスと範囲に制限します。
AllowUsers *@203.0.113.1 *@203.0.113.2 *@192.0.2.0/24 *@172.16.*.1
- 特定のIPアドレスからの名前付きユーザーを除くすべてのユーザーを禁止します。
AllowUsers sammy@203.0.113.1 alex@203.0.113.2
- 特定のユーザーを特定のIPアドレスに制限し、他のすべてのユーザーが制限なしでログインできるようにします。
Match User ashley
AllowUsers ashley@203.0.113.1
警告: OpenSSH構成ファイル内では、Match
ブロックの下のすべての構成は、インデントや改行に関係なく、基準に一致する接続にのみ適用されます。 つまり、グローバルに適用することを目的とした構成が誤ってMatch
ブロック内に配置されないように注意する必要があります。 これを回避するために、すべてのMatch
ブロックを構成ファイルの最後/最後に配置することをお勧めします。
構成を完了したら、OpenSSHサーバー構成ファイルの最後に追加します。
AllowUsers *@203.0.113.1
ファイルを保存して閉じてから、構成構文のテストに進みます。
- sudo sshd -t
エラーが報告されない場合は、OpenSSHサーバーをリロードして構成を適用できます。
- sudo systemctl reload sshd.service
このステップでは、OpenSSHサーバーにIPアドレス許可リストを実装しました。 次に、ユーザーのシェルを制限して、ユーザーが使用できるコマンドを制限します。
ステップ3—ユーザーのシェルを制限する
このステップでは、SSHユーザーのシェルを制限するためのさまざまなオプションについて説明します。
SSHは、リモートシェルアクセスを提供するだけでなく、SFTPなどを介してファイルやその他のデータを転送する場合にも最適です。 ただし、ユーザーがファイル転送のみを実行できるようにする必要がある場合は、ユーザーにフルシェルアクセスを常に許可するとは限りません。
OpenSSHサーバー内には、特定のユーザーのシェル環境を制限するために使用できる複数の構成があります。 たとえば、このチュートリアルでは、これらを使用してSFTPのみのユーザーを作成します。
まず、/usr/sbin/nologin
シェルを使用して、特定のユーザーアカウントの対話型ログインを無効にしながら、ファイル転送やトンネリングなどの非対話型セッションを機能させることができます。
nologin
シェルを使用して新しいユーザーを作成するには、次のコマンドを使用します。
- sudo adduser --shell /usr/sbin/nologin alex
または、既存のユーザーのシェルをnologin
に変更することもできます。
- sudo usermod --shell /usr/sbin/nologin sammy
その後、これらのユーザーの1人としてインタラクティブにログインしようとすると、要求は拒否されます。
- sudo su alex
これにより、次のメッセージのようなものが出力されます。
OutputThis account is currently not available.
インタラクティブログインでの拒否メッセージにもかかわらず、ファイル転送などの他のアクションは引き続き許可されます。
次に、nologin
シェルの使用法をいくつかの追加の構成オプションと組み合わせて、関連するユーザーアカウントをさらに制限する必要があります。
nano
またはお好みのエディターでOpenSSHサーバー構成ファイルを再度開くことから始めます。
- sudo nano /etc/ssh/sshd_config
厳しく制限されたSFTPのみのユーザーアカウントを作成するために一緒に実装できる2つの構成オプションがあります:ForceCommand internal-sftp
とChrootDirectory
。
OpenSSHサーバー内のForceCommand
オプションは、ユーザーにログイン時に特定のコマンドを実行するように強制します。 これは、特定のマシン間通信、または特定のプログラムを強制的に起動する場合に役立ちます。
ただし、この場合、internal-sftp
コマンドは特に便利です。 これはOpenSSHサーバーの特別な機能であり、サポートするシステムファイルや構成を必要としないインプレースSFTPデーモンを起動します。
これは、理想的にはChrootDirectory
オプションと組み合わせる必要があります。このオプションは、特定のユーザーの認識されたホームディレクトリを上書き/変更し、基本的にシステム上の特定のディレクトリに制限します。
このために、OpenSSHサーバー構成ファイルに次の構成セクションを追加します。
Match User alex
ForceCommand internal-sftp
ChrootDirectory /home/alex/
警告:ステップ2で説明したように、OpenSSH構成ファイル内では、Match
ブロックの下のすべての構成は、インデントや改行に関係なく、基準に一致する接続にのみ適用されます。 つまり、グローバルに適用することを目的とした構成が誤ってMatch
ブロック内に配置されないように注意する必要があります。 これを回避するために、すべてのMatch
ブロックを構成ファイルの最後/最後に配置することをお勧めします。
構成ファイルを保存して閉じてから、構成を再度テストします。
- sudo sshd -t
エラーがない場合は、構成を適用できます。
- sudo systemctl reload sshd.service
これにより、alex
ユーザーの堅牢な構成が作成され、インタラクティブログインが無効になり、すべてのSFTPアクティビティがユーザーのホームディレクトリに制限されます。 ユーザーの観点からは、システムのルート、つまり/
がホームディレクトリであり、ファイルシステムをトラバースして他の領域にアクセスすることはできません。
ユーザー用にnologin
シェルを実装し、特定のディレクトリへのSFTPアクセスを制限する構成を作成しました。
ステップ4—高度な硬化
この最後のステップでは、SSHサーバーへのアクセスを可能な限り安全にするために、さまざまな追加の強化手段を実装します。
OpenSSHサーバーは、キーごとに制限を課すことができます。 具体的には、.ssh/authorized_keys
ファイルに存在するすべての公開鍵に制限制限を適用できます。 この機能は、マシン間セッションへのアクセスを制御する場合や、sudo以外のユーザーが自分のユーザーアカウントの制限を制御する機能を提供する場合に特に役立ちます。
これらの制限のほとんどは、/etc/ssh/sshd_configuration
ファイルを使用してシステムまたはユーザーレベルで適用できますが、
注: SSH公開鍵認証を使用している場合にのみ、これらの追加のセキュリティ構成を実装できます。 パスワード認証のみを使用している場合、またはSSH認証局などのより複雑な設定を使用している場合、これらのオプションは使用できません。
.ssh/authorized_keys
ファイルをnano
またはお好みのエディターで開くことから始めます。
- nano ~/.ssh/authorized_keys
注:これらの構成はキーごとに適用されるため、適用する個々のauthorized_keys
ファイル内の個々のキーを、上のすべてのユーザーに対して編集する必要があります。あなたのシステム。 通常、編集する必要があるのは1つのキー/ファイルだけですが、複雑なマルチユーザーシステムを使用している場合は、これを検討する価値があります。
authorized_keys
ファイルを開くと、各行にSSH公開鍵が含まれていることがわかります。SSH公開鍵はssh-rsa AAAB...
のようなもので始まる可能性があります。 追加の構成オプションを行の先頭に追加できます。これらは、その特定の公開鍵に対する認証が成功した場合にのみ適用されます。
次の制限オプションを使用できます。
no-agent-forwarding
:SSHエージェント転送を無効にします。no-port-forwarding
:SSHポート転送を無効にします。no-pty
:ttyを割り当てる機能を無効にします(つまり、 シェルを開始します)。no-user-rc
:~/.ssh/rc
ファイルの実行を防止します。no-X11-forwarding
:X11ディスプレイ転送を無効にします。
これらを適用して、特定のキーの特定のSSH機能を無効にすることができます。 たとえば、キーのエージェント転送とX11転送を無効にするには、次の構成を使用します。
no-agent-forwarding,no-X11-forwarding ssh-rsa AAAB...
デフォルトでは、これらの構成は「デフォルトで許可、例外でブロック」の方法を使用して機能します。 ただし、「デフォルトでブロックし、例外で許可する」を使用することもできます。これは、セキュリティを確保するために一般的に推奨されます。
これを行うには、restrict
オプションを使用します。これにより、特定のキーのすべてのSSH機能が暗黙的に拒否され、絶対に必要な場合にのみ明示的に再度有効にする必要があります。 このチュートリアルで前述したのと同じ構成オプションを使用して機能を再度有効にすることができますが、no-
プレフィックスはありません。
たとえば、X11ディスプレイ転送を除いて、特定のキーのすべてのSSH機能を無効にするには、次の構成を使用できます。
restrict,X11-forwarding ssh-rsa AAAB...
command
オプションの使用を検討することもできます。これは、手順3で説明したForceCommand
オプションと非常によく似ています。 すでにForceCommand
を使用している場合、これは直接的なメリットにはなりませんが、メインのOpenSSHサーバー構成ファイルが上書きされた場合に備えて、多層防御を行うことをお勧めします。 、編集など。
たとえば、ログイン時に特定のキーを使用して認証するユーザーに特定のコマンドを実行させるには、次の構成を追加できます。
command="top" ssh-rsa AAAB...
警告: command
構成オプションは、純粋に多層防御の方法として機能し、SSHユーザーのアクティビティを制限するためだけに依存するべきではありません。環境に応じて、オーバーライドまたはバイパスします。 代わりに、この記事で説明されている他のコントロールと組み合わせて構成を使用する必要があります。
最後に、ステップ3で作成したSFTPのみのユーザーのキーごとの制限を最適に使用するには、次の構成を使用できます。
restrict,command="false" ssh-rsa AAAB...
restrict
オプションはすべてのインタラクティブアクセスを無効にし、command="false"
オプションはForceCommand
オプションまたはnologin
シェルの場合の2番目の防御線として機能します失敗することになっていました。
ファイルを保存して閉じ、構成を適用します。 これはすべての新規ログインに対してすぐに有効になるため、OpenSSHを手動でリロードする必要はありません。 現在のSSHセッションを切断する前に、使用する予定のコマンドを必ずテストしてください。
この最後のステップでは、.ssh/authorized_keys
ファイル内のカスタムオプションを使用して、OpenSSHサーバーにいくつかの追加の高度な強化手段を実装しました。
結論
この記事では、OpenSSHサーバーの構成を確認し、サーバーを保護するためのさまざまな強化策を実装しました。
構成したオプションにより、未使用の機能を無効にし、特定のユーザーのアクセスをロックダウンすることで、サーバーの全体的な攻撃対象領域を減らしました。
OpenSSHサーバーのマニュアルページとそれに関連する構成ファイルを確認して、さらに微調整する可能性があるものを特定することをお勧めします。