OSSIM-包括的なオープンソースのセキュリティ管理システムを使用しています

この記事は、「 OSSIM-統合オープンソースセキュリティ管理システムの展開 」という記事の印象を受けて書かれました。 繰り返しはせず、システムのインストールプロセスについて説明します。 OSSIMを使用した実際の経験に関連した明確化と明確化を行いたいだけです。

何に賭けますか？ 鉄または仮想？

どの手順でも、「間違いなく仮想マシン上で」を読むことになります。 私の答えは、「間違いなく鉄の上に」です。 両方の答えが正しいです。 なんで？

OSSIMはオペレーティングシステムと「バンドル」されてインストールされ、イメージのあるディスクにはハードウェアに必要なドライバーが含まれていない可能性があるため、最初の答えは正しいです。 これに遭遇した場合、これはあなたの問題になります。あなたは自分で解決する必要があります。 仮想マシンにインストールすると、いくつかの汎用性が提供され、問題は発生しません。 さらに、更新後に問題を再度解決する必要がないという保証はありません。 アプライアンスとして販売され、それに応じてサポートされる公式の商用「ハードウェア実装」がありますが、ここではオープンソースOSSIMに注目し、ここですべてのハードウェアの問題はあなたの問題です。

ハイパーバイザーはブレーキなので、2番目の答えは正しいです。 ユニバーサル仮想化の支持者は、必要なだけトランペットを鳴らし、ドラム、ウェーブフラグを打ち負かすことができますが、ハイパーバイザーはゲストシステムのパフォーマンスを大幅に低下させます。 通常、これは無視できますが、OSSIMは速度が大好きです。 その結果、4コアアトム、16 GB DDR3および128 GB SATA3 SSDを備えたベアコアミニコンピューターにより、HP dl380上の仮想マシンが容易になります。 物理マシンが必要とするよりもはるかに多くのリソースを仮想マシンに提供する必要があります。 そして、それはもっと費用がかかります。 ドライバーについては、インストール中に、必要に応じてドライバー付きのUSBフラッシュドライブを挿入するように求められます。

重要です。 アイアンマシンでは、インストーラーは起動可能なCDからのみ起動します。 イメージをUSBフラッシュドライブにアップロードすると、OSSIMはインストールされませんが、Debianをインストールできます。

とても重要です。 動作中のコンピューターにOSSIMを「2番目のシステム」としてインストールしないでください。 インストーラーは、自分が裸のマシンに置かれていると信じており、「ディスクをパーティション分割する方法」というばかげた質問をしません。 まず第一に、尋ねることなく、彼はパーティションテーブルを上書きし、ディスクをフォーマットします。

OSSIMのインストールには、「15分」かかりません。 ずっと長い。 最後の段階では、インストーラーがフリーズし、すべてがなくなったと考えることさえできます。 ちょっと待って 彼は働いています。

重要度の高い順にOSSIMの最も重要なリソース

ディスクサブシステムの速度。 SSDを正しく使用してください。 ボリュームは重要ではありません。 100GBで十分です。 しかし、速度は非常に重要です。 これには2つの理由があります。 まず、syslogに送信され、OSSIMプラグインによって読み取られるテキストログ。 次に、同じマシンで実行されるデータベース。 SSDはシステムのパフォーマンスを劇的に改善します。

プロセッサコアの数。 各コアのパフォーマンスは、その数ほど重要ではありません。 OSSIMは非常に簡単な操作を実行しますが、一度に多くの操作があり、並行して実行できます。 また、ご存知のように、ネットワークIDS（Suricata）にとっても重要です。

RAMの量。 それほど重要ではありませんが、ページファイルに何もプッシュしない方が良いです。

ログ内の200万イベントと「判読不能」インターフェイス上の10テラバイトのトラフィックの毎日のストリームに基づく仮想マシンに適した構成：8コア、16 GB。 しかし、それは背中合わせです。 リソースは眼球に食べられます。



もちろん、スイッチのスパンポートからネットワークのすべてのヴィランからミーアキャットの分析のために収集されたトラフィックをスローする判読不能なインターフェイスは10Gbsである必要があります。 それ以外の場合は、単にチョークします。

WindowsマシンからOSSIMサーバーを管理する場合は、パテとWinSCPが必要です。 まあ、またはあなたが彼を愛しているなら遠い。 Ubuntuを搭載したマシンからドライブする方が便利です。 少なくとも、スクリプトでCRLFとして行末を誤って書いたかどうかを毎回確認する必要はありません。

