Troubleshooting
Problem
Syslog リダイレクトは、ログ・ソース ID に関する特定の問題を解決するために使用されるプロトコルです。
Resolving The Problem
- A. Syslog リダイレクト・プロトコルは、どのような場合に使用すればよいのでしょうか?
- B. 制限
- C. Syslog リダイレクト・プロトコルはどのように機能しますか?
- D. シナリオ
- E. ID の正規表現とフォーマット設定ストリングの使用について
A. Syslog リダイレクト・プロトコルは、どのような場合に使用すればよいのでしょうか?
Syslog リダイレクトは、管理者が QRadar に送信された、誤った形式のヘッダーが含まれているイベントを受信する場合、イベント・ソースの有用な ID が含まれていない場合、または 127.0.0.1 や 0.0.0.0 などの内部 IP アドレスまたは予約済み IP アドレスを使用する場合に役立ちます。 Syslog リダイレクトは、QRadar アプライアンスに送信されるすべてのイベントを評価するためのものではありません。このプロトコルは、正当な ID がイベント・ソースによって提供されない特定のユース・ケースに対して追加機能を提供することを目的としているためです。 Syslog リダイレクト・プロトコルを使用して、Syslog フォワーダーまたはロード・バランサーを経由する QRadar 内のすべてのイベントを解析すると、イベントの解析にかかる時間が長くなり、パフォーマンスの問題が発生する可能性があります。
ユース・ケース
RFC3164 または RFC5424 Syslog タイプを使用するログ・ソースからのイベントは、デフォルトで正しく解析されます。 Syslog イベント・ペイロードに非標準ヘッダーが含まれている場合、Syslog リダイレクトを使用して、不正な形式のヘッダーの前にある新しいヘッダーを置き換えることができます。
2. ログ・ソースのヘッダーに誤った ID が指定されている。
イベントを QRadar に転送する中間ホストには、識別可能な Syslog ヘッダーが含まれていない場合があります。 このような場合、ソースからのすべてのイベントが同じログ ソースに着信しているように見えます。 これは、イベント・ソース ( ロード・バランサー、syslog フォワーダー、何らかの形式のログ管理システムなど ) が、イベントを QRadar に転送する前に独自のヘッダーを追加できるためです。 一部の例では、イベントに一般的なプレースホルダー ホスト名が含まれる場合があります。 これらのイベントは複数のソースから発生する場合がありますが、QRadar では同じソースを持つように見えます。
3. ログ・ソースが内部メッセージ・ルーティングを妨害している
QRadar は、内部監査に 127.0.0.1 を使用します。 127.0.0.1 を使用するログ ソースでは、Syslog リダイレクトでこのアドレスを新しい ID に置き換える必要があります。
B. 制限
Syslog リダイレクト・プロトコルは、 QRadar における単一スレッドのプロセスである。 このプロトコルは、 QRadar アプライアンスに送信されるすべての受信イベントを構文解析するために使用するものではなく、置換を必要とするイベントを選択して、誤ったログ・ソース IDを置換することを意図しています。管理者は、ソースからのすべてのイベントを修正する代わりに Syslog リダイレクトを使用しないことをお勧めします。ただし、選択した置換が必要な場合にのみ、イベント・ソースに対してこのプロトコルを利用してください。
C. Syslog リダイレクト・プロトコルはどのように機能しますか?
syslog リダイレクト・プロトコルは、ポート (デフォルトは 517 ) で受信イベントをリッスンします。 指定された正規表現 ( regex ) を使用して、プロトコルはイベント ペイロードから関連情報を抽出し、それをログ・ソース ID として使用します。 ログ・ソース ID の置換は、ECS-EC ( または QRadar 7.3.1 の場合は ECS-EC-INGRES ) のライセンス交付コンポーネントの前のイベント・パイプラインの開始時に行われ、イベントが重複したり、デプロイメント・ライセンスに対して 2 回カウントされたりしないようにします。
重要 : 管理者は、Syslog リダイレクト イベントをポート 514 に送信していないことを確認する必要があります。ポート 517 に送信するようにイベント ソースを構成できない場合は、中間アプライアンスまたは iptables ルールを使用して、これらのイベントをポート 517 に適切にルーティングする必要がある場合があります。
D. シナリオ
複数のデバイスから転送サーバーに送信されるイベントがあるとします。 転送サーバーはポート 517 で QRadar にイベントを送信するように構成され、syslog リダイレクト・ログ・ソースはポート 517 でリッスンするように構成されています。これらの各イベントは、転送サーバーによって生成されているかのように表示されます。 同じ転送サーバーを経由していても、イベント・データを送信している特定のホストからのアクティビティを分析者が掘り下げることができるように、それぞれ固有デバイスから来るイベントを個々のログ・ソースにグループ化できるようにしたいと思います。元のホストを識別するために使用される元の送信元アドレスは、イベント・ペイロード内の name=value のペアです。 次の例では、イベント・ペイロードから「 orig = IP アドレス」を使用しています。 ログ・ソース ID の置換を完了するために使用される正規表現は、orig=(\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3}) です。
syslog リダイレクト・プロトコルでは、次のようなイベントが発生する場合があります。
- 有効な syslog ヘッダーが既に存在する
- 有効なsyslogヘッダーがない
- 指定された正規表現に一致する
- 指定された正規表現に一致しない
有効なヘッダーがない、正規表現に一致する
イベントは、新しいパケット IP でイベント・コレクターに転送されます。 QRadar は、10.199.56.21 のパケット IP でこのイベントを受信します。
受信イベント
<13> 127.0.0.1 forwardinghost1 loc=10814950|time=26Mar2017 14:03:22|action=accept|orig=10.199.56.21 |i/f_dir=inbound|i/f_name=Exp1-1|has_accounting=0|uuid=<51xxxxxx,00xxxxxx,15xxxxxx,00xxxxxx>|product=VPN-1 & FireWall-1|__policy_id_tag=product=VPN-1 & FireWall-1[db_tag={xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx};mgmt=lab1;date=1364192986;policy_name=examplepolicy_cps]|src=10.203.15.141|s_port=41269|dst=10.207.36.152|service=443|proto=tcp|rule=150
転送されたイベント
<13> 127.0.0.1 forwardinghost1 loc=10814950|time=26Mar2017 14:03:22|action=accept|orig=10.199.56.21|i/f_dir=inbound|i/f_name=Exp1-1|has_accounting=0|uuid=<5151aaaa,000102eb,1538c70a,0000ffff>|product=VPN-1 & FireWall-1|__policy_id_tag=product=VPN-1 & FireWall-1[db_tag={xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx};mgmt=fm55lab01;date=1364192986;policy_name=examplepolicy_cps]|src=10.203.15.141|s_port=41269|dst=10.207.36.152|service=443|proto=tcp|rule=150
有効なヘッダ、正規表現に一致する
イベントは、新しい syslog ヘッダーと新しいパケット IP とともにイベント・コレクターに転送されます。 QRadar は、10.199.56.21 のパケット IP でこのイベントを受信します。
受信イベント
<189>Jun 29 16:30:07 Message forwarded from 10.48.225.4: loc=10814950|time=26Mar2013 14:03:22|action=accept|orig=10.199.56.21|i/f_dir=inbound|i/f_name=Exp1-1|has_accounting=0|uuid=<5151aaaa,000102eb,1538c70a,0000ffff>|product=VPN-1 & FireWall-1|__policy_id_tag=product=VPN-1 & FireWall-1[db_tag={xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx};mgmt=lab1;date=1364192986;policy_name=examplepolicy_cps]|src=10.203.15.141|s_port=41269|dst=10.207.36.152|service=443|proto=tcp|rule=150
転送されたイベント
<55>May 23 10:56:31 10.199.56.21 <189>Jun 29 16:30:07 Message forwarded from 10.48.225.4: loc=10814950|time=26Mar2013 14:03:22|action=accept|orig=10.199.56.21|i/f_dir=inbound|i/f_name=Exp1-1|has_accounting=0|uuid=<5151aaaa,000102eb,1538c70a,0000ffff>|product=VPN-1 & FireWall-1|__policy_id_tag=product=VPN-1 & FireWall-1[db_tag={xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx};mgmt=lab1;date=1364192986;policy_name=examplepolicy_cps]|src=10.203.15.141|s_port=41269|dst=10.207.36.152|service=443|proto=tcp|rule=150
有効なヘッダー、正規表現に一致しない
イベントはそのままイベント・コレクターに入り、syslog として取得されます。 QRadar は、このイベントを syslog として受信します。パケット IP は 10.48.255.4 です。
受信イベント
<189>Jun 29 16:30:07 Message forwarded from 10.48.225.4: loc=10814950|time=26Mar2013 14:03:22|action=accep|i/f_dir=inbound|i/f_name=Exp1-1|has_accounting=0|uuid=<5151aaaa,000102eb,1538c70a,0000ffff>|product=
VPN-1 & FireWall-1|__policy_id_tag=product=VPN-1 & FireWall-1[db_tag={xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx};mgmt=lab1;date=1364192986|policy_name=examplepolicy_cps]|src=10.203.15.141|s_port=41269|dst=10.207.36.152|service=443|proto=tcp|rule=150
転送されたイベント
<189>Jun 29 16:30:07 Message forwarded from 10.48.225.4: loc=10814950|time=26Mar2013 14:03:22|action=accep|i/f_dir=inbound|i/f_name=Exp1-1|has_accounting=0|uuid=<5151aaaa,000102eb,1538c70a,0000ffff>|product=
VPN-1 & FireWall-1|__policy_id_tag=product=VPN-1 & FireWall-1[db_tag={xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx};mgmt=lab1;date=1364192986;policy_name=examplepolicy_cps]|src=10.203.15.141|s_port=41269|dst=10.207.36.152|service=443|proto=tcp|rule=150
E. ID の正規表現とフォーマット設定ストリングの使用について
ID の正規表現
ペイロード情報のどの値をログ・ソース ID として使用するかを選択したら、ペイロードからそれを解析するための正規表現を作成できます。 上記の例では、「 |orig=10.199.56.21| 」のようなログの発信元 IP アドレスが必要でした。 IP を抽出するには、orig=(\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3}) をログ・ソース ID の正規表現として使用します。
実際のアドレスを含むパターンの部分を括弧で囲んでいることに注意してください。括弧で囲まれた部分はすべてキャプチャ・グループ 1 です。キャプチャー・グループは、前にバックスラッシュを付けた番号で参照でき、フォーマット設定ストリングで使用できます。 つまり、\1 は \d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3} に一致するペイロードの部分を表します。 \1 はデフォルト値でもあります。
正規表現は、複数のキャプチャー・グループを持つこともできます。 例えば、ログ・ソース ID に時刻を含めることができます。 ログ・ソース ID 正規表現として、time = (\w +). * ?orig = (\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3}) を使用します。
この場合、\1 は「time =」の後の最初の単語と一致し、\2 は IP と一致します。
ここで注意しなければならないのは、正規表現が広すぎると、望ましくない結果がソースの下にグループ化される可能性があることです。逆に、正規表現が正確すぎると、必要な値がすべて含まれないことがあります。お客様の環境に最適な正規表現を選択するよう、慎重に判断してください。
フォーマット設定ストリング
フォーマット設定ストリングは、キャプチャー・グループを任意の順番で任意の区切り文字（例: \1 \2 3, \2+CAHI1, \1-CAHI2, \1::\2::###3, etc)で組み合わせて、ログ・ソース ID を作成することが可能です。これは、自動検出されたデバイスと同じ規則に従って、ログ・ソース名として使用されます。デバイス@ <フォーマット・ストリング>.
例
CheckPoint ペイロードを使用した例 :<189>Jun 29 16:30:07 Message forwarded from 10.48.225.4: loc=10814950|time=26Mar2013 14:03:22|action=accept|orig=10.199.56.21|i/f_dir=inbound|i/f_name=Exp1-1|has_accounting=0|uuid=<51xxxxxx,00xxxxxx,15xxxxxx,00xxxxxx>|product=VPN-1 & FireWall-1|__policy_id_tag=product=VPN-1 & FireWall-1[db_tag={xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx};mgmt=lab1;date=1364192986;policy_name=examplepolixy_cps]|src=10.203.15.141|s_port=41269|dst=10.207.36.152|service=443|proto=tcp|rule=150
regex: orig=(\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3})
format: \1 LSI: Check Point @ 10.199.56.21
複数のキャプチャー・グループを使用した代替例
以下の例は、キャプチャー・グループを使用してログ・ソース ID ( LSI ) をフォーマットする方法を示しています。 フォーマット設定ストリングにより、プロトコルは $PIP$ タグを使用してログ・ソース名のパケット・ソースを使用することもできます。 これにより、LSI に転送サーバー・アドレスを組み込むことができます。
- キャプチャー・グループの正規表現 :
time=(\w+).*?orig=(\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3})- フォーマット :
\1 :: \2
ログ・ソース ID を最初に時間としてログに記録し、次に発信元 IP アドレスをログに記録する :Check Point @ 26Mar2013 :: 10.199.56.21 - フォーマット :
\2 :: \1
ログ・ソース ID を最初に発信元 IP アドレスとしてログに記録し、次に時間をログに記録する :Check Point @ 10.199.56.21 :: 26Mar2013 - フォーマット :
\1-\2-$PIP$
ログ・ソース ID を時間、発信元 IP アドレス、パケット・アドレスとしてログに記録する :Check Point @ 26Mar2013-10.199.56.21-10.48.225.4
- フォーマット :
Related Information
Was this topic helpful?
Document Information
Modified date:
30 May 2023
UID
ibm16967957