1. システム・セキュリティの強化
  2. 追加のセキュリティ機能およびベスト・プラクティスの実装

4 追加のセキュリティ機能およびベスト・プラクティスの実装

この項では、Oracle Linuxシステムのセキュリティを強化するその他の方法と、環境を保護するためのベスト・プラクティスについて説明します。

コア・ダンプの操作

コア・ダンプは、プロセスに障害が発生して途中で終了したときに生成されるファイルです。コア・ダンプには、プロセスのメモリーのイメージが含まれています。コア・ダンプを使用して問題をデバッグし、プログラムが終了したときにプログラムのステージを検査できます。コア・ダンプはオンデマンドで作成することも、終了時に自動的に作成することもできます。

コア・ファイルはコアとも呼ばれ、現在の作業ディレクトリに作成されます。コアの書込みは、作成先のディレクトリが読取り専用であるか、同じ名前のファイルがその場所に存在し、そのファイルが読取り専用であるか通常ファイルではない場合に失敗します。

コア・ダンプには、攻撃者が悪用できる情報が含まれている可能性があります。コア・ダンプは、大量のディスク領域を占有する可能性もあります。そのため、Oracle Linuxでは、デフォルトでコア・ダンプ機能が無効になります。これを行うには、コア・ダンプ・ファイルの最大サイズを0に制限します。次のulimitコマンドを使用して、システムの現在のコア・サイズを確認できます。たとえば、次のコマンドでは、端末の現在のユーザー・セッションのulimitサイズがデフォルト値の0に設定されていることが示されています: 

ulimit -c
0
現在の端末セッションで実行されているアプリケーションに問題が発生した場合は、ulimit -cの値を0より大きい任意の整数に変更することで、そのセッションのコア・ダンプを有効にできます。次に例を示します。 
ulimit -c 1000

リブート間で変更内容を保持するには、コア・ダンプへのアクセスを様々なユーザーやグループに制限または限定します。詳細は、limits.conf(5)マニュアル・ページを参照してください。

デフォルトでは、setuidおよびsetgidプログラム、資格証明が変更されたプログラム、およびコア・ダンプの読取り権限を持たないバイナリを含むプログラムが阻止されます。この設定がまだ無効になっていることを確認するには、次のコマンドを実行します: 
sysctl fs.suid_dumpable

値fs.suid_dumpable = 0は、その設定がまだ無効になっていることを示しています。

注意:

これらのプログラムに対してダンプ・ファイルを有効にすることはお薦めしません。なんらかの理由でこれらのプログラムに対してダンプ・ファイルを有効にする必要がある場合は、fs.suid_dumpable値を1または2に設定することで、このダンプ・ファイルを有効にできます。値1は、ダンプ・プロセスの所有者から読取り可能なコア・ダンプを作成します。値2は、デバッグ目的でrootからのみ読取り可能なコア・ダンプを作成します。

コア・ダンプを一時的に有効にして不具合が生じているシステムをトラブルシューティングする方法の詳細は、『Oracle Linux 8: システムのモニタリングおよびチューニング』を参照してください。

自動バグ報告ツールの使用

自動バグ報告ツール(abrt)を実行している場合、コア・ダンプ機能を無効にしても、システムでコア・ダンプが引き続き生成されることがあります。本番システムでは、オプションで完全に無効化またはアンインストールできます。

注意:

自動バグ報告ツールは、非推奨になっています。かわりにsystemd-coredump機能を使用することを検討してください。coredumpctlコマンドの使用方法の詳細は、『Oracle Linux 8: システムのモニタリングおよびチューニング』およびsystemd-coredumpのマニュアル・ページを参照してください。

abrtdサービスを完全に停止および無効化するには、次を実行します。 

sudo systemctl disable --now abrtd

サービスを実行するときに、署名付きパッケージを使用してインストールされたバイナリのコア・ダンプのみを分析するようにサービスを制限できます。また、拒否リストに追加することで、ダンプ内の機密情報が明らかになる特定のバイナリをサービスが分析しないようにすることもできます。

たとえば、/etc/abrt/abrt-action-save-package-data.confを編集して、次のパラメータを設定します。 

# Require a GPG signature for a package
OpenGPGCheck = yes                                             
 
# Add any package names to the Blacklist that contain binaries 
# that you want abrt to not store dump data for
BlackList = nspluginwrapper, valgrind, strace, mono-core, bash

# Disable processing of unpackaged binaries
ProcessUnpackaged = no

# Add any paths to the BlackListedPaths that may contain binary 
# executables that you want abrt to not store dump data for
BlackListedPaths = /usr/share/doc/*, */example*, /usr/bin/nspluginviewer, \
     /usr/lib*/firefox/plugin-container

BlackListおよびBlackListedPathsオプションを使用すると、サービスがダンプ・データを格納できないようにできますが、ダンプは短時間で生成され、ディスクに書き込まれてから削除されます。これにより、abrtdは、ディスク領域を使用しないでクラッシュについてシステム管理者に通知できます。