インストール後、リモートマシンからSSH経由でサーバーに接続することはできません。 Debian 8では、sshd設定のデフォルトオプションは「PermitRootLogin without-password」であり、 `/ etc / ssh / ssh_config`で` PermitRootLogin yes`に変更する必要があります。

タイムゾーン

もう1つの重要なことは、プラグインのタイムゾーンの正しい構成です。 実際、すべてのログソースが同じタイムゾーンにある場合でも、必ずしも同じ現地時間を使用しているわけではありません。 たとえば、System Center Configuration Managerは、UTCでデータベースに時間を保存するのが妥当であると考えています。 また、データベースから新しいイベントを読み取るプラグインを持っている場合（そして、私はそれを持っています）、それらは現地時間で記録されないことを考慮する必要があります。

プラグインのタイムゾーンは2つの場所で設定されます：最初に、すべてのプラグインのデフォルトのタイムゾーンが `/ etc / ossim / agent / config.cfg`に設定され、次に、個々のプラグインの設定ファイルで再定義できます。 タイムゾーンの定義とは、プラグインジェネレーターに「データがそのようなタイムゾーンから来ていると想定し、時間を我々の時間に変換する」ことを意味します。 この場合、「ours」はサーバーの現地時間です。 実際、時間はデータベースにUTCで書き込まれますが、「ローカルシステム」のオフセットが書き込まれる別のフィールドがあります。

異なるタイムゾーンに同じタイプの2つのソースがある場合、興味深いことが始まります。 たとえば、さまざまなブランチからcisco-asaルータログを取得します。 この場合、異なるパラメーター `tzone =`を指定する設定ファイルで、異なるプラグインでそれらを処理する必要があります。 このパラメーターは `[default]`セクションで設定されます。 あなたがドキュメントでこれを見つけられないので、私はこれについて書いています、私は理由を知りません。 POSIX形式：「tzone = Europe / Moscow」。

Windowsログを収集する最良の方法は何ですか？

私の答え：「ネイティブ」ツールAlienVault HIDS、別名OSSEC。 もちろん、これについて簡単に説明します。

理論的には、多くのエージェントのいずれかを使用して、Windowsイベントログをsyslogに送信したり、WMIを使用したりできます。 OSSIMにはWMIクライアントがあり、Windowsログを読み取るための標準プラグインがあります。 SNAREエージェント用の標準プラグインもありますが、ロシアのWindowsを扱っている場合、それは役に立ちません。 問題は、SNAREがロシアのWindowsからcp1251エンコーディングでデータを送信し、SNAREの標準パーサーがcp1252の下に記述されていることです。 レギュラーシーズンを編集する必要があります。

しかし、最も興味深いことは、「多言語」システムからログを収集するときに始まります。 たとえば、ワークステーションにロシア語のWindowsがあり、サーバーに英語があります。 そして今、それを分析する方法は？ これは実際、すべてのSIEMに共通の問題です。 彼らはそれをさまざまな方法で解決します。 たとえば、ArcSightはWindowsログの収集にかなり洗練されたシステムを使用しているため、システムのローカライズに関係なく、英語のみでログを収集できます。 OSSECは非常に単純な手法を使用します。 Windowsにエージェントをインストールすると、英語のWindowsログの文字列メッセージのテーブルを含むcsvファイルがその作業ディレクトリに書き込まれます。 したがって、分析に必要なメッセージの「必須部分」は、システムのローカライズに関係なく、常に1つの言語で送信されます。 しかし、「データ」は「元の言語で」来ます。 とても便利です。

さらに、OSSECエージェントの標準プラグインは非常によく書かれています。 彼はイベントをタイプごとに慎重に解析します。 ログを収集するために別の方法を使用する場合、棚でイベントを手配するのに多くの汗をかかなければなりません。 最後に、OSSECは単なる「ログ転送」ではなく、実際にはホストIDSであり、悪いものでもありません。 トレンドマイクロは、このエンジンを「高度な」ウイルス対策に使用することに決めました。 はい、OSSECはコントロールショットとして信頼できます。 重要なシステムにエージェントを安全にインストールできます。

