次の方法で共有

[非推奨] CEF または Syslog データ コネクタのトラブルシューティング

  • [アーティクル]

重要

多くのアプライアンスおよびデバイスからのログ収集が、AMA 経由の Common Event Format (CEF)、AMA 経由の Syslog、または Microsoft Sentinel の AMA データ コネクタ経由のカスタム ログでサポートされるようになりました。 詳細については、「Microsoft Sentinel データ コネクタを見つける」を参照してください。

注意事項

この記事では、サービス終了 (EOL) 状態になった Linux ディストリビューションである CentOS について説明します。 適宜、使用と計画を検討してください。 詳細については、「CentOS のサポート終了に関するガイダンス」を参照してください。

この記事では、Microsoft Sentinel の CEF または Syslog データ コネクタを検証してトラブルシューティングするための一般的な方法について説明します。

たとえば、ログ メッセージが Syslog または CommonSecurityLog テーブルに表示されない場合、データ ソースが正しく接続されていない可能性があります。 データが届いていない理由は他に存在している可能性もあります。

コネクタのデプロイが失敗した場合に発生する他の現象としては、security_events.conf または security-omsagent.config.conf ファイルのいずれかが欠落している場合や、rsyslog サーバーがポート 514 をリッスンしていない場合などがあります。

詳細については、「Common Event Format を使用して外部ソリューションを接続する」と、「Syslog を使用して Linux ベースのソースからデータを収集する」を参照してください。

ドキュメントに記載されている手順とは異なる方法でコネクタをデプロイし、問題が発生している場合は、そのデプロイを破棄して、ドキュメントに記載されている手順に従って最初からやり直すことをお勧めします。

この記事では、Log Analytics エージェントを使用して CEF コネクタまたは Syslog コネクタのトラブルシューティングを行う方法について説明します。 Azure Monitor エージェント (AMA) を使用した CEF ログの取り込みに関連するトラブルシューティング情報については、AMA コネクタを使用した Common Event Format (CEF) の手順を確認してください。

重要

2023 年 2 月 28 日に、CommonSecurityLog テーブル スキーマの変更を導入しました。 この変更に伴い、カスタム クエリの確認と更新が必要になる場合があります。 詳細については、このブログ投稿の推奨アクションに関するセクションを参照してください。 すぐに使用できるコンテンツ (検出、ハンティング クエリ、ブック、パーサーなど) が、Microsoft Sentinel によって更新されました。

この記事の使用方法

この記事の情報が Syslog にのみ関連する場合、または CEF コネクタにのみ関連する場合、それは個別のタブに表示されます。 コネクタの種類に対して、正しいタブの指示を使用していることを確認します。

たとえば、CEF コネクタのトラブルシューティングを行う場合、 CEF 接続の検証から始める必要があります。 Syslog コネクタのトラブルシューティングを行う場合、「データ コネクタに関する前提条件を確認する」から作業を開始してください。

CEF 接続の検証

ログ フォワーダーをデプロイし、CEF メッセージを送信するようにセキュリティ ソリューションを構成したら、このセクションの手順を使用してセキュリティ ソリューションと Microsoft Sentinel の間の接続を検証します。