コア・ダンプがディスクに書き込まれないようにし、abrtdでアプリケーションのクラッシュが検出されないようにするには、/etc/abrt/plugins/CCpp.confファイルを編集して、バイナリの絶対パスをIgnoredPathsリストに追加します。次に例を示します。 

IgnoredPaths = /path/to/binary

カーネル・セキュリティ・メカニズムの構成および使用

Linuxカーネルには、システム・セキュリティを強化する、いくつかのセキュリティ・メカニズムが搭載されています。これらのメカニズムにより、プロセスのアドレス空間の配置をランダム化したり、実行不可能なメモリー内でコードが実行されるのを防ぎます。

アドレス空間配置のランダム化

アドレス空間配置のランダム化(ASLR)は、特定のタイプのバッファ・オーバーフロー攻撃を撃退するのに役立ちます。ASLRでは、ベース、ライブラリ、ヒープ、スタックをプロセスのアドレス空間のランダムな位置に配置します。これにより、攻撃プログラムは次の命令のメモリー・アドレスを予測することが困難になります。ASLRはLinuxカーネルに組み込まれており、パラメータ/proc/sys/kernel/randomize_va_spaceによって制御されます。randomize_va_spaceパラメータは、次の値をとることができます。
0

ASLRを無効化します。この設定は、カーネルがnorandmapsブート・パラメータでブートされる場合に適用されます。

1

スタック、仮想動的共有オブジェクト(VDSO)ページ、共有メモリー領域の位置をランダム化します。データ・セグメントのベース・アドレスは、実行可能コード・セグメントの末尾の直後に配置されます。

2

スタック、VDSOページ、共有メモリー領域およびデータ・セグメントの位置をランダム化します。これはデフォルトの設定です。

次のように、新しい値を/proc/sys/kernel/randomize_va_spaceに書き込むことで、設定を一時的に変更できます。 

echo value | sudo tee /proc/sys/kernel/randomize_va_space

値を完全に変更するには、この設定を/etc/sysctl.confに追加します: 

kernel.randomize_va_space = value

その後、sysctl -pコマンドを実行します。

randomize_va_spaceの値を変更する場合は、アプリケーション・スタックをテストして、新しい設定と互換性があることを確認することをお薦めします。

オプションで、特定のプログラムとその子プロセスに対してASLRを無効にできます: 

setarch `uname -m` -R program [args ...]

データ実行の防止またはNo eXecute

データ実行防止(DEP)機能は、No eXecute (NX)とも呼ばれ、アプリケーションまたはサービスが実行不可能なメモリー領域でコードを実行することを防ぎます。ハードウェアで強制されたDEPは、互換性のあるCPU上のNXビットと連携して動作し、特定のタイプのバッファ・オーバーフロー攻撃を防止します。この機能では、ハードウェア機能を使用してシステムを保護するため、デフォルトで有効になっており、無効にすることはできません。

Oracle Linuxでは、ハードウェアにNXビットを実装していないCPUのために、ソフトウェアでNXビットをエミュレートすることはありません。

位置独立実行形式

位置独立実行形式(PIE)機能では、カーネルがテキストを再配置できないように、ランダム・メモリー・アドレスで実行可能バイナリをロードします。開発者はこの機能を使用して、アプリケーションがロードされるたびに異なるメモリー・アドレスにロードされるアプリケーションをコーディングできるため、攻撃者はアプリケーションがメモリー内に格納される場所を予測しにくくなります。そのため、メモリー関連の攻撃からの保護に役立ちます。

位置独立バイナリを生成するには:

  • コンパイル時にgccに-fpieオプションを指定します。

  • リンク時にldに-pieオプションを指定します。

PIEを有効にしてバイナリまたはライブラリを構築したかどうかをテストするには、次のコマンドを実行します。 

sudo readelf -d elfname | grep -i flags

多くの場合、このコマンドはPIEフラグが設定されているかどうかを示します。デフォルトでは、Oracle Linux 8バイナリは、このオプションの設定から発生するコンパイルの問題など、そうしない特定の理由がないかぎり、通常、このフラグ・セットを使用して構築されます。

システム暗号化ポリシーの構成

Oracle Linux 8以降では、Oracle Linuxはシステム全体の暗号化ポリシーを設定する機能を提供します。多くのアプリケーションでは、通信の保護やデータの暗号化のために暗号化プロトコルを実装しています。以前は、アプリケーションではそれ固有の暗号化ポリシー構成が多様な方法でメンテナンスされていました。つまり、システム全体にわたる暗号化ポリシーの変更はアプリケーションごとに実行する必要があり、多くの場合、その構成方法はアプリケーションによって異なりました。

アプリケーションに取入れ可能なシステム全体暗号化ポリシーを定義できることで、多くの場合、管理のオーバーヘッドが減り、そのプロセスが簡略化されます。管理者は、システム全体暗号化ポリシーを構成でき、ほとんどのアプリケーションでデフォルトで同じポリシーを使用できます。

