ウェブサイト検索

LFCA: Linux システムのセキュリティを向上させる方法 – パート 20

皆さんが知っているように、root ユーザーは王様であり、Linux システムに対して無制限の特権を行使します。ただし、非 root ユーザーは基本的なタスクに限定されます。さらに、sudo ユーザーには、root ユーザーが特定の昇格されたタスクを実行するのに適していると判断した、ある程度の root 権限のみが付与されます。

通常のユーザーがリソースへのアクセスを制御されていない場合、または意図せずに root に昇格された場合に問題が発生します。これは重大なセキュリティ リスクであり、侵害や望ましくない変更、最悪の場合はシステムのクラッシュを引き起こす可能性があります。もう 1 つの潜在的なリスクは、ファイルのファイル権限の安全性が低い場合です。たとえば、グローバル ユーザーに書き込み権限を持つブート ファイルは簡単に変更または破損され、その結果システムが破損する可能性があります。

物理的、ネットワーク、およびデータのセキュリティを実装することはできますが、悪意のあるユーザーがセキュリティ対策を回避し、そのようなセキュリティの抜け穴を利用する可能性があります。このため、ファイル システムのセキュリティは真剣に考慮される必要があります。ファイルにアクセスするためにセキュリティ対策を回避するという重労働を行う必要がない、悪意のある従業員からの攻撃や内部関係者の脅威に直面した場合に追加の防御層を提供します。

システム セキュリティでは、次の重要な点に重点を置きます。

  • アクセス権 – ユーザーおよびグループの権限。
  • PAM モジュールを使用してパスワード ポリシーを適用します。

アクセス権 – ユーザーとグループの分離

Linux ではすべてがファイルとみなされます、ということを聞いたことがあるでしょう。そうでない場合は、それはプロセスです。 Linux システム上のすべてのファイルは、ユーザーおよびグループ ユーザーによって所有されます。また、ユーザー (u)、グループ (g)、およびその他 (o) の 3 つのユーザー カテゴリに対するファイル権限も付与されます。権限は、ユーザー カテゴリごとに読み取り、書き込み、実行 ( rwx ) で表されます。

rwx        rwx	     rwx
User       Group     Others

前に示したように、Linux の基本セクションでは、次のように ls コマンドの長い形式を使用してファイルのアクセス許可を表示できます。

ls -l

要約すると、権限は通常 9 文字で表されます。最初の 3 文字は、ファイルを所有する実際のユーザーのアクセス権を表します。 2 番目の文字セットは、ファイルのグループ所有者の権限を表します。最後に、他のユーザーまたはグローバル ユーザー用の最後のセットです。これらの文字は常に読み取り、書き込み、実行 (rwx) の順序になります。

権限の後には、ユーザーとグループの所有権があり、ファイルまたはディレクトリのサイズ、変更日、最後にファイルの名前が続きます。

ファイル/ディレクトリのアクセス許可と所有権の変更

ファイルとディレクトリのユーザー権限は、必要に応じて変更できます。経験則では、最小特権のセキュリティ原則を使用します。簡単に言うと、作業を行うために必要な最小限のアクセス権または権限をユーザーが取得できるようにする必要があります。

最小特権の原則により、ユーザーは特定のロールのみに制限され、これにより、攻撃者が低レベルのユーザー アカウントを利用して重要なデータにアクセスし、変更するリスクが最小限に抑えられます。また、攻撃者がシステムを制御した場合の攻撃対象領域を減らし、マルウェアの伝播を制限します。

したがって、ユーザーがファイルまたはディレクトリの内容を表示するだけでよい場合は、実行権限や書き込み権限を付与すべきではありません。非常に基本的なレベルでは、ユーザーがタスクを実行するために必要な最小限のアクセス許可と所有権のみを付与します。基本的な Linux コマンドのトピックでは、chmod および chown コマンドを使用してファイル/ディレクトリのユーザー権限と所有権を変更する方法に取り組みました。

スティッキービット許可モード

システム管理者がアクセス許可を管理しやすくするために、ディレクトリ全体に特別なアクセス許可またはアクセス権を付与できます。ファイルまたはディレクトリの削除と変更を制限するために適用できる特別なアクセス許可の 1 つがスティッキー ビットです。

