Ubuntu18.04でOpenSSHを強化する方法

投稿日: 2022-04-20 2022-04-20
タグ: Security, Ubuntu 18.04

著者は、 Electronic Frontier Foundation Inc を選択して、 Write forDOnationsプログラムの一環として寄付を受け取りました。

序章

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 18.04を使用した初期サーバーセットアップに従ってセットアップされたUbuntu18.04サーバー（sudo非rootユーザーを含む）。

これを準備したら、root以外のユーザーとしてサーバーにログインして開始します。

ステップ1—一般的な硬化

この最初のステップでは、SSHサーバーの全体的なセキュリティを向上させるために、いくつかの初期強化構成を実装します。

独自のサーバーに最適な正確な強化構成は、独自の脅威モデルとリスクしきい値に大きく依存します。ただし、この手順で使用する構成は、大部分のサーバーに適した一般的な安全な構成です。

/etc/ssh/sshd_configにある標準のOpenSSHサーバー構成ファイルを使用して実装するOpenSSHの強化構成の多く。このチュートリアルを続行する前に、既存の構成ファイルのバックアップを取ることをお勧めします。これにより、万が一問題が発生した場合にファイルを復元できます。

次のコマンドを使用して、ファイルのバックアップを取ります。

sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bak

これにより、ファイルのバックアップコピーが/etc/ssh/sshd_config.bakに保存されます。

構成ファイルを編集する前に、現在設定されているオプションを確認できます。これを行うには、次のコマンドを実行します。

sudo sshd -T

これにより、OpenSSHサーバーが拡張テストモードで実行され、完全な構成ファイルが検証され、有効な構成値が出力されます。

これで、お気に入りのテキストエディタを使用して構成ファイルを開き、初期の強化対策の実装を開始できます。

sudo nano /etc/ssh/sshd_config

注： OpenSSHサーバー構成ファイルには、多くのデフォルトのオプションと構成が含まれています。既存のサーバー構成によっては、推奨される強化オプションの一部がすでに設定されている場合があります。

構成ファイルを編集する場合、一部のオプションは、行の先頭に単一のハッシュ文字（#）を使用してデフォルトでコメント化される場合があります。これらのオプションを編集したり、コメント付きのオプションを認識させたりするには、ハッシュを削除してコメントを解除する必要があります。

まず、次のオプションを設定して、rootユーザーとしてSSH経由でのログインを無効にします。

sshd_config

PermitRootLogin no

これは、潜在的な攻撃者がrootとして直接ログインするのを防ぐため、非常に有益です。また、非特権ユーザーとして操作したり、sudoを使用して絶対に必要な場合にのみ特権を昇格したりするなど、優れた運用セキュリティ慣行を奨励します。

次に、以下を構成することにより、特定のログインセッションの認証試行の最大数を制限できます。

sshd_config

MaxAuthTries 3

3の標準値はほとんどのセットアップで許容されますが、独自のリスクしきい値に応じて、これを高くまたは低く設定することをお勧めします。

必要に応じて、ログイン猶予期間を短縮することもできます。これは、ユーザーがSSHサーバーに最初に接続してから認証を完了する必要がある時間です。

sshd_config

LoginGraceTime 20

構成ファイルは、この値を秒単位で指定します。

これを低い値に設定すると、複数の認証セッションが長期間開いたままになる特定のサービス拒否攻撃を防ぐのに役立ちます。

パスワードを使用するのではなく、認証用にSSHキーを構成した場合は、SSHパスワード認証を無効にして、漏洩したユーザーパスワードが攻撃者にログインを許可しないようにします。

sshd_config

PasswordAuthentication no

パスワードに関連するさらなる強化策として、空のパスワードによる認証を無効にすることもできます。これにより、ユーザーのパスワードが空白または空の値に設定されている場合、ログインが防止されます。

sshd_config

PermitEmptyPasswords no

ほとんどのユースケースでは、SSHは、唯一の使用中の認証方法として公開鍵認証を使用して構成されます。ただし、OpenSSHサーバーは他の多くの認証方法もサポートしており、その一部はデフォルトで有効になっています。これらが不要な場合は、無効にしてSSHサーバーの攻撃対象領域をさらに減らすことができます。

sshd_config

ChallengeResponseAuthentication no
KerberosAuthentication no
GSSAPIAuthentication no

SSH内で利用可能な追加の認証方法のいくつかについて詳しく知りたい場合は、次のリソースを確認することをお勧めします。

X11転送では、SSH接続を介したリモートグラフィカルアプリケーションの表示が可能ですが、これが実際に使用されることはめったにありません。サーバーで必要ない場合は、無効にすることをお勧めします。

sshd_config

X11Forwarding no