その他。 ウサギは貴重な毛皮であるだけでなく、3〜4キログラムの食肉でもあります。 OSSECはログコレクターではなく、それ自体がSIEMです。 OSSIMでは、Windowsログはまったく送信されませんが、独自のalert.logはエージェントから受信したイベントの事前処理に基づいて形成されます。 ここには、たとえば、制御されたファイルの変更イベント、または「複数のエラー」や「レジストリ内のキーのチェックサムの複数の変更」などの集約イベントがあります。 単なるコレクターよりも便利です。 OSSECはインターネット上で非常に広く普及しており、Webサーバーを保護するために頻繁に使用されているため、コミュニティは大きく活発です。

もちろん、Windowsのログを収集する他の方法を試すことができます。 これは面白いです。

OSSECエージェント構成についての何か

Windowsマシンでは、エージェントはデフォルトの構成ファイルとともにインストールされます。 このファイルは次の場所にあります： `/ usr / share / ossec-generator / installer / ossec.conf`。 OSSECは、サーバーからの構成のダウンロードをサポートしています。 ファイル `/ var / ossec / etc / shared / agent.conf`がこの目的に使用されます。 デフォルトでは存在しません。 このファイルは、OSSIMコンソールのWebインターフェースから作成できます（環境-検出-エージェント-agent.conf）。 または、テキストエディタで作成します。

ローカルエージェント設定ファイルとマージされるXML形式の設定ディレクティブを含める必要があります。 さまざまなエージェントのディレクティブブロックをマークして、適切なエージェントにのみ適用できます。 OSタイプ、エージェント名、プロファイル名によるマーキングが許可されます（ローカルエージェント構成では、この場合、プロファイルの名前を示す必要があります）。

<agent_config name="agent001|agent002|agent018">

</agent_config>

<agent_config os="Linux|FreeBSD">

</agent_config>

<agent_config os="Windows">

</agent_config>

<agent_config profile="web-server">

</agent_config>

このようにして、エージェントの構成を一元的かつ個別に変更できます。 「マージ」という用語には明確化が必要です。 構成ファイルのローカルセクションがオーバーライドされるとどうなりますか？ 理論では、ローカルファイルが最初に読み込まれ、次にサーバーファイルが読み込まれ、最後に読み込まれたルールが最後に読み込まれ、以前のファイルはすべて上書きされます。 実際には、このような構成パラメーターの交差を試したことはありません。 単に必要はありませんでした。 必要に応じて、思うように機能することを願っています。

もう一つの重要なポイント。 ローカルエージェント構成のテンプレートは、サーバーへの接続方法を示しています。

<server-ip>172.17.2.10</server-ip>
<notify_time>120</notify_time>
<time-reconnect>240</time-reconnect>


あなたがここで見ることができるようにIPアドレス。 著者がそのようなテンプレートを好んだ理由はわかりません。 FQDNを指定すると、このセクションは異なるように見えるはずです。

<server-hostname>fqdn</server-hostname>
...



ただし、これは行われていません。 これは、サーバーのIPアドレスを変更すると、すべてのエージェントが落ちることを意味します。 良い考えではありません。 もちろん、SIEMはIPアドレスが変更されるようなデバイスではありませんが、どういうわけか不快です。 もちろん、テンプレートのこのセクションを変更できますが、ほとんどの場合、次の更新でテンプレートが再生成されます。 これを常に監視する必要があります。 アドレスを変更する習慣がないので、この問題は私を悩ませません。

ホストエージェントのインストールに関する考慮事項

Windowsでは、自動展開ボタンを使用してOSSIM Webコンソールからエージェントをインストールするのが最も便利です。 ただし、ターゲットホスト（またはドメイン）のローカル管理者の資格情報が必要になります。 グループポリシーからのインストールまたはSCCMの使用は非常に困難です。 実際には、各インストールファイルは、サーバーとの通信を暗号化するための一意のキーを含むため、特定のホストに対して個別です。 PCI DSSレベルでのこのような秘密。 悲しみ。

Linuxの場合、エージェントレスが可能ですが、SSHを介したホスト接続のセットアップが必要です。 私の意見では、これは悪い考えです。 私はエージェントを置くことを好みます。 この場合、「生」からターゲットマシンにエージェントをコンパイルして完全に手動でインストールします。 バージョン2.8.2を公式にサポートしましたが、バージョン2.8.3も問題なく機能します。 実際には、たとえばDebianなど、さまざまなシステム用のパッケージがあります。 詳細はこちらをご覧ください。

