コアファイル監視機能は、サーバー上のコアファイルへのアクセスをリアルタイムで監視します。 この機能は、アクセス、変更、削除、名前変更などのファイル操作をリアルタイムで監視し、疑わしい操作に関するアラートを生成できます。 この機能を使用して、コアファイルが盗まれたか改ざんされたかを確認できます。 このトピックでは、コアファイル監視機能を使用して、サーバー上のコアファイルへのアクセスを監視する方法について説明します。
制限事項
Security CenterのEnterpriseエディションとUltimateエディションのみがこの機能をサポートしています。 Security Centerの購入とアップグレード方法の詳細については、「Security Centerの購入」および「Security Centerのアップグレードとダウングレード」をご参照ください。
この機能は、Security Centerエージェントがオンラインになっているサーバーのみをサポートします。 アイコンは、
エージェントがオンラインであることを示します。 オペレーティングシステムとカーネルバージョンのサーバーは、AliWebGuardファイルでサポートされている必要があります。 詳細については、「AliWebGuardファイルのサポートされているオペレーティングシステムとカーネルバージョン」をご参照ください。
ステップ1: ルールの作成
ルール検証ロジック
コアファイル監視機能が機能する前に、サーバーファイルの監視範囲を指定するルールを作成する必要があります。 ルールを作成する前に、ルール検証ロジックを理解することをお勧めします。
サーバー上のファイルへのアクセスの監視中に、リクエストが指定したルールの次のすべての項目と一致する場合にのみ、Security Centerはアラートを生成するか、リクエストを許可します。
プロセスパス
ファイルパス
ファイル操作
Security Centerは、Handling MethodパラメーターがReleaseに設定されているルールに対してリクエストを優先的に照合します。 このタイプのルールは許可ルールと呼ばれます。 リクエストが許可ルールと一致しない場合、Security Centerは、Handling MethodパラメーターがAlertに設定されているルールに対してリクエストを照合します。 このタイプのルールはアラートルールと呼ばれます。
設定の提案と例
コアシステムファイルと重要な設定ファイルのモニタリングルールを設定することを推奨します。 ルール設定の標準と例の詳細については、「コアファイルモニタリング機能を設定するためのベストプラクティス」をご参照ください。
ルールを作成する前に、監視するファイルと、ファイルへのアクセスを許可するプロセスの範囲を決定する必要があります。
コアビジネスファイルの場合、すべてのプロセスに対してアラートルールを設定し、許可されたプロセスに対して複数の許可ルールを設定する必要があります。 これにより、ファイルに対するすべてのアクセス操作が監視され、不要なアラートが生成されなくなります。
たとえば、監視するコアファイルのパスは /etc/sysctl.confで、許可されているプロセスはsystemdです。 ファイルパス /etc/sysctl.confを監視するには、2つのルールを設定する必要があります。
ルール1: Handling MethodパラメーターをAlertに設定し、Process Pathパラメーターをアスタリスク (
*) に設定し、File Pathパラメーターを/etc/sysctl.confに設定し、File operationパラメーターのすべてのオプションを選択します。 アスタリスク (*) はすべてのプロセスを指定します。ルール2: 処理方法パラメーターをリリースに設定し、プロセスパスパラメーターを
/usr/lib/systemd/systemdに設定し、ファイルパスパラメーターを/etc/sysctl.confに設定し、ファイル操作パラメーターのすべてのオプションを選択します。
複数のサーバー上のコアファイルを監視する場合は、アラートルールですべてのサーバーのファイルパスを指定し、[プロセスパス] パラメーターをアスタリスク (*) に設定します。 次に、異なるサーバーで許可する異なるプロセスパスに対して複数の許可ルールを設定します。
すべてのプロセスに対してアラートルールを設定しない場合、指定されたプロセスパスの範囲外のプロセスによるアクセス操作を監視できません。 範囲外のすべてのプロセスは、Security Centerの監視をバイパスできます。
許可ルールを設定するときは、ワイルドカード文字を使用してプロセスパスを指定しないことを推奨します。 ワイルドカード文字を使用してプロセスパスを指定すると、攻撃者は許可ルールを悪用して、セキュリティセンターの監視をバイパスした後にサーバーファイルにアクセスできます。
手順
Security Centerコンソールにログイン。 上部のナビゲーションバーで、管理するアセットのリージョンを選択します。 中国および全世界 (中国を除く)のリージョンがサポートされています。
左側のナビゲーションウィンドウで、を選択します。
Security Center Advancedまたはそれ以降のエディションを使用している場合は、今すぐ購入 をクリックして、Security Center EnterpriseまたはUltimateを購入します。
コアファイルの監視 ページで、モニタリングルール タブをクリックし、ホワイトリストルール作成 をクリックします。
ホワイトリストルール作成 パネルでパラメーターを設定し、OK をクリックします。
パラメーター
説明
ルール名
ルールの名前を入力します。
処理の方法
ルールがヒットしたときに実行するSecurity Centerのアクションを選択します。 有効な値：
アラート: Security Centerはアラートを生成し、イベントを記録します。
許可: セキュリティセンターはリクエストを許可します。 Security Centerはアラートを生成したり、イベントを記録したりしません。
アラートレベル
このパラメーターは、Handling Methodパラメーターをアラートに設定した場合にのみ必要です。
ルールがヒットしたときに生成されるアラートの重大度を選択します。
OSタイプ
監視するサーバのオペレーティングシステムタイプを選択します。
ルールのステータス
ルールの作成後にルールを有効にするかどうかを指定します。 最大100のルールを有効にできます。
プロセスパス
監視するプロセスのパスを入力します。
ワイルドカード文字を使用して、プロセスパスを指定できます。 たとえば、プロセスパス /usr/confを監視する場合は、*/confと入力します。 アスタリスク (*) を使用してすべてのプロセスを指定することもできます。
長さが1 ~ 128文字のプロセスパスを入力できます。
複数のパスを改行で区切る必要があります。 各ルールで最大20のプロセスパスを指定できます。
ファイルパス
監視するファイルのパスを入力します。
ワイルドカード文字を使用してファイルパスを指定できます。 たとえば、ファイルパス /etc/nginx/nginx.confを監視する場合は、/etc/nginx/* と入力します。 /* を使用してすべてのファイルパスを指定することもできます。
1 ~ 128文字のファイルパスを入力できます。
複数のパスを改行で区切る必要があります。 各ルールで最大20のファイルパスを指定できます。
ファイル操作
監視するファイル操作を選択します。
説明権限変更 オプションはWindowsシステムではサポートされていません。
ルール適用範囲
ルールを適用するサーバーを選択します。
ルールの作成後にルールを変更、削除、有効化、または無効化する場合は、ルールの [ステータス] 列または [アクション] 列でエントリポイントを見つけることをお勧めします。 サーバーのルールを初めて有効にするには、ルールが有効になるまで最大5分かかります。 ルールを変更する場合、ルールが有効になるまでに最大1分かかります。 ルールが有効になった後、既存のアラートと記録されたイベントは影響を受けません。
ステップ2: アラートの表示と処理
コアファイルの監視 ページで、アラートイベント タブをクリックします。 次に、ファイルアクセス時にSecurity Centerによって生成されるアラートを表示できます。
表示するアラートを見つけ、[操作] 列の 詳細 をクリックして、ファイルアクセスの詳細を表示します。
説明Pythonスクリプトを使用してファイルにアクセスすると、Security Centerは詳細なCLI情報を取得できません。
Shell組み込みコマンドを使用してファイルにアクセスすると、Security Centerは詳細なCLI情報を取得できません。 たとえば、コマンドが
echo "new content" >> /etc/nginx/nginx.confの場合、アラートの詳細ページに収集されたCLI情報として["-bash"]が表示されます。 これは、コマンドがシェル組み込みコマンドであり、nginx.confファイルにコンテンツを追加するためです。Security Centerは、シェル解析後にCLI情報を収集し、収集したCLI情報をJSON配列でアラート詳細ページに表示します。 表示されるコマンドは、元のユーザー指定コマンドとは異なる場合があります。
例1: ユーザー指定のコマンドは
mkdir "1 2"で、これはmkdir 1\ 2コマンドに相当します。 どちらのコマンドも、1 2という名前のディレクトリを作成します。 シェルの解析後、ユーザーが指定したコマンドはmkdirおよび1 2になり、アラートの詳細ページの表示結果は["mkdir", "1 2"]になります。例2: ユーザー指定のコマンドは
rm -rf *です。 シェル解析後、*は指定されたディレクトリ内のすべてのファイルとサブディレクトリに置き換えられます。 この例では、Security Centerは次のCLI情報を収集して表示します。rm、-rf、および現在のディレクトリ内のすべてのファイルとサブディレクトリのリスト。
ファイルアクセスの内容に基づいて, 異常イベントが記録されていないか確認してください。
フォローアップソリューションは、チェック結果によって異なります。
異常なイベントが記録された場合は、ビジネスに影響があることを確認した後、関連プロセスを手動でブロックし、関連ファイルを隔離することを推奨します。
イベントが通常のファイルアクセスを記録する場合、ホワイトリストにアラートを追加してアラートを処理できます。
イベントがファイルに影響を与えないと見なされ、ホワイトリストにアラートを追加する必要がない場合は、アラートを無視できます。
アラートを調べて処理した後、アラートを見つけて、[操作] 列の 処理 をクリックします。 次に、処理方法を選択し、OK をクリックします。
ホワイトリスト: ホワイトリストにアラートを追加すると、Security Centerは、アラートによって検出された動作を許可するホワイトリストルールを自動的に生成します。 このオプションを選択した場合、ホワイトリストルール名、プロセスパス、ファイルパス、ファイル操作、およびルールスコープのパラメーターを設定する必要があります。 次に、OK をクリックします。
無視: アラートを無視すると、アラートのステータスは無視に変わります。 同じアラートが後で検出された場合、Security Centerは新しいアラートを生成します。
手動処理: 異常イベントを処理した場合は、このオプションを選択できます。
よくある質問
web改ざん防止とコアファイル監視の違いは何ですか?
Web改ざん防止は、セキュリティセンターがファイルを保護するために提供する別の機能です。 Web改ざん防止とコアファイル監視は、次の項目が異なります。
項目 | Web 改ざん防止 | コアファイルモニタリング |
シナリオ | 攻撃を受けやすく、ファイルの改ざんに敏感なWebサイトなどの資産を保護する必要があります。 |
|
保護スコープ | この機能は、ほとんどのLinuxおよびWindowsサーバーを保護できます。 | この機能は、ほとんどのLinuxおよびWindowsサーバーを保護できます。 |
課金 | この機能は、Security Centerが提供する付加価値サービスです。 それを使用するには、機能を購入する必要があります。 | この機能は、Security Center EnterpriseおよびUltimateでのみ使用できます。 |
機能 | この機能は、異常なファイル変更の識別をサポートします。 この機能は、関連するプロセスをブロックしたり、アラートを生成したりできます。 | この機能は、読み取り、変更、削除操作など、ファイルへの異常なアクセスの監視をサポートします。 この機能は、アラートを生成することもできます。 |
web改ざん防止の詳細については、「web改ざん防止機能の使用」をご参照ください。
web改ざん防止とコアファイル監視の両方を有効にすると、どの機能が優先的に有効になりますか?
サーバーでweb改ざん防止とコアファイル監視の両方が有効になっている場合、web改ざん防止が優先的に有効になります。 Security Centerがweb改ざん防止のルールに対してリクエストを照合できない場合、Security Centerはリクエストをコアファイル監視のルールに対して照合します。 web改ざん防止のホワイトリストルールは、web改ざん防止機能が機能する場合にのみ有効になります。 コアファイルモニタリングの許可ルールは、コアファイルモニタリング機能が機能する場合にのみ有効になります。