OpenSSHサーバーを使用すると、接続しているクライアントがカスタム環境変数を渡すことができます。つまり、$PATHを設定したり、端末設定を構成したりできます。ただし、X11転送と同様に、これらは一般的に使用されないため、ほとんどの場合無効にすることができます。

sshd_config

PermitUserEnvironment no

このオプションを構成する場合は、行の先頭にハッシュ（#）を追加して、AcceptEnvへの参照をコメントアウトする必要があります。

次に、サーバーでこれらを使用しない場合は、トンネリングと転送に関連するいくつかのその他のオプションを無効にすることができます。

sshd_config

AllowAgentForwarding no
AllowTcpForwarding no
PermitTunnel no

最後に、オペレーティングシステムのバージョンなど、システムに関するさまざまな情報が表示されるため、デフォルトで有効になっている冗長SSHバナーを無効にすることができます。

sshd_config

DebianBanner no

このオプションは構成ファイルにまだ存在していない可能性が高いため、手動で追加する必要がある場合があることに注意してください。完了したら、ファイルを保存して終了します。

次に、テストモードでsshdを実行して、新しい構成の構文を検証します。

sudo sshd -t

構成ファイルに有効な構文がある場合、出力はありません。構文エラーが発生した場合は、問題を説明する出力が表示されます。

構成ファイルに問題がなければ、sshdをリロードして新しい設定を適用できます。

sudo service sshd reload

このステップでは、OpenSSHサーバー構成ファイルの一般的な強化を完了しました。次に、IPアドレス許可リストを実装して、サーバーにログインできるユーザーをさらに制限します。

ステップ2—IPアドレス許可リストの実装

IPアドレス許可リストを使用して、IPアドレスごとにサーバーへのログインを許可されているユーザーを制限できます。このステップでは、OpenSSHサーバーのIP許可リストを構成します。

多くの場合、少数の既知の信頼できるIPアドレスからのみサーバーにログオンします。たとえば、自宅のインターネット接続、企業のVPNアプライアンス、データセンター内の静的なジャンプボックスまたは要塞ホストなどです。

IPアドレス許可リストを実装することで、事前に承認されたIPアドレスの1つからのみログインできるようになり、秘密鍵やパスワードが漏洩した場合の侵害のリスクを大幅に減らすことができます。

注：許可リストに追加する正しいIPアドレスを特定するように注意し、たとえば消費者向けインターネットサービスプロバイダーでよく見られるように、これらが定期的に変更される可能性のあるフローティングアドレスまたは動的アドレスでないことを確認してください。

wコマンドを使用して、現在サーバーに接続しているIPアドレスを特定できます。

これにより、次のようなものが出力されます。

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アドレス許可リストの実装を開始するには、お気に入りのテキストエディタで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サーバー構成ファイルの最後に追加します。

sshd_config

AllowUsers *@203.0.113.1

ファイルを保存して閉じてから、構成構文のテストに進みます。

sudo sshd -t

エラーが報告されない場合は、OpenSSHサーバーをリロードして構成を適用できます。

sudo service sshd reload

このステップでは、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シェルの使用法をいくつかの追加の構成オプションと組み合わせて、関連するユーザーアカウントをさらに制限する必要があります。

まず、お気に入りのテキストエディタでOpenSSHサーバー構成ファイルを再度開きます。

sudo nano /etc/ssh/sshd_config

厳しく制限されたSFTPのみのユーザーアカウントを作成するために一緒に実装できる2つの構成オプションがあります：ForceCommand internal-sftpとChrootDirectory。

OpenSSHサーバー内のForceCommandオプションは、ユーザーにログイン時に特定のコマンドを実行するように強制します。これは、特定のマシン間通信、または特定のプログラムを強制的に起動する場合に役立ちます。

ただし、この場合、internal-sftpコマンドは特に便利です。これはOpenSSHサーバーの特別な機能であり、サポートするシステムファイルや構成を必要としない基本的なインプレースSFTPデーモンを起動します。

これは、理想的にはChrootDirectoryオプションと組み合わせる必要があります。これにより、特定のユーザーの認識されたルートディレクトリが上書き/変更され、基本的にシステム上の特定のディレクトリに制限されます。

このために、OpenSSHサーバー構成ファイルに次の構成セクションを追加します。

sshd_config

Match User alex
  ForceCommand internal-sftp
  ChrootDirectory /home/alex/

警告：ステップ2で説明したように、OpenSSH構成ファイル内では、Matchブロックの下のすべての構成は、インデントや改行に関係なく、基準に一致する接続にのみ適用されます。つまり、グローバルに適用することを目的とした構成が誤ってMatchブロック内に配置されないように注意する必要があります。これを回避するために、すべてのMatchブロックを構成ファイルの最後/最後に配置することをお勧めします。