ポリシーにより、管理者は次を構成できます:

  • 受け入れられるTLS/SSL (およびDTLS)のバージョン
  • 受け入れられる暗号スイートおよび優先順序
  • 証明書とキー交換に使用できるパラメータ。次のものがあります。
    • 受け入れ可能なパラメータ最小サイズ(DH、ECDH、RSA、DSA、ECDSA)、
    • 受け入れ可能な楕円曲線(ECDH、ECDSA)、
    • 受け入れ可能な署名ハッシュ関数。
  • 安全再ネゴシエーションなどのその他のTLSオプション

Oracle Linuxでの主要な暗号化ソフトウェアのほとんどは、デフォルトで、システム全体暗号化ポリシーを使用するようにすでに構成されています。このように動作するように構成されたアプリケーションには、OpenSSL、GnuTLS、NSS、libkrb5ライブラリを使用するアプリケーションに加えて、OpenSSHやバインドなどの重要なアプリケーションが含まれます

システム全体ポリシーを構成しても、システム全体で動作が強制されるわけではありません。このポリシーは、様々なアプリケーションに共通の構成を提供します。システム全体ポリシーを使用するように設計されていないアプリケーションは、それで使用されている別のポリシー構成に従って機能し続けます。多くのアプリケーションには、必要に応じてシステム全体暗号化ポリシーをオーバーライドするオプションもあります。たとえば、OpenSSHには、サーバー・アプリケーションとクライアント・アプリケーションで異なる暗号化ポリシーを設定するオプションがあり、wgetやcurlなどのコマンドには、--ciphersオプションを使用してカスタム暗号選択および順序を定義するオプションがあり、システム全体ポリシーを効率的にオーバーライドします。

システム全体ポリシーでは、セキュリティ要件にあわせて、システムの強化やセキュアでないプロトコルの削除を実行できるように、アプリケーション内のデフォルトの暗号化動作を定義します。

Oracle Linuxにはupdate-crypto-policiesコマンドが含まれており、これを使用すると、アプリケーションとサービスで使用するためにシステムで有効になっている暗号化アルゴリズム、暗号、およびプロトコルを構成できます。このコマンドを使用して、ポリシーを緩和することも、さらに強化することもできます。

このツールと影響を受けるアプリケーションの詳細は、crypto-policies(7)およびupdate-crypto-policies(8)の各マニュアル・ページを参照してください。

事前定義済ポリシーについて

Oracle Linuxには、次の4種類の事前定義済暗号化ポリシーが組み込まれています。
  • LEGACY: 特定のレガシー・プロトコルを構成してレガシー・システムとの互換性を最大限に高めます。これには、3DES、RC1、DSA、TLSv1.0およびTLSv1.1の有効化が含まれます。DHおよびRSAの場合は、最小パラメータ・サイズを1024ビットに設定することもできます。このポリシーで指定されたプロトコルおよび値は、非常にセキュアであるとは言えませんが、簡単に悪用することはできません。
  • DEFAULT: TLSv1.2とTLSv1.3、IKEv2とSSH2など、標準的な最新のプロトコルを構成します。DHおよびRSAの場合は、最小パラメータ・サイズを2048ビットに設定することもできます。
  • FIPS: 暗号化ポリシーのFIPS 140-2要件を満たすようにシステムを構成します。このポリシーは、Oracle LinuxシステムでFIPSモードを有効にするためのFIPS-mode-setupコマンドによって有効になります。このポリシーの使用の詳細は、FIPSモードでのシステムの構成を参照してください。
  • FUTURE: SHA-1とCBCが無効になり、DHとRSAの場合に最小パラメータ・サイズを3072ビットに設定する、保守的なポリシー・レベル。このポリシーは、多数の古いシステムとの通信を無効にする可能性がありますが、アプリケーションが安全に機能し続けるには将来どのような措置を取る必要があるかを特定するために検討する価値があります。

これらのポリシーでの制限は、時間の経過とともに、新しいセキュアなデフォルト値の決定に伴い変更される可能性があります。

update-crypto-policiesツールを使用すると、現在のシステム・ポリシーの表示や、システムに適用するポリシーの変更ができます。

現在のシステム全体ポリシーの確認

すべてのユーザーは、次を実行することで、現在のシステム全体暗号化ポリシーを確認できます:

update-crypto-policies --show

システム全体ポリシーの設定

Oracle Linuxで暗号化ポリシー間を切り替えるには、ポリシーの名前を指定してupdate-crypto-policies --setコマンドを使用します。たとえば、LEGACYポリシーに切り替えるには、次を実行します。 

sudo update-crypto-policies --set LEGACY

このポリシーはすぐに更新されます。また、システム全体暗号化ポリシーを使用できるすべてのアプリケーションは、実行または再起動されるとすぐに、その新しいポリシーと連携します。一部のアプリケーションがすでにカスタム・ポリシーを使用して実行されている可能性があるため、必ずすべてのアプリケーションで正しいポリシーが使用されるように、ポリシーの変更後にシステムをリブートすることをお薦めします。

