このZookeeperインスタンスを悪用することは可能ですか？
Zookeeper xx.x.x.xx：2181のインストールに遭遇したとき、クライアントのセキュリティテストを実行していました。 NetCatを試したところ、次のすべてのコマンドを実行できることがわかりました。
dump：未解決のセッションと一時ノードを一覧表示します。これはリーダーでのみ機能します。
envi：サービス環境に関する詳細を出力します
kill：サーバーをシャットダウンします。これは、ZooKeeperサーバーが実行されているマシンから発行する必要があります。 （これは試したことがない）
reqs：未処理の要求を一覧表示します
ruok：サーバーが非エラー状態で実行されているかどうかをテストします。サーバーが実行中の場合、サーバーはimokで応答します。それ以外の場合は、まったく応答しません。
srst：statコマンドによって返される統計をリセットします。
stat：パフォーマンスと接続されているクライアントに関する統計を一覧表示します。
私はZookeeperに慣れていないので、これが愚かな質問のように聞こえますが、Zookeeperは認証なしでアクセスできるはずですか？また、このアプリケーションを公開することの意味は何ですか？
どんな助けでも本当に感謝しています、ありがとう
まず第一に、私はZookeeperにもまったく詳しくありませんが、セキュリティの観点から一般的なアドバイスを提供できます。
Zookeeperコマンド 管理機能のように聞こえます。つまり、認証後にのみアクセスできるようにしたり、プライベートネットワーク内だけにアクセスしたり、特定のIPアドレスからのみアクセスできるようにする必要があります。
管理されたテスト環境をテストしている場合は、管理者に連絡して、killコマンドをテストする時間を計画することをお勧めします。これにより、このような方法で実際に機能するかどうかが確認されます。もしそうなら、クラスタ内のすべてのZookeeperサーバーを見つけ、それらすべてをkillにして、サービスをシャットダウンするようなものを想像できます。セキュリティ専門家は、それを可用性リスクと呼ぶでしょう。倫理的なハッカーや脚本家は、それを改ざんと呼ぶでしょう。
繰り返しになりますが、Zookeeperについての知識はありませんが、以下の理論的なリスクを想像できます。
dumpはセッションを表示します。公開されている正確なセッション情報によっては、そのようなセッションを偽装しようとするときにシステムを混乱させる可能性があります。整合性に影響を与える可能性があります。enviは、情報に応じて、それを使用してターゲットのより良いビューを取得し、その情報によって他の関連システムが見つかった場合にスコープを広げることができることを示しました。kill以前に気づいたように、可用性のリスク、そしておそらくこのコマンドのリストの最大のリスク。reqs情報の開示、および情報によっては、なりすましによってプロセスが混乱する可能性があります。ruok単純な情報開示です。Zookeeperに固有の脆弱性があり、エラー以外の状態で実行されている場合にのみ機能することがわかっている場合を除き、リスクは想像できません。繰り返しますが、エラー状態/非エラー状態は、「状態固有の」脆弱性が機能する可能性が50％の確率です。実際の状態を知ると、バージョンとすべてが一致すると、理論的には100％に増加します。srst正確にリセットする統計によっては、ハッキングの試行後にトレースを消去できる場合があります。トラックを消去しています。stat情報開示。システムおよびおそらくインフラストラクチャーに不必要な洞察を与えることで、スコープを広げるために使用できる可能性があります。
私の一般的なアドバイスになります。このシステムがその種のコマンドをだれからも受け入れないようにします。 VPNやIP制限などの認証レイヤーを追加するか、Zookeeper内で認証機能を有効にします（存在する場合）。これにより、情報が不必要に開示されないようになり、killコマンドによって発生する可能性のある可用性のリスクが軽減されます。
kill自体は脆弱性ではありませんが、リスクがあります。 [〜＃〜] cvss [〜＃〜] スコアリングシステムを使用して、killが実際に機能し、攻撃の正確な背景と要因に応じて、可用性のCVSSを推定した場合7.1（高）などのリスク （AV：N/AC：M/Au：N/C：N/I：N/A：C） 。
また、これをチェックすることもできます。
ZooKeeperはクラスター管理ツールです。 クライアントノードを接続する できるかどうかを最初に確認します。内部ネットワークに既に侵入しているようです（ほとんどのクラスターツールはネットワークレベルで保護されています）。クライアントノードを接続できる場合は、文字どおりgetDataを使用できます。 要するに、はい、これは脆弱性である可能性があります。
クライアントノードに接続するには、独自のサーバーの電源を入れ、クライアントのZooKeeper依存関係と インストールガイドに従ってください をインストールします。ノードが接続した場合（使用した場合）に使用できるコマンドのリストが表示されます。
クライアントノードがまっすぐに接続しない場合、心配しないでください。希望があります... マスター自体に接続 および 一部の設定を変更 特にskipACLコマンド。また、いつでもバッファオーバーフロー攻撃を試すことができることに注意してください（マスターだけでなくクライアントノードでも）。
いくつかの言語（Java/C）で作業/コマンドをマスターに送信できるので、クラスターを管理している人は使用量が増えるので、まず自分のインスタンスでこれをすべてテストすることをお勧めします。
さらに、ほとんどのビッグデータクラスターは何らかのNFSを使用するか、分散FS Lustreのように使用します。Lustreも本質的に安全ではない（ファイアウォール/ネットワークレベルで保護されている）ので、自由に利用してみてください。上手。
Zookeeperマスターと同じノードで実行されている可能性があるその他のソフトウェアは、Spark、Hadoop、Mesos、Ganglia、Pig、Hue、Hive、およびその他の多くのビッグデータ分析ソフトウェアです。そのため、これらの発見エクスプロイトもいくつか記述します。 ...
リストしたコマンドは "The Four Letter Words" として文書化されており、本質的に危険ではありません（ただし、Intelは他の攻撃につながる可能性があります）。ただし、これらは上記の構成の悪用を示している可能性があります。