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

[アーティクル]
03/25/2023

注意

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

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

たとえば、ログが Microsoft Sentinel の Syslog または共通セキュリティログテーブルに表示されない場合、データソースの接続に失敗しているか、データが取り込まれない別の原因が発生している可能性があります。

コネクタの展開が失敗した場合に発生する他の現象としては、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
Syslog

CEF 接続の検証

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

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

次の前提条件を満たしていることを確認します。
- ログフォワーダーマシンに対する昇格されたアクセス許可 (sudo) が必要です。
- ログフォワーダーマシンに python 2.7 または 3 がインストールされている必要があります。 python --version コマンドを使用して確認してください。
- 場合によっては、プロセスの間にワークスペース ID とワークスペースの主キーが必要になることがあります。それらはワークスペースリソースの [エージェント管理] で確認できます。
Microsoft Sentinel ナビゲーションメニューから [ログ] を開きます。 CommonSecurityLog スキーマを使用して、セキュリティソリューションからログが届いているかどうかを確認するクエリを実行します。

ログが Log Analytics に表示されるようになるまで、最大 20 分かかる場合があります。
クエリの結果がまったく表示されない場合は、セキュリティソリューションからイベントが生成されていることを確認するか、なんらかのイベントを生成してみてください。それらのイベントが、指定した Syslog フォワーダーマシンに転送されていることを確認します。
ログフォワーダーで次のスクリプトを実行し (プレースホルダーをワークスペース ID に置き換えます)、セキュリティソリューション、ログフォワーダー、および Microsoft Sentinel 間の接続を確認します。デーモンが適切なポートでリッスンしていること、転送が適切に構成されていること、デーモンと 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]
```
- "コンピューター" フィールドのマッピングに関する問題を修正するためのコマンドを実行するよう指示するメッセージが表示される場合があります。詳細については、検証スクリプトの説明を参照してください。
- Cisco ASA ファイアウォールログの解析に関する問題を修正するためのコマンドを実行するよう指示するメッセージが表示される場合があります。詳細については、検証スクリプトの説明を参照してください。

CEF 検証スクリプトの説明

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

rsyslog デーモン

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

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

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

<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>

次のコマンドを使用して、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]
```
次のコマンドを使用して、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]
```
マシンのセキュリティにネットワークトラフィックをブロックするような改良 (ホストファイアウォールなど) がなされているかどうかを確認します。
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
```

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

service rsyslog restart

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

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

netstat -an | grep 25226
```
Syslog デーモンによりポート 514 でデータが受信されていること、およびエージェントによりポート 25226 でデータが受信されていることを確認します。
```
sudo tcpdump -A -ni any port 514 -vv

sudo tcpdump -A -ni any port 25226 -vv
```
MOCK データを localhost のポート 514 に送信します。このデータは、Microsoft Sentinel ワークスペースから次のクエリを実行することによって観察できます。
```
CommonSecurityLog
| where DeviceProduct == "MOCK"
```

syslog-ng デーモン

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

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

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

<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>

次のコマンドを使用して、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]
```
次のコマンドを使用して、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]
```
マシンのセキュリティにネットワークトラフィックをブロックするような改良 (ホストファイアウォールなど) がなされているかどうかを確認します。
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);};
```

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

service syslog-ng restart

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

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

netstat -an | grep 25226
```
Syslog デーモンによりポート 514 でデータが受信されていること、およびエージェントによりポート 25226 でデータが受信されていることを確認します。
```
sudo tcpdump -A -ni any port 514 -vv