DEFAULTポリシーに戻すには、次を実行します。

sudo update-crypto-policies --set DEFAULT

モジュールの使用によるポリシーの拡張

ポリシー・モジュールまたはサブポリシーを作成することで、システム全体ポリシーをカスタマイズできます。モジュールを作成することで、ポリシー全体をゼロから作成する必要なく、ポリシーを微調整できます。たとえば、DEFAULTシステム・ポリシー全体を書き換えるのではなく、DEFAULTシステム・ポリシーを使用し、すべてのアプリケーションでより弱いSHA-1ハッシュ機能を無効にする場合は、モジュールを付加してDEFAULTポリシーを設定することで、モジュールを適用できます。次に例を示します: 

sudo update-crypto-policies --set DEFAULT:NO-SHA1

Oracle Linuxには、/usr/share/crypto-policies/policies/modules/ディレクトリにすでに構成済ですぐに使用できる追加のモジュールがいくつか用意されています。

/etc/crypto-policies/policies/modules/ディレクトリにカスタム・モジュールを作成できます。モジュールの名前は大文字にし、その拡張子は小文字の.pmodにする必要があります。たとえば、/etc/crypto-policies/policies/modules/NO-AES-128.pmodという名前のモジュールを作成して、このコンテンツをファイルに追加し、AES-128暗号全体を無効にできます: 

# Disable the AES-128 cipher
cipher = -AES-128-*

暗号を無効にするには、先頭に-文字を付ける必要があります。機能を有効にするには、接頭辞なしで指定します。この例では、ルールがAES-128暗号のすべてのモードと一致するようにワイルドカードを指定するために*文字も使用されています。

また、システム全体暗号化ポリシーを設定するときに、モジュールを連結することもできます:

sudo update-crypto-policies --set DEFAULT:NO-SHA1:NO-AES-128

ポリシー定義ファイルの構文の詳細は、crypto-policies(7)のマニュアル・ページを参照してください。

新しいシステム全体暗号化ポリシーの作成

Oracle Linuxに用意されている事前定義済ポリシーを使用するかわりに、カスタム暗号化ポリシーをゼロから作成できます。ポリシーは、/etc/crypto-policies/policies/ディレクトリで定義できます。ポリシー・ファイル名は、大文字で、小文字の接尾辞.polで終わる必要があります。ポリシー・ファイルでは、INIファイル形式が使用され、標準のkey = valueエントリが含まれています。

Oracle Linuxに用意されている事前定義済ポリシーは、/usr/share/crypto-policies/policies/ディレクトリに格納されます。カスタム・ポリシーを定義するには、既存のポリシーをコピーし、必要に応じてそれを構成します。次に例を示します。 

sudo cp /usr/share/crypto-policies/policies/DEFAULT.pol /etc/crypto-policies/policies/MYPOLICY.pol

ファイルの形式と構造の詳細は、crypto-policies(7)マニュアル・ページ内の"CRYPTO POLICY DEFINITON FORMAT"というセクションを参照してください。

カスタム・ポリシーの編集が終了したら、次のコマンドでそれを有効にします:

sudo update-crypto-policies --set MYPOLICY

カスタムのシステム全体ポリシーを有効にした後は、それをすべての実行中サービスに対して有効にするために、必ずシステムをリブートしてください。

注意:

モジュールを使用して既存のポリシーを拡張することで実行が必要な処理を実現できるかどうかを検討してください。カスタム・システム全体の暗号化ポリシーをメンテナンスするには、新しいセキュリティ標準を常に監視して調査する必要があります。そのため、事前定義済ポリシーをセキュリティ要件を満たすように拡張することで、ポリシー全体を自分でメンテナンスする必要がなくなります。

ユーザーのアカウントおよび権限の確認

ロック解除されたユーザー・アカウントがないかシステムをチェックすることは、多くの場合、適切なセキュリティ・プラクティスと考えられます。たとえば、次のコマンドを使用します: 

for u in $(awk -F: '{print $1}' /etc/passwd;); do sudo passwd -S "$u"; done | sort

次のような出力結果が表示されます。 

adm LK 2023-03-31 0 99999 7 -1 (Alternate authentication scheme in use.)
bin LK 2023-03-31 0 99999 7 -1 (Alternate authentication scheme in use.)
chrony LK 2023-06-20 -1 -1 -1 -1 (Password locked.)
clevis LK 2023-06-20 -1 -1 -1 -1 (Password locked.)
cockpit-wsinstance LK 2023-06-20 -1 -1 -1 -1 (Password locked.)
cockpit-ws LK 2023-06-20 -1 -1 -1 -1 (Password locked.)
...

このコマンドの出力の2番目のフィールドに、ユーザー・アカウントがロックされているかどうか(LK)、パスワードがないかどうか(NP)、または有効なパスワードがあるかどうか(PS)が示されます。3番目のフィールドには、ユーザーがパスワードを最後に変更した日付が示されます。残りのフィールドには、パスワードの最小経過期間、最大経過期間、警告期間、非アクティブ期間およびパスワードのステータスに関するその他の情報が示されます。期間の単位は日数です。