ドキュメントを探す場所と読むべきもの

Webコンソールメニューのサポートボタンをクリックして、リンクを取得します。 読む必要があります：

USM 5.xプラグイン管理ガイド
相関ディレクティブまたは相互相関ルールのカスタマイズ
AlienVaultでの侵入検知
ポリシー管理の基礎
OTXでUSMおよびOSSIM 5.1を使用する-AlienVault
資産、グループ、ネットワーク
システムエラー、警告、提案

SIEMが必要な理由

誰もが理解しているように見えますが、ビジネスに関しては、ほとんどの場合、人々はSIEMの目的を正しく理解していないことがわかります。 まず第一に、これは救済策ではありません。 「セキュリティ管理システム」でもないので、この記事のタイトルを失礼しますが、最初に始めたわけではありません。 実際、これはセキュリティ侵害の成功を検出する手段です。 保護を構築するための標準的なスキームは、起こりうる攻撃（実際の脅威）とそれらの実行方法の識別から始まります。 次に、考えられる「攻撃ベクトル」に置かれる技術的および組織的な防御手段が考案され、実装されます。 そして、これらすべての後、「コントロール」が設定されます。その目的は、すべての保護手段が機能しないことを確認することです。 また、SIEMはこのクラスに属します。

これはあなたが理解する必要があるものです。 SIEMは、すでに発生した違反を検出するか、技術的および組織的な保護手段を回避するように設計されています。 これは、ビデオ監視システムのようなものです。 まず、これらの違反を検出する兆候、SIEMがこれらの兆候を識別する方法、必要な情報を取得する場所を決定する必要があります。 SIEMに表示されない「デッドゾーン」はありますか。 状況は最も予想外の場合があります。



OSSIMは、分析のために疑わしいパケットをpcap形式で保存します。 ここにあります：



あれは何だった？

しかし、それはそのようなものでした。 あるオフィスでは、IT専門家がTomcatアプリケーションサーバー環境で回転しているある種のものをテストしました。 もちろん、出会った最初のサーバーにこのものをインストールし、コンソールの入り口に空のパスワードを残しました。 テストして忘れてしまった。 最初のサーバーはターミナルサービスサーバーであることが判明しました。 そして、ご存じのとおり、tomcatはシステムアカウントで動作しました。 邪悪なハッカーフィッシングが従業員のコンピューターにトロイの木馬を滑り込ませ、ネットワーク上で有用なものを調べました。 この忘れられたWebサーバーを見つけて喜んでいた。 コンソールコマンドをサポートするためにライブラリを注ぎました。 このライブラリをテストするその瞬間が写真に示されています。 net userコマンドが実行され、suricataがhttp-responceの出力の内容を見てブーイングを出しました。 彼らがどんな種類のゴミを整理している間、邪悪なハッカーはすでにミミカツをそこに押し込み、ユーザーパスワードを収集し始めました。幸いなことに、それらはすべてターミナルサーバーに行きます。

状況は非常に重要です。 人々は常に間違いを犯します。 IT専門家だけでなく、ハッカーも。

または、ここに簡単な話があります。 これは、完全に新しいアラームページです。



これは、いわゆるOTXパルスです。 詳細は次のとおりです。



あれは何だった？

そして、これは従業員の1人のブラウザであり、bankir.ruのフォーラムスレッドの1つを見て、URL owqkq.ne1t3v8.topに急いで行きました。これはAngler Exploit Toolkitを使用した駐車ページの1つです。 また興味深い話。

「デッドゾーン」を回避するには、まずネットワーク上のすべてのホストにHIDSエージェント（OSSEC）を配置する必要があります。 次に、内部ネットワーク上のすべてのトラフィックの「判読不能」なOSSIMインターフェイスへの送信を構成して、NIDS（Suricata）によって処理されるようにします。 少なくともすべてのDMZノードのOpenVASスキャナーで定期的な脆弱性スキャンを構成して実行することが不可欠です。 これは重要です。 観察によると、非常に小さな会社でも、毎日20〜50の敵スキャナーが通過しています。 あなたが彼らよりも前に脆弱性を発見するならば、それはより良いでしょう。 私は誇張ではなく、ただ軽視しています。 以下は、日報の実際のスニペットです。

2016:02:18 - 2016:02:19