構成ファイルを保存して閉じてから、構成を再度テストします。

sudo sshd -t

エラーがない場合は、構成を適用できます。

sudo service sshd reload

これにより、alexユーザーの堅牢な構成が作成され、インタラクティブログインが無効になり、すべてのSFTPアクティビティがユーザーのホームディレクトリに制限されます。ユーザーの観点からは、システムのルート、つまり/がホームディレクトリであり、ファイルシステムをトラバースして他の領域にアクセスすることはできません。

ユーザー用にnologinシェルを実装し、特定のディレクトリへのSFTPアクセスを制限する構成を作成しました。

ステップ4—高度な硬化

この最後のステップでは、SSHサーバーへのアクセスを可能な限り安全にするために、さまざまな追加の強化手段を実装します。

OpenSSHサーバーのあまり知られていない機能は、キーごとに制限を課す機能です。これは、.ssh/authorized_keysファイルに存在する特定の公開キーにのみ適用される制限です。これは、マシン間セッションへのアクセスを制御する場合や、sudo以外のユーザーが自分のユーザーアカウントの制限を制御する機能を提供する場合に特に役立ちます。

これらの制限のほとんどはシステムレベルまたはユーザーレベルでも適用できますが、キーレベルでも実装して、多層防御と追加のフェイルセーフを提供することは依然として有利です。偶発的なシステム全体の構成エラーのイベント。

注： SSH公開鍵認証を使用している場合にのみ、これらの追加のセキュリティ構成を実装できます。パスワード認証のみを使用している場合、またはSSH認証局などのより複雑な設定を使用している場合、残念ながらこれらは使用できません。

.ssh/authorized_keysファイルをお気に入りのテキストエディタで開くことから始めます。

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転送を無効にするには、次の構成を使用します。

〜/ .ssh / authorized_keys

no-agent-forwarding,no-X11-forwarding ssh-rsa AAAB...

デフォルトでは、これらの構成は「デフォルトで許可、例外でブロック」の方法を使用して機能します。ただし、「デフォルトでブロックし、例外で許可する」を使用することもできます。これは、セキュリティを確保するために一般的に推奨されます。

これを行うには、restrictオプションを使用します。これにより、特定のキーのすべてのSSH機能が暗黙的に拒否され、絶対に必要な場合にのみ明示的に再度有効にする必要があります。このチュートリアルで前述したのと同じ構成オプションを使用して機能を再度有効にすることができますが、no-プレフィックスはありません。

たとえば、X11ディスプレイ転送を除いて、特定のキーのすべてのSSH機能を無効にするには、次の構成を使用できます。

〜/ .ssh / authorized_keys

restrict,X11-forwarding ssh-rsa AAAB...

commandオプションの使用を検討することもできます。これは、手順3で説明したForceCommandオプションと非常によく似ています。すでにForceCommandを使用している場合、これは直接的なメリットにはなりませんが、メインのOpenSSHサーバー構成ファイルが上書きされた場合に備えて、多層防御を行うことをお勧めします。、編集など。

たとえば、特定のキーに対して認証するユーザーに、ログイン時に特定のコマンドを実行するように強制するには、次の構成を追加できます。

〜/ .ssh / authorized_keys

command="top" ssh-rsa AAAB...

警告： command構成オプションは、純粋に多層防御の方法として機能し、SSHユーザーのアクティビティを制限するためだけに依存するべきではありません。環境に応じて、オーバーライドまたはバイパスします。代わりに、この記事で説明されている他のコントロールと組み合わせて構成を使用する必要があります。

最後に、ステップ3で作成したSFTPのみのユーザーのキーごとの制限を最適に使用するには、次の構成を使用できます。

〜/ .ssh / authorized_keys

restrict,command="false" ssh-rsa AAAB...

restrictオプションはすべてのインタラクティブアクセスを無効にし、command="false"オプションはForceCommandオプションまたはnologinシェルの場合の2番目の防御線として機能します失敗することになっていました。

ファイルを保存して閉じ、構成を適用します。これはすべての新規ログインに対してすぐに有効になるため、OpenSSHを手動でリロードする必要はありません。

この最後のステップでは、.ssh/authorized_keysファイル内のカスタムオプションを使用して、OpenSSHサーバーにいくつかの追加の高度な強化手段を実装しました。

結論

この記事では、OpenSSHサーバーの構成を確認し、サーバーを保護するためのさまざまな強化策を実装しました。

これにより、未使用の機能を無効にし、特定のユーザーのアクセスをロックダウンすることで、サーバーの全体的な攻撃対象領域を減らすことができます。

OpenSSHサーバーのマニュアルページとそれに関連する構成ファイルを確認して、さらに微調整する可能性があるものを特定することをお勧めします。

getdocs

13036