スティッキービット

システムまたはネットワーク内のすべてのユーザーが共有ディレクトリにアクセスできるシナリオでは、一部のユーザーがディレクトリ内のファイルを削除または変更できる潜在的なリスクがあります。ディレクトリの内容の整合性を維持したい場合、これは望ましくありません。ここで問題が発生します。

スティッキー ビットは、ファイルまたはディレクトリ全体に設定される特別なファイル権限です。そのファイル/ディレクトリの所有者にのみ、ファイルまたはディレクトリの内容を削除または変更する権限が付与されます。他のユーザーはファイル/ディレクトリを削除または変更できません。シンボリック値は t 、数値は 1000 です。

ディレクトリのスティッキー ビットをオンにするには、次のようにchmod コマンドを使用します。

chmod +t directory_name

以下の例では、test というディレクトリにスティッキー ビットを適用しています。ディレクトリの場合、すべてのコンテンツはスティッキー ビットのアクセス許可を継承します。 ls -ld コマンドを使用して、スティッキー ビットのアクセス許可を確認できます。ファイル権限の末尾にある t 記号に注意してください。

ls -ld test

別のユーザーがディレクトリを削除したり、ディレクトリ内のファイルを変更しようとすると、アクセスが拒否されました エラーが表示されます。

これがスティック ビット ファイル パーミッションの要点です。

SUID および SGID 権限の監視

SUID (ユーザー ID の設定) は、別の通常のユーザーがファイル所有者のファイル アクセス許可でファイルを実行できるようにするもう 1 つの特別なファイル アクセス許可です。これは通常、実行権限を表す x ではなく、ファイル権限のユーザー部分のシンボリック値 s によって示されます。 SUID の数値は 4000 です。

SGID (グループ ID の設定) を使用すると、通常のユーザーがファイル グループ所有者のグループ権限を継承できるようになります。実行権限の x ではなく、ファイル権限のグループ部分に s が表示されます。 SGID の数値は 2000 です。

どんなに便利であっても、SUID と SGID のアクセス許可はセキュリティ リスクを伴うため、絶対に使用しないようにする必要があります。これは、通常のユーザーに特別な権限を付与するためです。一般ユーザーを装った侵入者が、SUID ビットが設定された root ユーザーが所有する実行可能ファイルを見つけた場合、その抜け穴を利用してシステムを悪用する可能性があります。

Linux で SUID ビットが設定されているすべてのファイルを検索するには、root ユーザーとして find コマンドを実行します。

find / -perm -4000 type -f

ディレクトリの場合は次を実行します。

find / -perm -4000 type -d

SGID ビットが設定されているすべてのファイルを検索するには、次のコマンドを実行します。

find / -perm -2000 type -f

ディレクトリの場合は次を実行します。

find / -perm -2000 type -d

ファイルのSUIDビットを削除するには、次のように chmod コマンドを実行します。

chmod u-s /path/to/file

ファイルの SGID ビットを削除するには、次のコマンドを実行します。

chmod g-s filename /path/to/file

PAM モジュールを使用してパスワード ポリシーを適用する

ユーザーが弱いパスワードを設定することは珍しいことではありません。ログイン中にパスワードを忘れないようにするために、短く、単純で、簡単に推測できるパスワードを適切な数に設定します。便利ではありますが、弱いパスワードは総当たり攻撃スクリプトを使用して簡単に突破される可能性があります。

PAM モジュール ( Pluggable Authentication Module ) は、システム管理者が Linux システムにパスワード ポリシーを適用できるようにするモジュールです。これを実現するには、libpam_pwquality ライブラリによって提供される pam_pwquality モジュールが必要です。 pam_pwquality モジュールは、一連のルールとシステム辞書に照らしてパスワードの強度をチェックし、弱いパスワードの選択肢を特定します。

pam_pwquality モジュールを Ubuntu 18.04 以降のバージョンにインストールするには、次のコマンドを実行します。

sudo apt install libpam_pwquality

RHEL/CentOS 8 の場合は、次のコマンドを実行します。