この手順は CEF 接続にのみ関連し、 Syslog 接続には関係ありません。

  1. 次の前提条件を満たしていることを確認します。

    • ログ フォワーダー マシンに対する昇格されたアクセス許可 (sudo) が必要です。

    • ログ フォワーダー マシンに python 2.7 または 3 がインストールされている必要があります。 python --version コマンドを使用して確認してください。

    • このプロセスの途中でワークスペース ID とワークスペース プライマリ キーが必要になるかもしれません。 それらはワークスペース リソースの [エージェント管理] で確認できます。

  2. Microsoft Sentinel ナビゲーション メニューから [ログ] を開きます。 CommonSecurityLog スキーマを使用してクエリを実行し、セキュリティ ソリューションからログが届いているかどうかを確認します。

    ログが Log Analytics に表示されるようになるには、約 20 分かかる場合があります。

  3. クエリの結果が何も表示されない場合は、セキュリティ ソリューションがログ メッセージを生成していることを確認します。 または、ログ メッセージを生成するためのアクションをいくつか実行してみて、指定された Syslog フォワーダー マシンにメッセージが転送されることを確認します。

  4. セキュリティ ソリューション、ログ フォワーダー、Microsoft Sentinel の間の接続を確認するには、ログ フォワーダーで次のスクリプトを実行します (プレースホルダーはワークスペース ID に置き換えます)。 デーモンが適切なポートでリッスンしていること、転送が適切に構成されていること、デーモンと Log Analytics エージェントとの間の通信がブロックされていないことが、このスクリプトによって確認されます。 また、モック メッセージ "TestCommonEventFormat" を送信することで、エンドツーエンドの接続が確認されます。 

    sudo wget -O cef_troubleshoot.py https://raw.githubusercontent.com/Azure/Azure-Sentinel/master/DataConnectors/CEF/cef_troubleshoot.py&&sudo python cef_troubleshoot.py [WorkspaceID]

    • Computer フィールドのマッピングに関する問題を修正するためのコマンドを実行するように求めるメッセージが表示される場合があります。 詳細については、検証スクリプトの説明を参照してください。

    • Cisco ASA ファイアウォール ログの解析に関する問題を修正するためのコマンドを実行するように求めるメッセージが表示される場合があります。 詳細については、検証スクリプトの説明を参照してください。

CEF 検証スクリプトの説明

次のセクションでは、 rsyslog デーモンと syslog-ng デーモンの CEF 検証スクリプトについて説明します。

rsyslog デーモン

rsyslog デーモンの場合、CEF 検証スクリプトは次のチェックを実行します。

  1. ファイル
    /etc/opt/microsoft/omsagent/[WorkspaceID]/conf/omsagent.d/security_events.conf
    が存在し、有効であることを確認します。

  2. このファイルに次のテキストが含まれていることを確認します。

    <source>
    type syslog
    port 25226
    bind 127.0.0.1
    protocol_type tcp
    tag oms.security
    format /(?<time>(?:\w+ +){2,3}(?:\d+:){2}\d+|\d{4}-\d{2}-\d{2}T\d{2}:\d{2}:\d{2}.[\w\-\:\+]{3,12}):?\s*(?:(?<host>[^: ]+) ?:?)?\s*(?<ident>.*CEF.+?(?=0\|)|%ASA[0-9\-]{8,10})\s*:?(?<message>0\|.*|.*)/
    <parse>
        message_format auto
    </parse>
</source>

<filter oms.security.**>
    type filter_syslog_security
</filter>

  3. 次のコマンドを使用して、Cisco ASA ファイアウォール イベントの解析が想定どおりに構成されていることを確認します。

    grep -i "return ident if ident.include?('%ASA')" /opt/microsoft/omsagent/plugin/security_lib.rb

    • 解析に問題がある場合、スクリプトは次のコマンドを手動で実行するよう求めるエラー メッセージを生成します (プレースホルダーはワークスペース ID に置き換えます)。 このコマンドにより、正しい解析が保証され、エージェントが再起動されます。

      # Cisco ASA parsing fix
sed -i "s|return '%ASA' if ident.include?('%ASA')|return ident if ident.include?('%ASA')|g" /opt/microsoft/omsagent/plugin/security_lib.rb && sudo /opt/microsoft/omsagent/bin/service_control restart [workspaceID]

  4. 次のコマンドを使用して、Syslog ソースの "コンピューター" フィールドが、Log Analytics エージェントで正しくマップされていることを確認します。

    grep -i "'Host' => record\['host'\]"  /opt/microsoft/omsagent/plugin/filter_syslog_security.rb

    • マッピングに問題がある場合、スクリプトは次のコマンドを手動で実行するよう求めるエラー メッセージを生成します (プレースホルダーはワークスペース ID に置き換えます)。 このコマンドにより、正しいマッピングが保証され、エージェントが再起動されます。

      # Computer field mapping fix