保護されていないアカウントにパスワードを設定するには、passwdコマンドを使用します。

未使用のアカウントをロックするには、passwd -lコマンドを使用します。userdelコマンドを使用して、アカウントを完全に削除することもできます。

注意:

システム・アカウントを保持する必要があります。これらはユーザーID数が1000未満のアカウント、特にユーザーID数が100未満のアカウントです。

詳細は、passwd(1)およびuserdel(8)の各マニュアル・ページを参照してください。

ユーザー・パスワードのエージング方法を指定するには、次の表で説明する/etc/login.defsファイルの設定を編集します。

設定 説明

PASS_MAX_DAYS

パスワードを変更するまでに使用できる最大日数。デフォルト値は99,999日です。

PASS_MIN_DAYS

パスワードを変更する間隔として許容される最大日数。デフォルト値は0日です。

PASS_WARN_AGE

パスワードの期限が切れる前に警告が表示される日数。デフォルト値は7日です。

詳細は、login.defs(5)マニュアル・ページを参照してください。

ユーザー・アカウントが非アクティブになってからロックされるまでの期間を変更するには、usermodコマンドを使用します。たとえば、次のように非アクティブ期間を30日に設定します。 

sudo usermod -f 30 username

新規ユーザー・アカウントのデフォルトの非アクティブ期間を変更するには、useraddコマンドを使用します。 

sudo useradd -D -f 30

値-1は、非アクティブのためにユーザー・アカウントがロックされることはありません。

詳細は、useradd(8)およびusermod(8)の各マニュアル・ページを参照してください。

root以外のユーザー・アカウントのユーザーIDが0でないことを確認するには、次のコマンドを使用します。 

sudo awk -F":" '$3 == 0 { print $1 }' /etc/passwd

このコマンドの出力は次のとおりです。 

root

デフォルトのユーザー・アカウントとパスワードを作成するソフトウェアをインストールする場合、ベンダーのデフォルト・パスワードをただちに変更することは、適切なセキュリティ・プラクティスと考えられます。OpenLDAPなどのLDAP実装を使用する集中ユーザー認証では、ユーザー認証および管理タスクを一元化できます。また、未使用のアカウントまたはパスワードなしのアカウントから発生するリスクを減らすことができます。

デフォルトでは、Oracle Linux 8システムは、ユーザーがrootとして直接ログインできないように構成されています。システム・アカウンティングで特権管理アクションを実行するユーザーの元のユーザー名をトレースできるように、suまたはsudoコマンドを使用してrootユーザーとしてタスクを実行する前に、指定ユーザーとしてログインする必要があります。sudoコマンドを使用して、特定のユーザーに特定の管理タスクを実行する権限を付与するには、visudoコマンドを使用して/etc/sudoersファイルを構成します。

たとえば、次のエントリでは、sudoコマンドの使用時にユーザーuser1にrootと同じ権限が付与されており、一方、user2には、systemctl、rpmおよびdnfなどのコマンドを実行できるように、限定された権限が定義されています。 

user1           ALL=(ALL)       ALL
user2           ALL= SERVICES, SOFTWARE

ユーザー・アカウントおよび認証の設定の詳細は、『Oracle Linux 8 システム・ユーザーおよび認証の設定』を参照してください。

ユーザー認証およびパスワード・ポリシーの構成

従来のデジタル・アイデンティティ・ポリシーに従う場合、Pluggable Authentication Module (PAM)機能を使用して、パスワードの複雑さ、長さ、経過期間、有効期限、前のパスワードの再利用を決定するルールを含む強力なユーザー認証およびパスワード・ポリシーを実施できます。ログイン試行に何回も失敗した後、通常の勤務時間後、または同時セッションが多数開かれている場合に、ユーザー・アクセスをブロックするようPAMを構成できます。これらのポリシーの一部は、パスワードの保存時または更新時にユーザーが適切でないセキュリティ・プラクティスを実装できるようになるため、セキュリティにとって有用ではなくなることに注意してください。詳細は、https://pages.nist.gov/800-63-3/sp800-63-3.htmlを参照してください。

PAMは様々なモジュールおよびカスタマイズ可能なパラメータが使用されているため、高度にカスタマイズできます。たとえば、デフォルトのパスワード整合性チェック・モジュールpam_pwquality.soはパスワードの強度をテストします。PAM構成ファイル(/etc/pam.d/system-auth)には、パスワードの強度をテストするための次のデフォルト・エントリが含まれます。 
password    requisite    pam_pwquality.so local_users_only retry=3 authtok_type= enforce_for_root
password    requisite    pam_pwhistory.so use_authtok enforce_for_root remember=4
password    sufficient   pam_unix.so sha512 shadow use_authtok enforce_for_root remember=4
password    sufficient   pam_sss.so use_authtok
password    required     pam_deny.so

