[非推奨]Syslog を使用して Linux ベースのソースからデータを収集する

Syslog は、Linux に共通するイベント ログ プロトコルです。 Linux デバイスとアプライアンスに組み込まれている Syslog デーモンを使用して、指定した種類のローカル イベントを収集し、Linux 用 Log Analytics エージェント (旧称 OMS エージェント) を使用してそれらのイベントを Microsoft Sentinel に送信させることができます。

この記事では、Syslog を使用してデータ ソースを Microsoft Sentinel に接続する方法について説明します。 このメソッドでサポートされているコネクタの詳細については、「 データ コネクタリファレンス」を参照してください。

Syslog を構成して DCR を作成する方法など、 Azure Monitor エージェントで Syslog を収集する方法について説明します。

建築

VM またはアプライアンスに Log Analytics エージェントがインストールされている場合は、インストール スクリプトによって、UDP ポート 25224 でエージェントにメッセージを転送するローカル Syslog デーモンが構成されます。 メッセージを受信すると、エージェントは HTTPS 経由で Log Analytics ワークスペースに送信し、 そこで Microsoft Sentinel > ログの Syslog テーブルに取り込まれます。

詳細については、 Azure Monitor の Syslog データ ソースに関するページを参照してください。

Log Analytics エージェントのローカル インストールを許可しない一部の種類のデバイスについては、代わりに、Linux ベースの専用ログ フォワーダーにエージェントをインストールできます。 転送元のデバイスは、ローカル デーモンではなく、このフォワーダー上の Syslog デーモンに Syslog イベントを送信するように構成されている必要があります。 フォワーダー上の Syslog デーモンから、UDP を介して Log Analytics エージェントにイベントが送信されます。 この Linux フォワーダーで、大量の Syslog イベントを収集することが予期されている場合は、代わりに TCP を介して、Syslog デーモンからエージェントにイベントが送信されます。 いずれの場合も、エージェントは次にそこから、Microsoft Sentinel 内の Log Analytics ワークスペースにイベントを送信します。

Syslog コレクションを構成する際には以下の 3 つの手順があります。

• Linux デバイスまたはアプライアンスを構成します。 これは、Log Analytics エージェントがインストールされるデバイスを指します。これは、イベントの発生元と同じデバイスであるか、イベントを転送するログ コレクターです。

• エージェントにイベントを送信する Syslog デーモンの場所に対応するアプリケーションのログ設定を構成します。

• Log Analytics エージェント自体を構成します。 これは Microsoft Sentinel 内から行われ、構成はインストール済みのすべてのエージェントに送信されます。

前提条件

開始する前に、Microsoft Sentinel のコンテンツ ハブから Syslog のソリューションをインストールします。 詳細については、「Microsoft Sentinel の即使用可能なコンテンツの検出と管理」を参照してください。

Linux マシンまたはアプライアンスを構成する

1. Microsoft Sentinel ナビゲーション メニューから、[ データ コネクタ] を選択します。

2. コネクタ ギャラリーから Syslog を選択 し、[ コネクタ ページを開く] を選択します。

   デバイスの種類が Microsoft Sentinel データ コネクタ ギャラリーに表示されている場合は、汎用 Syslog コネクタではなく、デバイスのコネクタを選択します。 お使いのデバイスの種類について、追加の手順や特別な手順がある場合は、ブックや分析ルール テンプレートのようなカスタム コンテンツと一緒にデバイスのコネクタ ページに表示されます。

3. Linux エージェントをインストールします。 [ エージェントをインストールする場所の選択] で、次の手順を実行します。

   マシンの種類	指示
   Azure Linux VM の場合	1. [ Azure Linux 仮想マシンにエージェントをインストールする] を展開します。 2. [Azure Linux 仮想マシン用のエージェントのダウンロードとインストール] > リンクを選択します。 3. [ 仮想マシン ] ブレードで、エージェントをインストールする仮想マシンを選択し、[ 接続] を選択します。 接続する各 VM に対してこの手順を繰り返します。
   その他の Linux マシンの場合	1. [Azure Linux 以外のマシンにエージェントをインストールする] を展開する 2. Azure Linux 以外のマシンのダウンロードおよびインストール エージェント > リンクを選択します。 3. [エージェント管理 ] ブレードで、[ Linux サーバー ] タブを選択し、[ Linux 用エージェントのダウンロードとオンボード ] コマンドをコピーし、Linux マシンで実行します。 Linux エージェントのインストール ファイルのローカル コピーを保持する場合は、[エージェントのダウンロードとオンボード] コマンドの上にある [Linux エージェント のダウンロード] リンクを選択します。

   注意

   組織のセキュリティ ポリシーに従って、これらのデバイスのセキュリティ設定を構成してください。 たとえば、組織のネットワーク セキュリティ ポリシーに合わせてネットワーク設定を構成し、デーモンのポートとプロトコルをセキュリティ要件に合わせて変更できます。

同じマシンを使用してプレーンな Syslog メッセージと CEF メッセージの両方を転送する

既存の CEF ログ フォワーダー マシン を使用して、プレーンな Syslog ソースからログを収集して転送することもできます。 ただし、両方の形式のイベントを Microsoft Sentinel に送信すると、イベントが重複することになるため、これを避けるには次の手順を行う必要があります。

CEF ソースからのデータ収集を既に設定し、Log Analytics エージェントを構成した場合:

1. CEF 形式でログを送信する各マシンで Syslog 構成ファイルを編集して、CEF メッセージの送信に使用されているファシリティを削除する必要があります。 これで、CEF で送信されるファシリティは、Syslog で送信されません。 これを行う方法の詳細な手順については、 Linux エージェントでの Syslog の構成 に関するページを参照してください。

2. これらのマシンで次のコマンドを実行して、エージェントと Microsoft Sentinel の Syslog 構成との同期を無効にする必要があります。 これで、前の手順で構成に加えた変更が上書きされなくなります。

   sudo -u omsagent python /opt/microsoft/omsconfig/Scripts/OMS_MetaConfigHelper.py --disable
   

デバイスのログ設定を構成する

多くのデバイスの種類では、データ コネクタ ギャラリーに独自の データ コネクタが 表示されます。 これらのコネクタの中には、Microsoft Sentinel でログ収集を適切に設定するために、特別な追加の手順が必要なものがあります。 これらの手順に、Kusto 関数に基づくパーサーの実装が含まれる場合があります。

ギャラリーに一覧表示されているすべてのコネクタには、ポータルのそれぞれのコネクタ ページと、 Microsoft Sentinel データ コネクタのリファレンス ページのセクションに特定の手順が表示されます。

Microsoft Sentinel のデータ コネクタのページの手順で、Kusto 関数が Advanced Security Information Model (ASIM) パーサーとしてデプロイされていることを示している場合は、ASIM パーサーがワークスペースにデプロイされていることを確認してください。

データ コネクタ ページのリンクを使用してパーサーをデプロイするか、 Microsoft Sentinel GitHub リポジトリの指示に従います。

詳細については、 高度なセキュリティ情報モデル (ASIM) パーサーを参照してください。

Log Analytics エージェントの構成

1. [Syslog コネクタ] ブレードの下部にある [ワークスペース エージェント構成を開く] >リンクを選択します。

2. レガシエージェント管理 ページで、コネクタがデータを収集するための機能を追加します。 [ 施設の追加] を選択し、施設のドロップダウン リストから選択します。

   • Syslog アプライアンスがそのログ ヘッダーに含めるファシリティを追加します。

   • 収集したデータで異常な SSH ログイン検出を使用する場合は、 auth と authpriv を追加します。 詳細については、 次のセクション を参照してください。

3. すべての監視したい施設を追加したら、収集したくない重大度のチェックボックスを解除します。 既定では、これらのすべてにチェックマークが付いています。

4. [ 適用] を選択します。

5. 仮想マシンまたはアプライアンスで、指定したファシリティが送信されていることを確認します。

データの検索

1. ログの syslog ログ データに対してクエリを実行するには、クエリ ウィンドウに「Syslog」と入力します。

   (Syslog メカニズムを使用するコネクタによっては、 Syslog以外のテーブルにデータが格納される場合があります。 Microsoft Sentinel データ コネクタのリファレンス ページで、コネクタのセクションを参照 してください)。

2. 「Azure Monitor ログ クエリでの関数の使用」で説明されているクエリ パラメーターを使用して、Syslog メッセージを解析できます。 その後、新しい Log Analytics 関数としてクエリを保存し、新しいデータ型として使用できます。

異常な SSH ログイン検出用に Syslog コネクタを構成する

Microsoft Sentinel は Syslog データに機械学習 (ML) を適用して、異常な Secure Shell (SSH) ログイン アクティビティを識別できます。 シナリオには以下が含まれます。

• あり得ない移動 - 2 つの成功したログイン イベントが、この 2 つのログイン イベントの期間内に到達できない 2 つの場所で発生した場合。

• 予期しない場所 - 成功したログイン イベントの発生した場所が疑わしい場合。 たとえば、最近検出されることのなかった場所などです。

この検出には、Syslog データ コネクタの特定の構成が必要です。

1. 上記の Log Analytics エージェントの構成 の手順 2 で、監視する機能として auth と authpriv の両方が選択されていること、およびすべての重大度が選択されていることを確認します。

2. Syslog 情報が収集されるまで、十分な時間をかけます。 次に、 Microsoft Sentinel - ログに移動し、次のクエリをコピーして貼り付けます。

   Syslog
   | where Facility in ("authpriv","auth")
   | extend c = extract( "Accepted\\s(publickey|password|keyboard-interactive/pam)\\sfor ([^\\s]+)",1,SyslogMessage)
   | where isnotempty(c)
   | count 
   

   必要に応じて 時間範囲 を変更し、[ 実行] を選択します。

   結果の数が 0 の場合は、コネクタの構成を確認し、クエリに指定した期間内に監視対象のコンピュータで成功したログイン アクティビティがあったことを確認します。

   結果の数が 0 より大きい場合、Syslog データは、異常な SSH ログインの検出用に適しています。 この検出は、 Analytics>Rule テンプレート>(プレビュー) の異常な SSH ログイン検出から有効にします。

次のステップ

このドキュメントでは、Syslog オンプレミス アプライアンスを Microsoft Sentinel に接続する方法について説明しました。 Microsoft Sentinel の詳細については、次の記事を参照してください。

• データと潜在的な脅威を可視化する方法について説明します。
• Microsoft Sentinel で脅威の検出を開始します。
• ワークブックを使用して データを監視します。