sudo tcpdump -A -ni any port 25226 -vv
```
MOCK データを localhost のポート 514 に送信します。このデータは、Microsoft Sentinel ワークスペースから次のクエリを実行することによって観察できます。
```
CommonSecurityLog
| where DeviceProduct == "MOCK"
```

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

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

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

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

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

Syslog データコネクタの設定中は、MMA または OMS エージェントの Microsoft Defender for Cloud の自動プロビジョニング設定を必ずオフにするようにしてください。

データコネクタの設定が完了したら、再びオンにすることができます。
Microsoft Sentinel が、SecurityInsights ソリューションがインストールされている正しい Log Analytics ワークスペースに接続されていることを確認します。

詳細については、手順 1: ログフォワーダーを展開する方法に関するページを参照してください。
少なくとも必要な前提条件を満たすよう、マシンのサイズが正しく設定されていることを確認します。詳細については、CEF の前提条件に関するセクションを参照してください。

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

詳細については、「説明されたデプロイスクリプト」を参照してください。および Azure portal での Syslog の構成。

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

cat /etc/rsyslog.d/95-omsagent.conf

この場合、rsyslog では、以下のような出力が表示されます。このファイルの内容は、Log Analytics ワークスペースクライアントの構成 - Syslog ファシリティ設定画面の Syslog 構成で定義された内容が反映されている必要があります。

OMS Syslog collection for workspace c69fa733-da2e-4cf9-8d92-eee3bd23fe81
auth.=alert;auth.=crit;auth.=debug;auth.=emerg;auth.=err;auth.=info;auth.=notice;auth.=warning  @127.0.0.1:25224
authpriv.=alert;authpriv.=crit;authpriv.=debug;authpriv.=emerg;authpriv.=err;authpriv.=info;authpriv.=notice;authpriv.=warning  @127.0.0.1:25224
cron.=alert;cron.=crit;cron.=debug;cron.=emerg;cron.=err;cron.=info;cron.=notice;cron.=warning  @127.0.0.1:25224
local0.=alert;local0.=crit;local0.=debug;local0.=emerg;local0.=err;local0.=info;local0.=notice;local0.=warning  @127.0.0.1:25224
local4.=alert;local4.=crit;local4.=debug;local4.=emerg;local4.=err;local4.=info;local4.=notice;local4.=warning  @127.0.0.1:25224
syslog.=alert;syslog.=crit;syslog.=debug;syslog.=emerg;syslog.=err;syslog.=info;syslog.=notice;syslog.=warning  @127.0.0.1:25224

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

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

CEF
Syslog

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

まだの場合は、サポートされているバージョンのオペレーティングシステムと Python を使用していることを確認してください。詳細については、CEF の前提条件に関するセクションを参照してください。
仮想マシンが Azure にある場合は、ネットワークセキュリティグループ (NSG) によって、ポート 514 のログクライアント (センダー) からの TCP/UDP 接続が許可されていることを確認します。
パケットが Syslog コレクターに到着していることを確認します。 Syslog コレクターに到着する Syslog パケットをキャプチャするには、次を実行します。
```
tcpdump -Ani any port 514 and host <ip_address_of_sender> -vv
```
次のいずれかの操作を行います。
- パケットが到着していない場合は、NSG セキュリティグループのアクセス許可と Syslog コレクターへのルーティングパスを確認してください。
- パケットが到着している場合は、これらが拒否されていないことを確認します。
拒否されているパケットがある場合は、IP テーブルによって接続がブロックされていないか確認します。

パケットが拒否されていないか確認するには、次を実行します。
```
watch -n 2 -d iptables -nvL
```
CEF サーバーでログが処理されているかどうかを確認します。次のコマンドを実行します。
```
tail -f /var/log/messages or tail -f /var/log/syslog
```
処理されている CEF ログは、プレーンテキストで表示されます。
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 接続がブロックされているか、ファイアウォールのプロセスがブロックされている可能性があります。問題を特定するには、以下の関連する手順を使用します。

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

まだの場合は、サポートされているバージョンのオペレーティングシステムと Python を使用していることを確認してください。詳細については、「Linux マシンまたはアプライアンスを構成する」を参照してください。
仮想マシンが Azure にある場合は、ネットワークセキュリティグループ (NSG) によって、ポート 514 のログクライアント (センダー) からの TCP/UDP 接続が許可されていることを確認します。
パケットが Syslog コレクターに到着していることを確認します。 Syslog コレクターに到着する Syslog パケットをキャプチャするには、次を実行します。
```
tcpdump -Ani any port 514 and host <ip_address_of_sender> -vv
```
次のいずれかの操作を行います。
- パケットが到着していない場合は、NSG セキュリティグループのアクセス許可と Syslog コレクターへのルーティングパスを確認してください。
- パケットが到着している場合は、これらが拒否されていないことを確認します。
拒否されているパケットがある場合は、IP テーブルによって接続がブロックされていないか確認します。

パケットが拒否されていないか確認するには、次を実行します。
```
watch -n 2 -d iptables -nvL
```
Syslog サーバーでログが処理されているかどうかを確認します。次を実行します。
```
tail -f /var/log/messages or tail -f /var/log/syslog
```
処理されている CEF ログは、プレーンテキストで表示されます。
rsyslog サーバーが TCP/UDP ポート 514 でリッスンしていることを確認します。次を実行します。
```
netstat -anp | grep syslog
```

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

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

注意

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

次を実行します。
```
sestatus
```
状態は、次のいずれかの値として報告されます。
- disabled この構成は、Microsoft Sentinel への接続でサポートされています。
- permissive この構成は、Microsoft Sentinel への接続でサポートされています。
- enforced この構成はサポートされていないので、状態を無効にするか、permissive に設定する必要があります。
現在、状態が enforced に設定されている場合は、一時的にオフにして、これがブロックの要因であるかどうかを確認してください。次を実行します。
```
setenforce 0
```
注意

この手順では、サーバーが再起動するまでの間だけ SELinux をオフにします。 SELinux をオフにするために、構成を変更してください。
正常に変更できたかどうかを確認するには、次を実行します。
```
getenforce
```
状態 permissive が返されるはずです。

重要

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

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

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

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

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

ファイアウォールポリシーを有効にしたままにするには、接続を許可するポリシー規則を作成します。必要に応じて、アクティブなファイアウォールを介して 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

アクティブなファイアウォールを介して 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 を実行してください。

CEF
Syslog

この記事のここまでの手順を実行しても問題が解決しない場合は、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 エージェントがブロックされている可能性があります。

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

Syslog コレクターで TCP/UDP ポート 514 にパケットが到着していることを確認します
ローカルログファイル ( /var/log/messages または /var/log/syslog) にログが書き込まれていることを確認します
ポート 25224 で、データパケットが流れていることを確認します
仮想マシンからポート 443 への TCP 経由のアウトバウンド接続があること、または Log Analytics エンドポイントに接続できることを確認します
ファイアウォールポリシーを使用して、Syslog コレクターまたは CEF コレクターから必要な URL にアクセスできることを確認します。詳細については、Log Analytics エージェントのファイアウォール要件に関するページを参照してください。
ワークスペースの仮想マシンの一覧に、Azure 仮想マシンが接続済みとして表示されていることを確認します。

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

次のステップ

この記事のトラブルシューティング手順で問題が解決しない場合は、サポートチケットを開くか、Microsoft Sentinel のコミュニティリソースを使ってください。詳細については、「Microsoft Sentinel の操作に便利なリソース」を参照してください。

Microsoft Sentinel の詳細については、次の記事を参照してください。

Cef および CommonSecurityLog フィールドマッピングについての説明。
データと潜在的な脅威を可視化する方法についての説明。
Microsoft Sentinel を使用した脅威の検出の概要。
ブックを使用してデータを監視する。

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