pam_pwquality.soの行では、適切なパスワードを選択するために3回試行できることが定義されています。モジュールのデフォルト設定では、パスワード長は最小6文字で、そのうち3文字は前のパスワードと同じにできません。このモジュールは、/etc/passwdファイルで定義されているユーザーのパスワードの品質のみをテストします。

pam_unix.soの行は、新しいパスワードの入力を求める前にスタックで指定された古いパスワードをモジュールがテストし、SHA-512パスワード・ハッシュと/etc/shadowファイルを使用してアクセスを決定することを指定します。pam_pwqualityでは、/etc/passwdファイルに定義されているユーザーに対して、そのようなチェックが実行されます。

制御フラグとモジュール・パラメータを構成して、ユーザーがパスワードを変更するときに実行されるチェックを変更できます: 

password  required  pam_pwquality.so retry=3 minlen=8 difok=5 minclass=-1
password  required  pam_unix.so use_authtok sha512 shadow remember=5
password  required  pam_deny.so

pam_pwquality.soの行では、ユーザーは適切なパスワードの選択を3回試行できます。パスワードは最小8文字で、そのうち5文字は前のパスワードと異なる必要があり、大文字、小文字、数字および特殊文字を少なくとも1つずつ使用する必要があることを指定しています。

pam_unix.soの行では、モジュールではパスワード・チェックを実行せず、SHA-512パスワード・ハッシュと/etc/shadowファイルを使用し、各ユーザーの過去5つのパスワードに関する情報を/etc/security/opasswdファイルに保存することを指定しています。

詳細は、pam_deny(8)、pam_pwquality(8)およびpam_unix(8)の各マニュアル・ページを参照してください。

ファイル・システムのマウント、ファイル権限およびファイル所有権の構成

OSおよびユーザー・データに別個のディスク・パーティションを使用すると、"ファイル・システム・フル"のエラーがサーバーの操作に影響を与えるのを防ぎます。たとえば、/home、/tmp、/oracleなどに別個のパーティションを作成できます。

ディスク割当てを設定すると、ユーザーはファイル・システムに(意図的かどうかにかかわらず)入力できなくなるため、他のユーザーへのアクセスを拒否できます。

侵入時にOSファイルおよびユーティリティが変更されないようにするには、/usrファイル・システムを読取り専用権限でマウントします。ファイル・システム上のRPMを更新する必要がある場合は、-o remount,rwオプションを指定してmountコマンドを使用することで、読取りおよび書込みアクセスの両方で/usrを再マウントします。更新の実行後、-o remount,roオプションを使用して/usrファイル・システムを読取り専用モードに戻すことができます。

/tmpなどの非rootローカル・ファイル・システム、またはリムーバル・ストレージ・パーティションへのユーザー・アクセスを制限するには、mountに-o noexec、nosuid、nodevオプションを指定します。これらのオプションは、スクリプトではなくバイナリの実行を防止し、setuidビットがなんらかの影響を及ぼすのを防止し、デバイス・ファイルの使用を防止します。

各ファイル・システム上の所有されていないファイルおよびディレクトリをチェックするには、findコマンドを使用します: 

sudo find mount_point -mount -type f -nouser -o -nogroup -exec ls -l {} \;

所有されていないファイルおよびディレクトリは、削除されたユーザー・アカウントに関連付けられている可能性があるため、ソフトウェアのインストール・エラーまたは削除エラー、あるいはシステムへの侵入を示している可能性があります。見つかったファイルおよびディレクトリの権限と所有権を修正するか、これらを削除します。作成につながった問題を調査して修正することは、適切なセキュリティ・プラクティスと考えられます。

各ファイル・システム上のあらゆるユーザーが書込み可能なディレクトリをチェックするには、findコマンドを使用します: 

sudo find mount_point -mount -type d -perm /o+w -exec ls -l {} \;

システム・ユーザー以外のユーザーによって所有される、あらゆるユーザーが書込み可能なディレクトリを調査することは、適切なセキュリティ・プラクティスと考えられます。ユーザーが、他のユーザーがディレクトリに書き込むファイルを削除または変更できる場合は、検出または削除したディレクトリのアクセス権と所有権を修正できます。

findコマンドを使用してsetuidおよびsetgid実行可能ファイルをチェックすることもできます。 

sudo find path -type f \( -perm -4000 -o -perm -2000 \) -exec ls -l {} \;

setuidおよびsetgidビットが設定されている場合、root権限などの権限を必要とするタスクを実行可能ファイルで実行できます。ただし、バッファ・オーバーラン攻撃によってこれらの実行可能ファイルが悪用され、利用されたプロセスの権限を使用して不正コードが実行される可能性があります。

SSH接続へのアクセスの制限

セキュア・シェル(SSH)を使用すると、他のシステムとの保護された暗号化通信が提供されます。SSHはシステムへのエントリ・ポイントであるため、セキュリティが必要ない場合、無効にすることは、適切なセキュリティ・プラクティスと考えられます。