IP
2016-02-18 09:22:46 180.97.106.37 Nanjing Malicious Host
2016-02-18 09:38:37 216.218.206.123 Fremont Malicious Host
2016-02-18 09:52:57 85.25.214.226 Germany Scanning Host
2016-02-18 10:08:11 146.185.250.105 Saint Petersburg Malicious Host
2016-02-18 10:22:54 178.62.14.193 London Malicious Host
2016-02-18 10:23:24 94.102.49.79 Netherlands Malicious Host
2016-02-18 10:47:52 195.88.209.6 Moscow Malicious Host
2016-02-18 10:53:29 222.186.34.177 Nanjing Malicious Host
2016-02-18 11:07:48 71.6.135.131 San Diego Malicious Host
2016-02-18 11:58:17 193.105.134.220 Sweden Malicious Host
2016-02-18 11:58:51 62.210.206.219 France Malicious Host
2016-02-18 12:28:13 193.109.69.150 Russia Malicious Host
2016-02-18 12:43:40 216.218.206.96 Fremont Malicious Host
2016-02-18 13:08:50 209.126.124.67 St Louis Malicious Host
2016-02-18 13:53:19 178.33.17.241 France Malicious Host
2016-02-18 14:23:52 198.20.70.114 Chicago Malicious Host
2016-02-18 14:32:49 104.219.238.10 Rye Malicious Host Scanning Host
2016-02-18 14:38:38 198.23.112.119 Dallas Scanning Host
2016-02-18 15:02:58 198.20.69.98 Chicago Malicious Host
2016-02-18 15:03:29 64.125.239.136 United States Malicious Host
2016-02-18 15:28:35 162.248.74.2 Clarks Summit Malicious Host
2016-02-18 15:43:36 222.174.5.28 Jinan Malicious Host
2016-02-18 15:57:42 66.240.236.119 San Diego Malicious Host
2016-02-18 16:13:09 74.82.47.45 Fremont Malicious Host
2016-02-18 16:13:44 64.125.239.92 United States Malicious Host
2016-02-18 17:07:57 142.54.162.74 Kansas City Malicious Host
2016-02-18 17:22:41 64.125.239.107 United States Malicious Host
2016-02-18 17:58:54 23.239.66.99 United States Malicious Host
2016-02-18 18:07:50 61.216.2.14 Taiwan Malicious Host
2016-02-18 18:08:03 198.20.69.74 Chicago Malicious Host
2016-02-18 18:08:18 141.212.122.84 Ann Arbor Malicious Host
2016-02-18 18:08:18 141.212.122.81 Ann Arbor Malicious Host
2016-02-18 19:52:53 185.94.111.1 Russia Malicious Host
2016-02-18 19:58:27 162.244.35.24 United States Malicious Host
2016-02-18 20:23:00 162.244.35.22 United States Malicious Host
2016-02-18 20:23:37 89.248.160.192 Netherlands Malicious Host
2016-02-18 20:43:55 222.174.5.17 Jinan Malicious Host
2016-02-18 21:23:55 185.130.5.201 Republic of Lithuania Malicious Host
2016-02-18 21:47:39 92.60.184.34 Ukraine Scanning Host
2016-02-18 22:33:48 209.126.102.181 St Louis Malicious Host
2016-02-18 22:57:37 71.6.167.142 San Diego Malicious Host
2016-02-18 23:13:37 212.83.148.78 France Malicious Host
2016-02-19 00:07:54 185.130.5.240 Republic of Lithuania Scanning Host
2016-02-19 00:48:22 64.125.239.224 United States Malicious Host
2016-02-19 01:13:11 66.240.192.138 San Diego Malicious Host Scanning Host
2016-02-19 02:33:05 198.204.234.74 Kansas City Scanning Host Malicious Host
2016-02-19 02:57:03 104.243.223.8 Tampa Malicious Host
2016-02-19 02:58:02 198.20.99.130 Netherlands Malicious Host
2016-02-19 03:27:43 162.244.35.25 United States Malicious Host
2016-02-19 03:28:13 89.163.251.200 Germany Malicious Host
2016-02-19 04:28:25 71.6.165.200 San Diego Malicious Host
2016-02-19 04:52:08 93.174.93.181 Netherlands Malicious Host
2016-02-19 04:58:24 184.105.247.238 Fremont Malicious Host
2016-02-19 05:23:07 192.162.101.79 Russia Malicious Host
2016-02-19 05:23:20 64.125.239.112 United States Malicious Host
2016-02-19 06:12:43 188.138.1.218 Germany Malicious Host Scanning Host
2016-02-19 06:12:44 74.82.47.55 Fremont Malicious Host
2016-02-19 06:43:55 209.239.123.106 St Louis Malicious Host
2016-02-19 07:13:45 185.56.28.67 Netherlands Malicious Host
2016-02-19 08:13:09 184.105.247.228 Fremont Malicious Host
2016-02-19 08:28:51 184.105.139.72 Fremont Malicious Host

