記事ディレクトリ
Huawei Cloud Yaoyun Server L インスタンスの評価 | Huawei Cloud 上のホストセキュリティ製品 Elkeid のトライアル
1. 背景: ホストのセキュリティとは何ですか?
クラウド技術の発展に伴い、大手銀行、大企業、中小企業、政府機関などでもクラウド技術が頻繁に利用されるようになり、これらの分野においてセキュリティが非常に重要な要素となっているのは明らかです。データ ストレージの場所として、クラウド ホストはハッカーによる絶え間ない侵入の脅威に直面しています。
ホスト セキュリティとは、特に、データの保存と処理におけるホストの機密性、完全性、可用性の確保を指します。これには、ハードウェア、ファームウェア、システム ソフトウェアの独自のセキュリティに加え、一連の追加のセキュリティ テクノロジとセキュリティ管理手段が含まれます。これにより、完全なホスト セキュリティ環境が確立されます。
20年以上の構築を経て、我が国の情報セキュリティは、ウイルス対策、ネットワーク、国境セキュリティにおいて一定の成果を上げているが、ホスト環境のセキュリティ構築は比較的脆弱であり、ホストは最も重要かつ最後の防御線である。情報セキュリティのため。
実際、私の個人的な理解では、ホスト セキュリティはホスト層侵入検知システム (HIDS) (ホストベースの侵入検知システム) であることが多く、主にホスト層の情報を収集して侵入検知/動作監査/攻撃元を実現します。トレース/資産インベントリ/コンプライアンスベースラインテストおよびその他の機能。
今日は、ByteDance のオープンソース HIDS プロジェクトである Elkeid を Huawei Cloud 上で使用する体験をしていきます。
2. ホストセキュリティエルケイド
1. エルケイドの紹介
Elkeidオープンソース版プロジェクトアドレス:https://github.com/bytedance/Elkeid
セキュリティ分野のオープンソース プロジェクトであり、北斗七星の七星の 1 つでもある堯光/坡君を意味する Elkeid と呼ばれるこのオープンソース プロジェクトが解決する問題は、ホスト セキュリティです。
Elkeid は Volcano Engine の CWPP 製品であり、複雑な技術アーキテクチャの下で現代の企業のセキュリティ ニーズを満たすように設計されています。Elkeid は ByteDance の内部ベスト プラクティスに由来しており、サーバー/コンテナ/サーバーレスなどの複数のワークロードの侵入防止機能をネイティブに統合し、サーバーとコンテナの侵入防止、コンテナ クラスタの侵入防止、およびアプリケーションのランタイム保護をカバーします。保護)、脅威の追跡とハンティング、ワークロード資産のインベントリ、ワークロードの脆弱性の発見、危険性の分析、その他の機能を備え、企業が統合ソリューションをより適切に実装できるようにするオープン ポリシー エンジンを提供し、クラウド上およびクラウド外のワークロードのセキュリティを確保します。
Elkeid は、ByteDance の社内セキュリティおよびリスク管理チームが自社開発した新しいホスト セキュリティ ソリューションであり、いくつかの特徴的な機能を備えています。
- 1 つは、ByteDance の数百万台のサーバーをサポートできる大規模なものです。もちろん、これに関しては、ByteDance の内部サーバーの規模についても少しネタバレします。
- もう 1 つの特徴は、Elkeid がカーネル状態テクノロジーを使用してほとんどのインジケーターと情報を収集することです。
- これにより、パフォーマンスが大幅に向上する一方で、より多くの豊富なデータを収集できるため、検出機能が大幅に向上します。
現在、エルケイド製品版の導入規模は100万レベルに達しており、その安定性、性能、データ収集能力、検知能力、トレーサビリティ能力はすべて実戦で検証され、良好な性能を発揮しています。
製品の利点
- 数百万のエージェント向けのバックエンド アーキテクチャ ソリューション
- 分散型、分散型、クラスターの高可用性
- シンプルなデプロイ、依存関係の少なさ、メンテナンスの容易さ
注: この製品は完全にはオープン ソースではありません。現時点 (2023-9) では、Elkeidup 自動展開ツールとハブはオープン ソースではなく、フロント エンドもオープン ソースではありません。
2.エルケイドサーバー
大規模なエージェントの監視、管理、ポリシー更新を実現するには、Elkeid Server をエンドのデータ収集層 (Elkeid Driver/Agent) と併用する必要があります。さまざまな複雑なネットワーク環境に適応でき、単一マシンまたはクラスターに導入できます。特定の展開計画については、リポジトリにアクセスして表示してください。
オープンソースのアドレス: https://github.com/bytedance/Elkeid/tree/main/server
3. Elkeidサーバーのアーキテクチャ
Elkeid Server には通常、次の 4 つのモジュールが含まれています。
-
AgentCenter: エージェントとの通信、エージェント データの収集、単純な処理後のメッセージ キュー クラスター ( Kafka クラスター) への要約を担当し、エージェントのアップグレード、構成変更、タスク配信などのエージェントの管理も担当します。
-
ServiceDiscovery: バックグラウンドの各サービス モジュールは、定期的にサービス情報を ServiceDiscovery センターに登録して同期し、各サービス モジュールのインスタンスが相互に認識され、直接通信が容易になるようにする必要があります。
-
マネージャー: バックエンド全体を管理し、関連するクエリと管理インターフェイスを提供する責任を負います。
-
リアルタイム/オフライン コンピューティング モジュール: コンシューマ サーバーはメッセージ キュー内のデータを収集し、リアルタイムおよびオフラインの分析と検出を実行します。(この部分はまだオープンソースではありません)
簡単に言うと次のとおりです。
-
AgentCenter はエージェント データを収集します
-
Manager は AgentCenter とこれらのコンピューティング モジュールを管理します
-
ServiceDiscovery は、これらすべてのサービスとノードを直列に接続します
-
リアルタイム/オフライン コンピューティング モジュールはこれらのデータを分析および検出します
Elkeid バックエンドには通常、次の 5 つのモジュールが含まれています。
-
AgentCenter (AC) は、エージェントとの通信、エージェント データの収集、簡単な処理、メッセージ キュー クラスターへの要約を担当し、また、エージェントのアップグレード、構成変更、タスク分散などを含むエージェントの管理も担当します。同時に、AC は外部への HTTP インターフェースも提供しており、Manager はこれらの HTTP インターフェースを通じて AC と Agent を管理および監視します。
-
ServiceDiscovery (SD) では、バックグラウンドの各サービス モジュールがサービス情報を SD センターに定期的に登録して同期し、各サービス モジュールのインスタンスが相互に認識され、直接通信が容易になるようにする必要があります。SD は登録された各サービスのステータス情報を保持しているため、サービス利用者がサービス ディスカバリを要求すると、SD は負荷分散を実行します。たとえば、エージェントが AC インスタンスのリストを要求すると、SD は負荷圧力が最も小さい AC インスタンスを直接返します。
-
マネージャーは、バックエンド全体を管理し、関連するクエリと管理インターフェイスを提供する責任があります。これには、AC クラスターの管理、AC ステータスの監視、AC サービス関連パラメーターの制御、AC を介したすべてのエージェントの管理、エージェントの実行ステータスの収集、エージェントへのタスクの発行が含まれます。同時に、マネージャーはリアルタイムおよびオフラインのコンピューティング クラスターも管理します。 。
-
Elkeid コンソール: Elkeid フロントエンド部分。
-
Elkeid HUB : Elkeid HIDS RuleEngine。
簡単に言うと、AgentCenter はエージェント データを収集し、Elkeid HUB はこれらのデータを分析および検出し、Manager は AgentCenter とこれらのコンピューティング モジュールを管理し、ServiceDiscovery はこれらすべてのサービスとノードを接続し、アラームと資産データは Elkeid コンソールを通じて表示できます。
Elkeid AgentCenter(以下、AC)
一方では、AC はエージェントからデータを収集して予備処理を実行し、処理されたデータを Kafka クラスターに書き込む必要があります (分析モジュールによるその後の使用のために)。このコミュニケーションは双方向です。
同時に、AC は外部への HTTP インターフェースも提供しており、Manager はこれらの HTTP インターフェースを通じて AC と Agent を管理および監視します。
関連技術紹介:
-
通信効率: 何百万ものエージェントが存在するため、このような大量のデータによるバックエンドへのプレッシャーを過小評価することはできません。通信と処理の効率は主に通信プロトコルとエンコード方式に影響されます。さまざまな通信方式を比較した結果、最終的に gRPC 双方向フローを使用することを選択しました。
-
一方、gRPC は HTTP2 プロトコル標準に基づいて設計および開発されており、他の RPC フレームワークと比較して、双方向ストリーミング、ヘッダー圧縮などのより強力な機能を備えています。これらは現在のニーズに非常に適しており、通信効率も非常に高いです。
-
一方、エンコード方式として Protobuf を使用します。Protobuf は標準の IDL と IDL コンパイラを備えており、シリアル化されたデータは非常に簡潔でコンパクトであり、さらにエンコードとデコードの速度も多くのシリアル化プロトコルの中でトップクラスです。
-
-
通信セキュリティ: エージェントは root 権限を持つアプリケーションであり、サーバーはエージェントに指示を発行する機能を備えているため、通信リンクが制御されると、致命的な事態が発生します。ここでは双方向 SSL 検証を使用します。これにより、エージェント/サーバーが未知のピアと通信しないことが保証される一方で、SSL は通信プロセス中のデータが暗号化されることも保証します。
概要: grpc 双方向ストリーム + 双方向 SSL 検証。
Elkeid Service Discovery(以下、SD)
サービス検出/負荷分散メカニズムには大きく 2 つの設計アイデアがあり、1 つは集中プロキシ、もう 1 つはターミナル プロキシです。
F5 や nginx などの集中型プロキシ メソッドでは、リクエストはまず集中型プロキシ ポイントに送信され、次にプロキシが特定の負荷分散アルゴリズムに従ってリクエストを転送します。サービス応答は最初にプロキシ ポイントに送られ、次に次のサーバーに転送されます。要求する側。この方法が最も一般的ですが、エージェントを往復させるとリクエストの応答遅延が大きくなるという 2 つの問題があり、大規模な導入環境ではこの解決策を使用できません。
関連技術紹介:
-
サービス プロバイダーは、サービス名、インスタンス IP、ポート、負荷ステータスなどを含む登録情報を SD に定期的に送信し、SD がすべてのサービス インスタンスのステータスを維持できるようにします。
-
SD サービスでは、さまざまなノード間でデータの同期が必要です。たとえば、上記 1 の登録情報が NodeA に送信されます。NodeA は、この情報を NodeB に同期する必要があります。これにより、NodeB へのアクセス要求があった場合、NodeB にも対応する登録情報。
-
サービス利用者は、サービス名を通じてサービス検出/登録センターにリクエストを行うことで、対応するサービス名で利用可能なインスタンスIPとポートリストを取得し、直接アクセスすることができます。
-
SD ノード間のデータ同期はブロードキャスト方式で一括同期され、一定レベルのパフォーマンスが保証されます。特定の時点でのノード間のデータは一貫性がありませんが、最終的には一貫性を保つことができ、これは分散 CAP 理論の AP を満足させ、大規模なエージェントおよび AC シナリオには影響を与えません。さらに、整合性ミドルウェア (etcd、Zookeeper など) が使用されないため、展開と保守が簡単になります。
-
SD は登録された各サービスのステータス情報を保持しているため、サービス ユーザーがサービス ディスカバリを要求すると、SD は負荷分散を実行します。たとえば、エージェントが AC インスタンス リストの取得を要求した場合、SD は負荷圧力が最も低い AC インスタンスを直接返します。
エルケイドマネージャー
Manager はバックエンド全体を管理し、さまざまなクエリおよび管理インターフェイスを提供します。これには、AC クラスターの管理、AC ステータスの監視、AC サービス関連パラメーターの制御、AC を介したすべてのエージェントの管理、エージェントの実行ステータスの収集、エージェントへのタスクの発行が含まれます。同時に、マネージャーはリアルタイムおよびオフラインのコンピューティング クラスターも管理します。 。
Manager は各クラスターをバックグラウンドで管理するため、すべての管理操作はクラスターに対する操作になります。Manger を呼び出すインターフェイス要求は、Manager を通じてターゲット クラスター内のすべてのノードに転送され、すべてのノードからの応答が収集されて処理されます。このプロセスの応答速度と安定性を向上させるために、Manager は内部にシンプルな分散タスク管理システムを実装しています。
3. Huawei Cloud で Elkeid をインストール、展開、試してみる
1.HUAWEI CLOUDホストの準備
- Huawei クラウド ホストを購入します。この評価の評価システムは次のとおりです。
2. 新しいセキュリティ グループを作成し、すべてのポートを開発してテストを容易にし
、セキュリティ グループを変更します。次のように、すべてのポートを開発するセキュリティ グループを選択します。
- すべてのポートを開発したら、ssh~ を使用して Huawei クラウド ホストにログインできます。
2. Elkeidのインストールと設定
公式リファレンス: http://elkeid.bytedance.com/docs/elkeidup/deploy-zh_CN.html基本的には
公式ドキュメントを参照できます。
評価環境のリソースが限られているため、公式の docker インストールを使用して Elkeid~
0 を試します。最初に docker をインストールします
yum install docker
1. スタンドアロン Docker の迅速な展開 (スタンドアロン テスト環境に推奨)
注: ホストとして centos 7.x または debian 9/10 を優先してください。コンテナ内のサービスは systemd に依存しており、systemd は cgroup を使用します。コンテナ内とコンテナ外のsystemdのバージョンが違いすぎるため、コンテナ内のsystemdが異常動作し、対応するサービスを起動できなくなります。
1.1. 画像のインポート
# 从release下载的是分卷的镜像,需要先合并镜像
wget https://github.com/bytedance/Elkeid/releases/download/v1.9.1.4/elkeidup_image_v1.9.1.tar.gz.00
wget https://github.com/bytedance/Elkeid/releases/download/v1.9.1.4/elkeidup_image_v1.9.1.tar.gz.01
wget https://github.com/bytedance/Elkeid/releases/download/v1.9.1.4/elkeidup_image_v1.9.1.tar.gz.02
wget https://github.com/bytedance/Elkeid/releases/download/v1.9.1.4/elkeidup_image_v1.9.1.tar.gz.03
cat elkeidup_image_v1.9.1.tar.gz.* > elkeidup_image_v1.9.1.tar.gz
個人的なテストでは、HUAWEI CLOUD のダウンロードが非常に遅いため、Xunlei でダウンロードして自分でアップロードすることをお勧めします。
#导入镜像
docker load -i elkeidup_image_v1.9.1.tar.gz
1.2. コンテナの実行
docker run -d --name elkeid_community \
--restart=unless-stopped \
-v /sys/fs/cgroup:/sys/fs/cgroup:ro \
-p 8071:8071 -p 8072:8072 -p 8080:8080 \
-p 8081:8081 -p 8082:8082 -p 8089:8080 -p 8090:8090\
--privileged \
elkeid/all-in-one:v1.9.1
1.3. 外部IPを
ローカルIPを使用するように設定する 127.0.0.1は使用できません。
docker exec -it elkeid_community bash
cd /root/.elkeidup/
# 命令为交互式
./elkeidup public {
ip}
./elkeidup agent init
./elkeidup agent build
./elkeidup agent policy create
cat ~/.elkeidup/elkeid_passwd
elkeid をインストールするために 2C2G をテストした後、エラーは次のようになります。メモリが小さすぎると推定されます。2C4Gマシンで再度検証
しましたが、やはり同じ競合が報告されました。バイト elkeipdup はオープン ソースではないため、理由は次のとおりです。不明 (おそらくリソース サイズの問題です。私のローカルではインストール テストでは問題ありません)~
この評価は当面ここで処理されます~~
3. Docker のインストールプロセス中に発生した問題の記録
docker 报错:unix:///var/run/docker.sock の Docker デーモンに接続できません。docker デーモンは実行されていますか?
このエラーは、Docker デーモンに接続できないことを意味します。一般的な理由は次のとおりです。
- Docker デーモンが実行されていません。Dockerサービスが実行されているかどうかを確認するために
使用できます。実行されていない場合は、それを使用して開始できます。sudo systemctl status docker
sudo systemctl start docker
sudo systemctl start docker
sudo systemctl enable docker
docker报错: その名前によるチェーン/ターゲット/一致はありません。
完全なエラー メッセージ:
[root@dev elkeid]# docker run -d --name elkeid_community \
> --restart=unless-stopped \
> -v /sys/fs/cgroup:/sys/fs/cgroup:ro \
> -p 8071:8071 -p 8072:8072 -p 8080:8080 \
> -p 8081:8081 -p 8082:8082 -p 8089:8080 -p 8090:8090\
> --privileged \
> elkeid/all-in-one:v1.9.1
5f24d42cfccf965d9a3ce6b7e5323049ff4fb9ef09d3ad1541b2391b28e3385b
/usr/bin/docker-current: Error response from daemon: driver failed programming external connectivity on endpoint elkeid_community (fd39db5e047de94bbba8f65474cf54ea9605062b36e630e4c46de56fe782c3e9): (iptables failed: iptables --wait -t nat -A DOCKER -p tcp -d 0/0 --dport 8090 -j DNAT --to-destination 172.17.0.2:8090 ! -i docker0: iptables: No chain/target/match by that name.
(exit status 1)).
問題分析: この問題は、docker run コマンドを使用してコンテナーを起動するときに、Docker がコンテナーのポート マッピング ルールを設定できないことです。
具体的には、iptables を使用して DNAT ルールを追加することが失敗し、指定されたチェーン、ターゲット、または一致が iptables にないことを示唆しています。
この問題は、デフォルトで iptables または iptables の nat モジュールをインストールしない一部の最小限の Linux ディストリビューションでよく発生します。
問題が解決しました:
- iptables と iptables の nat モジュールがホストにインストールされていることを確認してください
yum install iptables-services -y
- iptablesのnat機能を有効にする
modprobe iptable_nat
- Dockerサービスを再起動します
systemctl restart docker
4.エルケイドの使用
インストールが成功すると、コンテナの/root/.elkeidup/elkeid_passwd
ファイルに各コンポーネントのパスワードと関連 URL が記録されます。
elkeid_console にアクセスし、インストール構成インターフェースのコマンドに従ってエージェントをインストールおよびデプロイします。
4. 参考資料
【Elkeid Strategy】Fighting Hackers: How to Use Elkeid to Build Intrusion Detection Capabilities
参考URL: https://www.zhihu.com/column/c_1411384767867162624
ByteDanceはどうやってオープンソースプロジェクトを0から1まで構築するのか?
参考URL:https://www.51cto.com/article/711324.html