sudo dnf install libpwquality

構成ファイルは次の場所にあります。

  • Debian システムの場合 – /etc/pam.d/common-password
  • RedHat システムの場合 – /etc/pam.d/system-auth

パスワードポリシーの構成

PAM 構成ファイルの変更を開始する前に、まずパスワードの有効期間の制御に関する情報を収集することを検討してみましょう。

パスワードのエージングの詳細

これらは /etc/login.defs ファイルにあります。

このファイルには、次の主要なパスワード制御が含まれています。

  • PASS_MAX_DAYS: パスワードを使用できる最大日数。
  • PASS_MIN_DAYS: 最小数。パスワード変更の間に許可される日数。
  • PASS_WARN_AGE: パスワードの有効期限が切れるまでに表示される警告の日数。

デフォルト値を以下に示します。

PASS_MAX_DAYS 属性は、ユーザーがパスワードを使用できる日数を制限します。この値に達するか、パスワードの有効期限が切れると、ユーザーはシステムにログインするためにパスワードの変更を強制されます。デフォルトでは、この値は 99999 に設定されており、これは 273 年に相当します。ユーザーは生涯パスワードを使い続けることができるため、セキュリティに関する限り、これはあまり意味がありません。

これを意味のある値、たとえば図に示すように 30 日に設定できます。

PASS_MAX_DAYS  30

30 日が経過すると、ユーザーはパスワードを別のパスワードに変更することが強制されます。

PASS_MIN_DAYS 属性は、ユーザーがパスワードを変更するまでに使用できる最小期間を指定します。これはどういう意味ですか？たとえば、この値が 15 日に設定されている場合、ユーザーは 15 日が経過するまでパスワードを再度変更できなくなります。

PASS_MAX_DAYS  15

PASS_WARN_AGE 属性は、パスワードの期限が切れる前に、パスワードの有効期限が迫っていることに関する警告をユーザーに受け取る日数を指定します。たとえば、次のようにこれを 7 日に設定できます。

PASS_MAX_DAYS  7

注: これらのパスワード制御は、既存のアカウントでは機能しません。これらは、ルールを定義した後に作成された新しいアカウントにのみ適用されます。

PAM モジュールを使用したパスワードの複雑さの設定

/etc/pam.d/common-password ファイルを編集する前に、バックアップ コピーを作成してください。この例では、common-password.bak バックアップ コピー ファイルを作成しました。

sudo cp /etc/pam.d/common-password /etc/pam.d/common-password.bak

次に、ファイルを開きます。

sudo vim /etc/pam.d/common-password

以下に示す行を見つけます。

password        requisite          pam_pwquality.so retry=3

再試行オプションは、エラーが発生するまでに正しいパスワードの入力を要求される最大回数を設定します。デフォルトでは、これは 3 に設定されています。これは 1 つのオプションにすぎず、いくつかのオプションを含める予定です。

次の属性を行に追加します。

minlen=10 difok=3 lcredit=-1 ucredit=-1 dcredit=-1 ocredit=-1 reject_username

これらの属性を具体化してみましょう。

  • minlen=10: パスワードの最小許容サイズを設定します。この場合は10文字です。
  • difok=3: これは、以前のパスワードに存在する最大文字数です。
  • lcredit=-1: これは、パスワードに含める必要がある小文字の最小数です。
  • ucredit=-1: パスワードに含める必要がある小文字の最大数です。
  • dcredit=-1: パスワードに定義する必要がある数字の最小数。
  • ocredit=-1: パスワードに定義する必要がある特殊文字 (@、#、& など) の最小数。
  • reject_username: このオプションは、パスワードがストレートまたはリバース形式のユーザー名である場合に、パスワードの拒否をトリガーします。

パスワード ポリシーに違反する新しいユーザーを作成しようとすると、次のようなエラーが発生することになります。

まとめ

これで、システム セキュリティとセキュリティの基本全般に関するトピックは終了です。この章全体では、ハッカーや不満を抱いた従業員などの悪意のあるユーザーから Linux システムを保護するために実装できる基本的なセキュリティ対策に光を当ててきました。