web-dev-qa-db-ja.com

OSSECWindowsエージェントが構成の同期に失敗する

これは過去数日間の煩わしさを証明しており、根本的な原因はまだ解明されていません。

ラボでは、OSSECサーバーアプライアンスとWindows 7 x64 EnterpriseSP1クライアントの2つの仮想マシンをセットアップしました。

どちらも非常にうまく機能しているようです彼らが独自のことをするとき。 Windowsクライアントに広範な構成ファイルがある場合、エージェントはそれを読み取り、必要な処理を実行します。

この問題は、構成を一元化しようとすると発生します「マネージャー」またはOSSECサーバーアプライアンスに。

[root@ossec etc]# md5sum /var/ossec/etc/shared/agent.conf
9cc4c937f4eae011ecbccf4468973133  /var/ossec/etc/shared/agent.conf
[root@ossec etc]# /var/ossec/bin/agent_control -i 004

OSSEC HIDS agent_control. Agent information:
   Agent ID:   004
   Agent Name: ABC
   IP address: 192.168.0.93
   Status:     Active

   Operating system:    Microsoft Windows 7 Enterprise Edition Professional ..
   Client version:      OSSEC HIDS v2.9.0 / cd66e10fca4cc1dc4c459a1f05f9b2d1
   Last keep alive:     Sat Oct  7 22:52:09 2017

   Syscheck last started  at: Sat Oct  7 21:35:12 2017
   Rootcheck last started at: Sat Oct  7 22:27:19 2017
[root@ossec etc]#

当然のことながら、構成は同じバージョンではありません。

アプライアンスとWindowsエージェントの両方を再起動する（そして数分待つ）という簡単な修正は、そうではないことがわかりました。

ドキュメントを読んで、エージェントが一元化された構成をマージしようとすることを理解しました。

<agent_config name="ABC">
    <localfile>
        <location>/var/log/my.log2</location>
        <log_format>syslog2</log_format>
    </localfile>
</agent_config>


<agent_config os="Linux">
    <localfile>
        <location>/var/log/my.log2</location>
        <log_format>syslog</log_format>
    </localfile>
</agent_config>


<agent_config os="Windows">
 <!-- This is a test config -->

  <!-- One entry for each file/Event log to monitor. -->
  <localfile>
    <location>Application</location>
    <log_format>eventlog</log_format>
  </localfile>

  <!-- Additional contents are in here. -->

  <active-response>
    <disabled>no</disabled>
  </active-response>

</agent_config>

1つでローカルに持っています。エージェントの構成（ossec.conf）は次のとおりです。

<ossec_config>
  <active-response>
    <disabled>no</disabled>
  </active-response>
  <client>
        <server-ip>192.168.0.21</server-ip>
        <notify_time>120</notify_time>
        <time-reconnect>240</time-reconnect>
  </client>
</ossec_config>

およびエージェントの共有フォルダーにあるagent.confファイル：

<agent_config>
    <localfile>
        <location>/var/log/my.log</location>
        <log_format>syslog</log_format>
    </localfile>
</agent_config>

ログから、マージは行われておらず、ローカルコピーが実行されていることがわかります。

2017/10/08 00:06:52 ossec-agentd: INFO: Trying to connect to server 192.168.0.21, port 1514.
2017/10/08 00:06:52 INFO: Connected to 192.168.0.21 at address 192.168.0.21:1514, port 1514
2017/10/08 00:06:52 ossec-agent: Starting syscheckd thread.
2017/10/08 00:06:52 ossec-syscheckd(1702): INFO: No directory provided for syscheck to monitor.
2017/10/08 00:06:52 ossec-syscheckd: WARN: Syscheck disabled.
2017/10/08 00:06:52 ossec-rootcheck: INFO: Started (pid: 2512).
2017/10/08 00:06:52 ossec-syscheckd: INFO: Started (pid: 2512).
2017/10/08 00:06:53 ossec-agentd(4102): INFO: Connected to server 192.168.0.21, port 1514.
2017/10/08 00:06:53 ossec-agent: INFO: System is Vista or newer (Microsoft Windows 7 Enterprise Edition Professional Service Pack 1 (Build 7601) - OSSEC HIDS v2.9.0).
2017/10/08 00:06:53 ossec-logcollector(1103): ERROR: Could not open file '/var/log/my.log' due to [(9)-(Bad file descriptor)].
2017/10/08 00:06:53 ossec-logcollector(1950): INFO: Analyzing file: '/var/log/my.log'.

結局、エージェント/マネージャーが次のことができない場合ではないようです：

  • 互いに接続します。
  • 構成ファイルを解析します。
  • データをやり取りします（トリガーされたルール）。
  • 使用している構成ファイルのバージョンを確認してください。
  • 構成をマージします（エージェント上に定期的に0KBのmerge.mgファイルが表示されます）。

アプライアンス/マネージャーでオプションを設定できませんでしたか、それとも他の場所で問題が発生しましたか？

ossec
1
dark_st3alth

したがって、security.stackexchange.comで成功しなかった後、質問はここに移行されました。これにさらに数日を費やして、私は「解決策」を見つけました。

要約すると、次のようになります。別のHIDSソリューションを見つける