/etc/ssh/sshd_configファイルを編集して、rootユーザーへのローカル・アクセスを制限し、設定を構成して特定のユーザーおよびグループへのリモート・アクセスを制限できます。また、SSHクライアントが非アクティブ期間後に自動的にタイムアウトするように、/etc/ssh/sshd_configファイルで設定を構成することもできます。

SSHのパスワードベース認証を無効にし、かわりに公開キー認証を要求することは、適切なセキュリティ・プラクティスと考えられます。これにより、認可された秘密キーを所有するユーザーにアクセスを制限できます。

構成ファイルに変更を加えた後は、sshdサービスを再起動して変更内容を有効にする必要があります。

詳細は、『Oracle Linux OpenSSHを使用したリモート・システムへの接続』およびsshd_config(5)マニュアル・ページを参照してください。

システム監査および監視の使用

Oracle Linuxの監査サービスは、分析可能なカーネル・レベルでデータを収集して、不正なアクティビティを識別します。監査では、システム・ロギングよりもはるかに詳細なデータが数多く収集されますが、ほとんどの監査イベントは退屈で重要ではありません。監査証跡を調査して対象のイベントを見つけるプロセスは自動化できる、非常に難しい課題になる場合があります。

監査構成ファイル/etc/audit/auditd.confでは、データ保持ポリシー、監査ボリュームの最大サイズ、監査ボリュームの容量を超えた場合にとるべき措置、およびローカルおよびリモートの監査証跡ボリュームの場所を定義します。デフォルトの監査証跡ボリュームは、/var/log/audit/audit.logです。

Oracle Linuxシステムの監査および監視の詳細は、『Oracle Linux 8 システムのモニタリングおよびチューニング』を参照してください。

拡張侵入検出環境の使用

拡張侵入検出環境(AIDE)は、システム上の特定のファイルへの変更を検出し、それらに関してレポートするための様々なツールを使用するアプリケーションであり、これによって、ベースライン・ファイルの整合性を維持し、不正な変更や潜在的なツールキットの検出を実行できます。

このツールは次のようにインストールされます。 

sudo dnf install -y aide

AIDEのインストール時に、/etc/aide.confの構成を変更できます。この構成ファイルは、AIDEで監視されるファイルとディレクトリ、およびロギングと出力の処理方法を決定するために使用されます。

AIDEでは、システムの構成状態に関する現在の情報が/var/lib/aide/aide.dbにあるデータベースに格納されます。このデータベース・ファイルのコピーを外部の場所に格納する場合は、監査の実行時にAIDEの既知の安全な状態に置換できます。ファイルがまだ存在しない場合は、次を実行することで、現在のシステム状態のファイルを作成できます: 

sudo aide --init
sudo cp /var/lib/aide/aide.db.new.gz /var/lib/aide/aide.db.gz

データベースを作成したら、次を実行して、ファイルの整合性をいつでも確認できます: 

sudo aide --check

差異が見つからない場合、AIDEは次のメッセージで結果を返します。 

AIDE found NO differences between database and filesystem. Looks okay!!

このツールを自動cronジョブとして実行するように構成した場合は、早期侵入検出に役立つ可能性のあるシステム構成および状態への変更を示すための通常のレポートを取得できます。

詳細は、aide(1)およびaide.conf(5)の各マニュアル・ページを参照してください。

システム・プロセス・アカウンティングの実装

psacctパッケージは、プロセス・アクティビティの監視に使用できる次のユーティリティとともに、プロセス・アカウンティング・サービスを提供します:
ac

wtmpファイルに記録されているとおりに、ユーザーの接続時間を時間単位で表示します(デフォルトでは、/var/log/wtmp)。

accton

指定したファイルに対してプロセス・アカウンティングをオンにします。ファイル名引数を指定しないと、プロセス・アカウンティングは停止されます。デフォルトのシステム・アカウンティング・ファイルは/var/account/pacctです。

lastcomm

システム・アカウンティング・ファイルに記録されているコマンドの情報を表示します。

sa

システム・アカウンティング・ファイルに記録されているコマンドの情報を要約します。

注意:

ファイル・システムに、プロセス・アクティビティを監視するためのシステム・アカウンティング・ファイルおよびwtmpファイルを格納するための十分な領域があることを確認してください。ログ・ファイルのサイズを監視し、必要に応じて切り捨てることは、適切なセキュリティ・プラクティスと考えられます。

詳細は、ac(1)、 accton(8)、lastcomm(1)およびsa(8)の各マニュアル・ページを参照してください。

chroot jailを使用したルート・ディレクトリの保護

chrootコマンドは、実行中のプロセスとその子の表示可能なルート・ディレクトリを変更するため、/以外のルート・ディレクトリでプログラムを実行するために使用できます。プログラムは、構成済のディレクトリ・ツリー外部にあるファイルを表示することも、これにアクセスすることもできません。このような人為的なルート・ディレクトリを"chroot jail"と呼びます。その目的は、悪意のあるプロセスやハッカーのディレクトリへのアクセスを制限することです。chroot jailは、各プロセスおよびプロセスを使用しているすべてのユーザーIDをロック・ダウンするため、それらがアクセスできるのは、プロセスを実行しているディレクトリです。プロセスは、実行されているディレクトリがルート・ディレクトリであることも考慮されます。