sed -i -e "/'Severity' => tags\[tags.size - 1\]/ a \ \t 'Host' => record['host']" -e "s/'Severity' => tags\[tags.size - 1\]/&,/" /opt/microsoft/omsagent/plugin/filter_syslog_security.rb && sudo /opt/microsoft/omsagent/bin/service_control restart [workspaceID]

  5. マシンのセキュリティにネットワーク トラフィックをブロックするような改良 (ホスト ファイアウォールなど) がなされているかどうかを確認します。

  6. CEF として識別されたメッセージを TCP ポート 25226 で Log Analytics エージェントに送信するよう、syslog デーモン (rsyslog) が適切に構成されていることを確認します。

    構成ファイル: /etc/rsyslog.d/security-config-omsagent.conf

    if $rawmsg contains "CEF:" or $rawmsg contains "ASA-" then @@127.0.0.1:25226

  7. Syslog デーモンと Log Analytics エージェントを再起動します。

    service rsyslog restart

/opt/microsoft/omsagent/bin/service_control restart [workspaceID]

  8. 必要な接続が確立されていることを確認します。データの受信には TCP 514 が、また Syslog デーモンと Log Analytics エージェントとの間の内部通信には TCP 25226 が使用されます。

    netstat -an | grep 514

netstat -an | grep 25226

  9. Syslog デーモンによりポート 514 でデータが受信されていること、およびエージェントによりポート 25226 でデータが受信されていることを確認します。

    sudo tcpdump -A -ni any port 514 -vv

sudo tcpdump -A -ni any port 25226 -vv

  10. MOCK データを localhost のポート 514 に送信します。 このデータは、Microsoft Sentinel ワークスペースから次のクエリを実行することによって観察できます。

    CommonSecurityLog
| where DeviceProduct == "MOCK"

syslog-ng デーモン

rsyslog デーモンの場合、CEF 検証スクリプトは次のチェックを実行します。

  1. ファイル
    /etc/opt/microsoft/omsagent/[WorkspaceID]/conf/omsagent.d/security_events.conf
    が存在し、有効であることを確認します。

  2. このファイルに次のテキストが含まれていることを確認します。

    <source>
    type syslog
    port 25226
    bind 127.0.0.1
    protocol_type tcp
    tag oms.security
    format /(?<time>(?:\w+ +){2,3}(?:\d+:){2}\d+|\d{4}-\d{2}-\d{2}T\d{2}:\d{2}:\d{2}.[\w\-\:\+]{3,12}):?\s*(?:(?<host>[^: ]+) ?:?)?\s*(?<ident>.*CEF.+?(?=0\|)|%ASA[0-9\-]{8,10})\s*:?(?<message>0\|.*|.*)/
    <parse>
        message_format auto
    </parse>
</source>

<filter oms.security.**>
    type filter_syslog_security
</filter>

  3. 次のコマンドを使用して、Cisco ASA ファイアウォール イベントの解析が想定どおりに構成されていることを確認します。

    grep -i "return ident if ident.include?('%ASA')" /opt/microsoft/omsagent/plugin/security_lib.rb

    • 解析に問題がある場合、スクリプトは次のコマンドを手動で実行するよう求めるエラー メッセージを生成します (プレースホルダーはワークスペース ID に置き換えます)。 このコマンドにより、正しい解析が保証され、エージェントが再起動されます。

      # Cisco ASA parsing fix
sed -i "s|return '%ASA' if ident.include?('%ASA')|return ident if ident.include?('%ASA')|g" /opt/microsoft/omsagent/plugin/security_lib.rb && sudo /opt/microsoft/omsagent/bin/service_control restart [workspaceID]

  4. 次のコマンドを使用して、Syslog ソースの "コンピューター" フィールドが、Log Analytics エージェントで正しくマップされていることを確認します。

    grep -i "'Host' => record\['host'\]"  /opt/microsoft/omsagent/plugin/filter_syslog_security.rb

    • マッピングに問題がある場合、スクリプトは次のコマンドを手動で実行するよう求めるエラー メッセージを生成します (プレースホルダーはワークスペース ID に置き換えます)。 このコマンドにより、正しいマッピングが保証され、エージェントが再起動されます。

      # Computer field mapping fix
