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つのタスク(/スレッド)しか実行していない場合と同じ順序でパスワードがテストされることです。

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

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