注意:

chrootメカニズムでは、意図的な改ざんや特権ユーザーによるシステム・デバイスへの低レベルのアクセスを防ぐことはできません。たとえば、chroot rootユーザーはデバイス・ノードを作成し、その上にファイル・システムをマウントできます。また、root権限を取得し、chroot()を使用して現在の作業ディレクトリを実際のrootディレクトリに変更できた場合、プログラムはchroot jailの外部のリソースにアクセスできます。このため、chroot jailにrootが所有するsetuidまたはsetgid実行可能ファイルが含まれていないことを確認することは、適切なセキュリティ・プラクティスと考えられます。

chrootプロセスを正常に開始するには、必要なすべてのプログラム・ファイル、構成ファイル、デバイス・ノードおよび共有ライブラリを、chrootディレクトリの下の想定されているそれぞれの場所に(chrootディレクトリのレベルからの相対位置で)移入する必要があります。

Chroot JailでのDNSおよびFTPサービスの実行

DNSネーム・サービス・デーモン(named)がchroot jailで実行されている場合、BINDエクスプロイトを使用してシステムにアクセスするハッカーは、chroot jailディレクトリの下のファイルに分離されます。bind-chrootパッケージをインストールすると、/var/named/chrootディレクトリが作成され、これがすべてのBINDファイルのchroot jailとなります。

クライアントに対して自動的にchroot jailを起動するように、vsftpd FTPサーバーを構成できます。デフォルトでは、匿名ユーザーはchroot jailに配置されます。ただし、vsftpd FTPサーバーにアクセスしたローカル・ユーザーはそれぞれのホーム・ディレクトリに配置されます。ローカル・ユーザーをそれぞれのホーム・ディレクトリに基づいてchroot jailに配置するには、/etc/vsftpd/vsftpd.confファイルでchroot_local_user=YESオプションを指定します。

Chroot Jailの作成

Chroot jailを作成するには:

  1. chroot jailのrootディレクトリとなるディレクトリを作成します。次に例を示します: 

    sudo mkdir /home/oracle/jail

  2. lddコマンドを使用して、/usr/bin/bashなど、chroot jail内の実行予定のコマンドで必要となるライブラリを特定します: 

    sudo ldd /usr/bin/bash

    次のような出力結果が表示されます。 

    linux-vdso.so.1 (0x00007fffa5726000)
libtinfo.so.6 => /lib64/libtinfo.so.6 (0x00007f29127fa000)
libc.so.6 => /lib64/libc.so.6 (0x00007f29125f1000)
/lib64/ld-linux-x86-64.so.2 (0x00007f291298c000)

    注意:

    パスが/lib64として表示されていても、/lib64は/usr/lib64へのシンボリック・リンクのため、実際のパスは/usr/lib64です。同様に、/binは/usr/binへのシンボリック・リンクです。このようなシンボリック・リンクはchroot jail内で再作成する必要があります。

  3. chroot jailのルート・ディレクトリのサブディレクトリを作成します。このサブディレクトリの相対パスは、コマンド・バイナリとその必須ライブラリの実際のルート・ディレクトリからの相対パスと同じです。次に例を示します: 

    sudo mkdir -p /home/oracle/jail/usr/bin
    sudo mkdir -p /home/oracle/jail/usr/lib64

  4. バイナリおよびライブラリ・ディレクトリにリンクするシンボリック・リンクは、実際のルート・ディレクトリに存在するシンボリック・リンクと同じ方法で作成します。次に例を示します: 

    sudo ln -s /home/oracle/jail/usr/bin /home/oracle/jail/bin
    sudo ln -s /home/oracle/jail/usr/lib64 /home/oracle/jail/lib64

  5. バイナリと共有ライブラリを、chroot jailのルート・ディレクトリの下のディレクトリにコピーします。たとえば: 

    sudo cp /usr/bin/bash /home/oracle/jail/usr/bin
    sudo cp /usr/lib64/{libtinfo.so.5,libdl.so.2,libc.so.6,ld-linux-x86-64.so.2} /home/oracle/jail/usr/lib64

Chroot Jailの使用

既存のディレクトリのchroot jailでコマンドを実行するには(chroot_jail)、次のコマンドを使用します: 

sudo chroot chroot_jail command

コマンド引数が指定されていない場合、chrootはSHELL環境変数の値で実行し、SHELLが設定されていない場合は/usr/bin/shを実行します。

たとえば、次のように、chroot jailで/usr/bin/bashコマンドを実行します: 

sudo chroot /home/oracle/jail

このシェルでpwdなどの組込みのシェル・コマンドを実行することはできますが、バイナリおよび必要な共有ライブラリをChroot jailにコピーしないかぎり、他のコマンドは実行できません。

詳細は、chroot(1)マニュアル・ページを参照してください。