sed -i -e "/'Severity' => tags\[tags.size - 1\]/ a \ \t 'Host' => record['host']" -e "s/'Severity' => tags\[tags.size - 1\]/&,/" /opt/microsoft/omsagent/plugin/filter_syslog_security.rb && sudo /opt/microsoft/omsagent/bin/service_control restart [workspaceID]

  5. マシンのセキュリティにネットワーク トラフィックをブロックするような改良 (ホスト ファイアウォールなど) がなされているかどうかを確認します。

  6. CEF として識別 (正規表現を使用) されたメッセージを TCP ポート 25226 で Log Analytics エージェントに送信するよう、syslog デーモン (syslog-ng) が適切に構成されていることを確認します。

    • 構成ファイル: /etc/syslog-ng/conf.d/security-config-omsagent.conf

      filter f_oms_filter {match(\"CEF\|ASA\" ) ;};destination oms_destination {tcp(\"127.0.0.1\" port(25226));};
log {source(s_src);filter(f_oms_filter);destination(oms_destination);};

  7. Syslog デーモンと Log Analytics エージェントを再起動します。

    service syslog-ng restart

/opt/microsoft/omsagent/bin/service_control restart [workspaceID]

  8. 必要な接続が確立されていることを確認します。データの受信には TCP 514 が、また Syslog デーモンと Log Analytics エージェントとの間の内部通信には TCP 25226 が使用されます。

    netstat -an | grep 514

netstat -an | grep 25226

  9. Syslog デーモンによりポート 514 でデータが受信されていること、およびエージェントによりポート 25226 でデータが受信されていることを確認します。

    sudo tcpdump -A -ni any port 514 -vv

sudo tcpdump -A -ni any port 25226 -vv

  10. MOCK データを localhost のポート 514 に送信します。 このデータは、Microsoft Sentinel ワークスペースから次のクエリを実行することによって観察できます。

    CommonSecurityLog
| where DeviceProduct == "MOCK"

データ コネクタの前提条件を確認する

次のセクションを使用して、CEF または Syslog データ コネクタの前提条件を確認します。

CEF コレクターとしての Azure 仮想マシン

Azure 仮想マシンを CEF コレクターとして使用している場合は、次のことを確認してください。

  • Common Event Format データ コネクタの Python スクリプトをデプロイする前に、仮想マシンが既に既存の Log Analytics ワークスペースに接続されていないことを確認してください。 この情報は、Syslog ワークスペースに接続されている VM が [接続済み] と表示されている、Log Analytics ワークスペースの仮想マシンの一覧にあります。

  • Microsoft Sentinel が、SecurityInsights ソリューションがインストールされている正しい Log Analytics ワークスペースに接続されていることを確認します。

    詳細については、手順 1: ログ フォワーダーを展開する方法に関するページを参照してください。

  • 少なくとも必要な前提条件を満たすよう、マシンのサイズが正しく設定されていることを確認します。 詳細については、CEF の前提条件に関するセクションを参照してください。

オンプレミスまたは Azure 以外の仮想マシン

データ コネクタにオンプレミス マシンまたは Azure 以外の仮想マシンを使用している場合は、以下のようにしてサポートされている Linux オペレーティング システムの新規インストールでインストール スクリプトを実行済みであることを確認してください。

ヒント

このスクリプトは、Microsoft Sentinel の Common Event Format のデータ コネクタ ページで取得することもできます。

sudo wget -O cef_installer.py https://raw.githubusercontent.com/Azure/Azure-Sentinel/master/DataConnectors/CEF/cef_installer.py&&sudo python cef_installer.py <WorkspaceId> <Primary Key>

CEF ファシリティとログの重要度の収集を有効にする

Syslog サーバー (rsyslog または syslog-ng) は、関連する構成ファイルで定義されているすべてのデータを転送します。これには、Log Analytics ワークスペースで定義されている設定が自動的に設定されます。

Microsoft Sentinel に取り込むファシリティと重要度のログ レベルに関する詳細を追加するようにしてください。 構成プロセスには約 20 分かかる場合があります。

詳細については、「説明されたデプロイ スクリプト」を参照してください。

たとえば、rsyslog サーバーの場合は、次のコマンドを実行して、Syslog 転送の現在の設定を表示し、構成ファイルへの変更を確認します。

cat /etc/rsyslog.d/security-config-omsagent.conf

この場合、rsyslog では、以下のような出力が表示されます。

if $rawmsg contains "CEF:" or $rawmsg contains "ASA-" then @@127.0.0.1:25226

オペレーティング システムの問題のトラブルシューティング

このセクションでは、オペレーティング システムの構成に起因する問題をトラブルシューティングする方法について説明します。

オペレーティング システムの問題のトラブルシューティング方法:

  1. まだの場合は、サポートされているバージョンのオペレーティング システムと Python を使用していることを確認してください。 詳細については、CEF の前提条件に関するセクションを参照してください。

  2. 仮想マシンが Azure にある場合は、ネットワーク セキュリティ グループ (NSG) によって、ポート 514 のログ クライアント (センダー) からの TCP/UDP 接続が許可されていることを確認します。

  3. パケットが Syslog コレクターに到着していることを確認します。 Syslog コレクターに到着する Syslog パケットをキャプチャするには、次を実行します。

    tcpdump -Ani any port 514 and host <ip_address_of_sender> -vv

  4. 次のいずれかの操作を行います。

    • パケットが一つも表示されない場合は、NSG セキュリティ グループのアクセス許可と Syslog コレクターへのルーティング パスを確認します。

    • パケットが表示される場合は、それらが拒否されていないことを確認します。

    拒否されているパケットがある場合は、IP テーブルによって接続がブロックされていないことを確認します。

    パケットが拒否されていないことを確認するには、次を実行します。

    watch -n 2 -d iptables -nvL

  5. CEF サーバーでログが処理されているかどうかを確認します。 次のコマンドを実行します。

    tail -f /var/log/messages or tail -f /var/log/syslog

    処理されている CEF ログは、プレーン テキストで表示されます。

  6. rsyslog サーバーが TCP/UDP ポート 514 でリッスンしていることを確認します。 次を実行します。

    netstat -anp | grep syslog

    Syslog コレクターに送信されている CEF または ASA ログがある場合は、TCP ポート 25226 で接続が確立されていることが確認できます。

    次に例を示します。

    0 127.0.0.1:36120 127.0.0.1:25226 ESTABLISHED 1055/rsyslogd

    接続がブロックされている場合、OMS エージェントへの SELinux 接続がブロックされているか、ファイアウォールのプロセスがブロックされている可能性があります。 この先の関連手順を使用して問題を特定します。

SELinux による OMS エージェントへの接続のブロック

この手順では、SELinux が現在 permissive 状態にあるかどうか、または OMS エージェントへの接続をブロックしているかどうかを確認する方法について説明します。 この手順は、オペレーティングシステムが RedHat または CentOS からのディストリビューションであり、CEF と Syslog データ コネクタの両方で使用されている場合に関連します。

注意

Microsoft Sentinel の CEF および Syslog のサポートには、FIPS のセキュリティ強化のみが含まれます。 SELinux や CIS などの他のセキュリティ強化方法は、現在サポートされていません。

  1. 次を実行します。

    sestatus

    状態は、次のいずれかの値として報告されます。

    • disabled. この構成は、Microsoft Sentinel への接続でサポートされています。
    • permissive. この構成は、Microsoft Sentinel への接続でサポートされています。
    • enforced. この構成はサポートされていないので、状態を無効にするか、permissive に設定する必要があります。

  2. 現在、状態が enforced に設定されている場合は、一時的にオフにして、これがブロックの要因であるかどうかを確認してください。 次を実行します。

    setenforce 0

    注意

    この手順では、サーバーが再起動するまでの間だけ SELinux をオフにします。 SELinux をオフにするために、構成を変更してください。

  3. 正常に変更できたかどうかを確認するには、次を実行します。

    getenforce

    状態 permissive が返されるはずです。

重要

この設定の更新は、システムを再起動すると失われます。 この設定を永久に permissive に更新するには、SELINUX の値を SELINUX=permissive に変更して、 /etc/selinux/config ファイルを修正してください。

詳細については、RedHat のドキュメントを参照してください。

ブロックされたファイアウォール ポリシー

この手順では、ファイアウォール ポリシーによって Rsyslog デーモンから OMS エージェントへの接続がブロックされているかどうかを確認する方法と、必要に応じて無効にする方法について説明します。 この手順は、CEF と Syslog の両方のデータ コネクタに関連しています。

  1. 次のコマンドを実行して、IP テーブルに拒否があるかどうかを確認します。これは、ファイアウォール ポリシーによってドロップされたトラフィックを示します。

    watch -n 2 -d iptables -nvL

  2. ファイアウォール ポリシーを有効にしたままにするには、接続を許可するポリシー規則を作成します。 必要に応じて、アクティブなファイアウォールを介して TCP/UDP ポート 25226 および 25224 を許可する規則を追加します。

    次に例を示します。

    Every 2.0s: iptables -nvL                      rsyslog: Wed Jul  7 15:56:13 2021

Chain INPUT (policy ACCEPT 6185K packets, 2466M bytes)
 pkts bytes target     prot opt in     out     source               destination


Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination


Chain OUTPUT (policy ACCEPT 6792K packets, 6348M bytes)
 pkts bytes target     prot opt in     out     source               destination

  3. アクティブなファイアウォールを介して TCP/UDP ポート 25226 および 25224 を許可する規則を作成するには、必要に応じて規則を追加します。

    1. ファイアウォール ポリシー エディターをインストールするには、次を実行します。

      yum install policycoreutils-python

    2. ファイアウォール ポリシーにファイアウォール規則を追加します。 次に例を示します。

      sudo firewall-cmd --direct --add-rule ipv4 filter INPUT 0 -p tcp --dport 25226  -j ACCEPT
sudo firewall-cmd --direct --add-rule ipv4 filter INPUT 0 -p udp --dport 25224  -j ACCEPT
sudo firewall-cmd --direct --add-rule ipv4 filter INPUT 0 -p tcp --dport 25224  -j ACCEPT

    3. 例外が追加されていることを確認します。 次を実行します。

      sudo firewall-cmd --direct --get-rules ipv4 filter INPUT

    4. ファイアウォールを再度読み込みます。 次を実行します。

      sudo firewall-cmd --reload

注意

ファイアウォールを無効にするには、sudo systemctl disable firewalld を実行してください。

この記事のここまでの手順で問題が解決しない場合は、OMS エージェントと Microsoft Sentinel ワークスペースの間に接続の問題があるかもしれません。

このような場合は、次を確認してトラブルシューティングを続行します。

  • Syslog コレクターで TCP/UDP ポート 514 にパケットが到着していることを確認します

  • ローカル ログ ファイル ( /var/log/messages または /var/log/syslog) にログが書き込まれていることを確認します

  • ポート 25226 で、データ パケットが流れていることを確認します

  • 仮想マシンからポート 443 への TCP 経由のアウトバウンド接続があること、または Log Analytics エンドポイントに接続できることを確認します

  • ファイアウォール ポリシーを使用して、CEF コレクターから必要な URL にアクセスできることを確認します。 詳細については、Log Analytics エージェントのファイアウォール要件に関するページを参照してください。

次のコマンドを実行して、エージェントが Azure に正常に接続できているのか、または OMS エージェントから Log Analytics ワークスペースへの接続がブロックされているのかを確認します。

Heartbeat
 | where Computer contains "<computername>"
 | sort by TimeGenerated desc

エージェントが正常に接続できている場合は、ログ エントリが返されます。 されなかった場合、OMS エージェントがブロックされている可能性があります。