私は物事の広範なリストを試した後、この結論に達しました：

  • プロジェクトのウェブサイトから直接OVAを実行します（2.8.3）
  • OSSECプロジェクトのウェブサイトで提供されているOVAを更新/アップグレードしました。
  • CentOS7の新規インストールにOSSECサーバー/マネージャーをインストールしました。
  • CentOS7の「サーバーGUI」および「最小」インストールでサーバーをインストールしました。
  • Windows7クライアントVMの更新を試みました。
  • 他の新しいWindowsベースのVMを使用する。
  • ポート、ファイアウォールルール、および静的IPアドレスを変更します。
  • サーバーとクライアントの両方でファイアウォールを無効にしました。
  • レジストリを介してWindowsクライアント内のUDPバッファを増やします。
  • SELinuxを無効にしました（許容モードがアクティブです）。
  • サーバーにエージェントがリストされていることを確認し、変更を検出するために再起動しました。
  • RPMソースからサーバーをインストールしました
  • ソースコードからコンパイルおよびインストールされます。
  • Windowsエージェントバージョン2.9.0および2.9.2を試しました。

適切なインストールを実行するために、少なくとも（ある程度）機能したので、次の手順に従いました。

  1. サーバーをCentOS7インストールメディアで起動します。
  2. 最小インストールを選択します
  3. ネットワークに接続します。静的IPが最適です。
  4. インストール後、rootとしてログインします。
  5. ファイアウォールを開きますfirewall-cmd --permanent --zone=public --add-port=1514/udp
  6. 変更をコミットしますfirewall-cmd --reload
  7. いくつかのエクストラをインストールしますyum install mysql-devel postgresql-devel gcc wget vim
  8. ソースコードを入手するwget https://github.com/ossec/ossec-hids/archive/2.9.2.tar.gz
  9. コードを解凍しますtar -zxvf 2.9.2.tar.gz
  10. 新しいディレクトリに移動しますcd ossec-hids-2.9.2
  11. インストーラーを実行します./install.sh
  12. インストールにはserverタイプを選択します。
  13. 設定しました。メールをnoに設定する以外のすべてのオプションをデフォルトで設定しました。
  14. クライアントの構成をセットアップします/var/ossec/bin/manage_agents
  15. newvim /var/ossec/etc/shared/agent.confを介して一元化された構成ファイルを構成します
  16. サーバーを起動します/var/ossec/bin/ossec-control start
  17. 最新バージョン（2.9.2）のWindowsクライアントをインストールします。

何時間も費やした後の素晴らしいことは、私の仕事がすべて無駄になったということでした。 Windowsクライアントをデバッグレベル2に設定する方法を見つけ、次のメッセージを見つけました。

2017/10/20 02:13:40 ossec-agentd: Failed md5 for: shared/merged.mg -- deleting.

構成の重要なマージが失敗したという「通常の」ログレベルでスローされる警告がないことが判明しました（真剣に！？）

サーバーとクライアントを再起動した後、サーバーがクライアントの構成のmd5ハッシュを取得できなかったという事実にさらに感銘を受けました（＃2から＃14を試みてください）。

OVAを使用した1回の実行（試行＃1）で、サーバーは構成のクライアントのmd5を取得できましたが、サーバーのmd5と一致しませんでした。これは私の元の質問で見ることができます。エージェントのconfディレクトリ（主にagent.conf）にいくつかのファイルを追加したため、エージェントからのmd5が送信されたと思います。

まったく迷惑なことに、私はインターネットに目を向けると、OSSECの Googleグループディスカッション を見つけました。メッセージのチェーン全体を読んだ後、それは非常に明白になりましたOSSECに重大な欠陥があります：

IMHOの前に述べたように、この問題はWindowsおよびUNIXエージェントに影響しますが、デフォルトのバッファーが短いため、Windowsでより一般的です。プライベートVirtualBoxネットワーク上のWindowsエージェントでこの問題が発生しました。共有ファイルが到着しませんでした。デバッグを有効にすると、次のメッセージが表示されました。

ossec-agent: Failed md5 for: merged.mg -- deleting.

そこで、このテストを行いました。ファイルが破損していても削除されないようにソースコードを変更し、受信したファイルを元のファイルと比較しました。ファイルの一部のチャンクが実際に失われ、行末の問題ではありませんでした。

共有ファイルチャンクは、UDPプロトコル、およびその他のエージェントイベントまたは制御メッセージが原因で失われる可能性があります。実際、TCPを使用することは、この問題の良い解決策のようです。バージョン1.1から1年前にWazuhでTCP通信を実装し、いくつかの利点に到達しました。

No event losing. Communication is reliable for events, control messages and Active response requests.
Agents detect that a manager is down immediately, so they are able to "lock" the transmission in order to prevent events from being dropped.

TCP接続のエージェントは、Linux、Windows、OpenBSD、macOS、AIXなどを使用する多くのシステムで正しく機能しています。

これは私が読むと思っていたものではありません。私が最も心配しているのは、OSSECインフラストラクチャが単にパケット損失によってダウンする可能性があるという事実です。通常のログレベルでは、構成のマージに失敗しても表示されないことはさらに心配です。

私はWindowsエージェントのみをテストしましたが、Linuxエージェントが機能することは間違いありません。おそらく将来的にOSSECはTCP接続に移行しますが、今のところ、OSSECには重要な機能が欠けています。

tldr;（少なくとも私の意見では）結局のところ、不十分なソフトウェアテスト/品質保証です。 Googleグループのディスカッション UDP接続が問題を引き起こし、データ送信の検証が制限されていることがわかりました。転送中のマネージャーの構成が破損しているため、クライアントはそれをマージすることを拒否します。これは、Windowsクライアントでのみ発生するようです。

0
dark_st3alth