そして、これはコミュニティに知られている悪役に関連する部分のみであり、レポートには未知の悪役のリストを含む別の部分もあります。 もちろん、それらのほとんどはあまりプッシュしません。 例：このように（これは同じレポートからの切り抜きです）：

Netflow 180.97.106.37 : Nanjing : Malicious Host

2016-02-18 09:22:46.585 0.000 ICMP 91.111.111.9:0 180.97.106.37:3.0 1 56 1
2016-02-18 09:22:46.586 0.000 TCP 180.97.106.37:46024 91.111.111.9:3128 1 40 1
2016-02-18 20:32:23.247 0.000 TCP 180.97.106.37:37254 91.111.111.101:22 1 40 1
2016-02-18 20:43:38.783 0.000 TCP 180.97.106.37:45840 91.111.111.25:22 1 40 1
2016-02-18 20:43:38.783 0.000 ICMP 91.111.111.25:0 180.97.106.37:3.0 3 204 1
2016-02-18 22:07:25.502 0.000 TCP 180.97.106.37:54895 91.111.111.36:22 2 80 1
2016-02-18 22:41:06.739 0.000 TCP 91.111.111.13:22 180.97.106.37:48365 1 40 1
2016-02-18 23:16:01.974 0.996 TCP 180.97.106.37:13302 91.111.111.32:80 10 539 1
2016-02-18 23:16:01.975 0.679 TCP 91.111.111.32:80 180.97.106.37:13302 7 3048 1
2016-02-18 23:20:07.473 0.000 TCP 180.97.106.37:43667 91.111.111.9:22 2 80 1
2016-02-18 23:20:07.473 0.000 ICMP 91.111.111.9:0 180.97.106.37:3.0 1 56 1
2016-02-19 05:50:52.757 12.217 TCP 91.111.111.44:80 180.97.106.37:53461 5 260 1

しかし、非常に邪魔な性格もあります。

ファイアウォールログも必要になります。 これは、どのオフィスでも最小値です。 そして、内部のものがあります。DBMSおよび個々のビジネスアプリケーションへのアクセスログ、Webサーバーログなどです。 など 必要なものをすべて収集できます。 ログを解析するための標準プラグインがない場合は、独自のプラグインを作成するのは非常に簡単です。 真実は簡単です。 最初のプラグインを開発するのに数日もかかりません。 そして、2番目の開発には数時間かかります。

たとえば、組織のセキュリティ対策の違反を監視する場合、オフィスでは、情報セキュリティサービスの承認なしに運用環境の構成を変更することは禁止されています。 OSSECは、構成の変更について口sを鳴らし、同意されたかどうかを確認できます。 最も興味深い部分は、誰もこの変更を行っていないことが判明したときに始まります。

どの制御ルールを適用すべきかについて正確にアドバイスするつもりはありません。 各村には独自の伝統があります。 ご質問がある場合は、お問い合わせください。

重要です。 AlienVault OSSIMは、古典的な意味でのSIEMだけではありません。 これは、ホストIDS、ネットワークIDS、ワイヤレスIDS、Volnurability Scaner、NetFlow Collectorを含む本棚全体です。 つまり、企業のネットワークのビデオ監視を整理するための完全な古典的な「コントロール」のセットです。

トラブルと射撃

何かがおかしいと思われる場合は、ログを確認してください。 どこ？

OSSECログとエラー：

