web-dev-qa-db-ja.com

Hydraはワードリストファイルをタスク/スレッドと同じ数の部分に分割していますか？

Hydraとxmpp認証で遊んでいます。

私は自分の基本的なxmppサーバーを作成し、クリアテキストのpcapファイルから認証（サーバー側）を再現しました。接続処理で何か問題が発生したと思います（新しい接続ごとに1つのスレッドを作成していますが、エラーが発生すると閉じます）。ただし、これは私のポイントではありません。

このスケーラビリティの問題を修正しました。興味のある方は、最初の再生ではなく、Hydraによる最適化が原因でした。「Helloリクエスト」と呼びましょう。通常の認証には、クライアントからの4つの要求または応答、サーバーからの4つのパケットも必要です。そして、この最適化は最初のものをスキップし、2番目にまっすぐ進みます。それは私の場合のように見えます：<auth xmlns='urn:ietf:params:xml:ns:xmpp-sasl' mechanism='SCRAM-SHA-1'/>

統計/情報：

  • VM：2 CPU、2 GB RAMの設定。
  • ワードリスト内のパスワードの場所：60K中795番目。
  • 単一のタスク：パスワードを見つけるために〜50回/分->〜17分。
  • 16タスク：約820回/分-> 1時間14分、pwを見つけることなく完了します（接続処理の問題のため）。

新しい統計（最適化後）：

  • 単一のタスク：〜90回/分-> 9分13秒
  • 16タスク：〜1400 +試行/分-> 33秒

問題は、Hydraがワードリストを16の等しい部分に分割しているかどうかです。そしてどうやって？

1つのサイズは約3.8kのパスワードです。スレッド1は最初の3.8kパスワードで機能していますか？スレッド2は3801rst-> 7600で動作していますか？スレッド16まで続きますか？最後にテストされた16個のパスワードが3799番目、7599番目などになるように？

他の可能性は、たとえばスレッド1がワードリストから1％16（モジュロ）のパスワードごとに進行するため、1つのタスク（/スレッド）しか実行していない場合と同じ順序でパスワードがテストされることです。

私はそれを自分でテストすることができますが、誰かがすでにそうしたなら、私の闇を啓発してください。

passwordshydra
2
T. Rode

答えを見つけました。

Hydraは、並列に処理される各「サブファイル」を作成するためにモジュロ[タスク数]を実行していると思います。どうして ？ 99％は同じ一連のパスワードテストであるため、同じ順序で処理されます。

つまり、パスワード番号1は、16タスクを起動する番号1としてテストされ、パスワード番号2000は、16タスクのヒドラ処理で2000番目の位置でもテストされます。

これは、スレッド/タスク1がパスワード1、17、33、49を処理することも意味します...

スレッド/タスク2は、パスワード2、18、34、50などを処理します。

そしてもちろん、1つのタスクだけでhydraを起動した場合、パスワードは順番に、つまり同じ順序で処理されます。

私はそれを8kのパスワードでテストしましたが、ほとんどの場合、どちらの場合も同じ順序であり、ほとんど変化がありません。

0
T. Rode