`/var/ossec/logs/ossec.log`-ここにOSSECエラーが表示されます。 最も一般的な間違いは、エージェントとの通信が失われることです。これは、ネットワーク上で致命的な通信障害が発生した場合、またはエージェントを再インストールした後に発生します。 まれですが、エージェントの数が多い場合、それほど珍しいことではありません。 エージェントがアクティブでないことをコンソールで確認し、コンピューターの電源が入っていることがわかっている場合は、ここにいます。 ログでは、エラーは「ERROR：Duplicated counter for 'agent-name'」のようになります。 単純に排除されます。 Webコンソール（環境-検出-エージェント）またはファイル `/ var / ossec / etc / client.keys`で、この名前のエージェントを探し、その番号（左端の列の番号）を確認します。 次に、 `/ var / ossec / queue / rids`ディレクトリに移動し、その中のファイル-エージェント番号を削除します。 SSHをサーバーコンソールに移動し、コマンドラインを終了して、 `/ etc / init.d / ossec restart`を実行します。 すべてのもの。 正直なところ、OSSECで他のエラーを見たことはありません。

`/ var / ossec / logs / alerts / alerts.log`は、OSSECがエージェントから噛んだイベントを収集するログです。これは、OSSIMがOSSECのプラグインでイベントを読み取り、処理する場所です。 ここで、何がそこに行き、どのように見えるかを見ることができます。

従来の `/ var / log`にある残りのログは、` / var / log / alienvault / agent / agent.log`と同じ場所にあり、 `agent_error.log`にあります。 独自のプラグインをデバッグするときに便利です。 作業システムでは、「agent.log」のサイズはギガバイト単位であることに注意してください。

OSSIMの動作に重大なエラーを見たことはありません。 システムの次の更新後、定期的なバックアップが機能しなくなりました。 ファイルの1つに権限を誤って割り当てたことが判明しました。 これは翌日、文字通り修正されました。 このような問題に関する情報は、コミュニティフォーラムで開催されます。 もう一度、次の更新後、次の更新が機能しなくなりました。 今回は、4時間前に投稿された更新にバグが含まれており、この方法で修正する必要があるという通知が来ましたが、修正された更新はそのような時期に投稿されました。 ちなみに、標準的な手段（Webまたはsshコンソールから）による更新がクラッシュして機能しない場合は、コマンドで更新を実行できます。

apt-get update
apt-get upgrade

サーバーコンソールから。

おそらくこれが私が言いたかったことのすべてです。 そして最も重要なことです。 これはオープンソースです。 あなたが望むものは何でも、Pythonはあなたと一緒です。 そして、あなたが彼と一緒にいたくない場合は、商用版-Pythonを見てください。 そしてここで最後の質問に行きます。

オープンソースかエンタープライズか？

私の答えは、会社のニーズに合わせてSIEMが必要な場合は、エンタープライズです。 もちろん、企業が独自のSIEMの開発を目指していない場合、オープンソースバージョンをエンタープライズレベルにするための十分な人的および技術的リソースはありません。 しかし、これがあなたのビジネスではない場合、あなた自身の世話をしてください。 残念ながら、エンタープライズSIEMは非常に高価です。 しかし、非常に高価なのは、異常な相関サーバーエンジンがあるためではなく、イベント相関ルールライブラリの作成、複雑な攻撃の「シグネチャ」の分析とそれらの検出方法、およびこれらのメソッドのデバッグに多大な投資があるためです。 これは、自分ではできない仕事です。 ここでは商用製品の利点については説明しません。これらの利点は明らかであり、議論する価値はありません。

では、なぜこのオープンソースに時間を無駄にしているのでしょうか？ まず第一に、私は彼が好きです。 このようなすべてのオープンソースプロジェクトの中で、これは成功しています。 第二に、AlienVaultのWebサイトは、「誰でもセキュリティにアクセスできるようにしたい」と言っています。 いい考えだ。 サポートします。 あまりにも多くの企業は、このクラスの商用製品を購入する余裕がありません。 sysadminのフリーランサーが大勢いることは知っています。小さな会社にサービスを提供しているとしましょう。 彼らがこのように見えることは理にかなっています。 冒頭でミニコンピューターについて言及したのは、何の意味もありません。 Little SIEMは非常に現実的なものです。

エンタープライズ-エンタープライズ、およびコミュニティ-コミュニティ。 土地-農民、工場-労働者、お金-銀行員。 「すべての人に幸福を、そしてすべての人に十分」（A.とB. Strugatsky。「傍観者のピクニック」）。

使用されるソース：

https://www.alienvault.com/documentation
https://alienvault.ru/open-threat-exchange/
http://ossec.imtqy.com/docs/
http://suricata-ids.org/docs/