Hydra スレッド数を調整する

はじめに

この実験では、強力なネットワークログインクラッカーである Hydra でスレッド数を調整し、そのパフォーマンスを最適化する方法を学びます。LabEx 仮想マシン上に基本的な SSH サーバーを設定し、Hydra を使用して異なるスレッド数（16、32、および 4）でパスワードクラッキングを試みます。これらの異なる設定による速度の比較と効果を観察することで、利用可能なリソースとターゲットサービスの特性に基づいてスレッド数を調整することで、Hydra 攻撃を最適化する方法を理解できます。

SSH サーバーの設定

このステップでは、LabEx VM 上に基本的な SSH サーバーを設定します。SSH（Secure Shell）は、暗号化されたネットワークプロトコルであり、非安全なネットワーク上でネットワークサービスを安全に運用するために使用されます。リモートコマンドラインログインやリモートコマンド実行によく用いられます。

最初に、OpenSSH サーバーをインストールする必要があります。OpenSSH は、Secure Shell プロトコルに基づくセキュリティ関連のネットワークレベルツールスイートであり、最も一般的な SSH 実装です。

LabEx VM のターミナルを開きます。デフォルトの Xfce ターミナルを使用できます。

パッケージリストを更新するために、以下のコマンドを実行します。

sudo apt update

このコマンドは、パッケージインデックスファイルをソースから同期します。新しいソフトウェアをインストールする前に実行することは良い習慣です。パスワードの入力を求められる場合がありますが、labexユーザーはパスワードなしでsudo権限を持っています。

次に、OpenSSH サーバーをインストールします。

sudo apt install openssh-server -y

-yフラグは、インストール中のプロンプトに自動的に「yes」と回答し、インタラクティブなプロセスを回避します。

インストールが完了すると、SSH サーバーは自動的に起動するはずです。以下のコマンドを使用して、そのステータスを確認できます。

sudo service ssh status

SSH サーバーが動作していることを確認するために、SSH ポート（ポート 22）がリスニングしているかどうかを確認できます。netstatコマンドを使用します。

netstat -tulnp | grep 22

出力は次のようになります。

tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN      -
tcp6       0      0 :::22                   :::*                    LISTEN      -

これは、SSH サーバーが IPv4 および IPv6 接続の両方に対してポート 22 でリスニングしていることを示しています。

SSH サーバーの設定が完了したので、別のマシンから SSH クライアントを使用して接続できます。ただし、この実験では、Hydra を使用して異なるスレッド構成で SSH パスワードをクラッキングすることに焦点を当てます。

デフォルトの 16 スレッドで Hydra を実行する

このステップでは、Hydra を使用して、SSH サーバー上のlabexユーザーのパスワードをクラッキングしようとします。最初に、Hydra のデフォルトのスレッド数である 16 を使用します。

パスワードリストは、セットアッププロセス中に既にダウンロードされています。ファイル~/project/password.txtには、Metasploit フレームワークのunix_passwords.txtワードリストが含まれており、数百個の一般的な Unix パスワードが含まれています。このより大きなワードリストは、小さな手動リストと比較して、スレッドのパフォーマンスの違いをより良く示します。

パスワードリストが利用可能であることを確認し、そのサイズを確認できます。

ls -la ~/project/password.txt
wc -l ~/project/password.txt

これにより、ファイルの詳細とワードリスト内のパスワードの数（数百個の項目である必要があります）が表示されます。

次に、Hydra コマンドを実行します。-lオプションは攻撃対象のユーザー名 (labex) を、-Pオプションはパスワードリストのパス (~/project/password.txt) を、-Vオプションは詳細モードを有効にして各試行を表示します。ssh://localhostは、ローカルマシンの SSH サービスを対象としていることを示します。

hydra -V -l labex -P ~/project/password.txt ssh://localhost

Hydra は、password.txtファイル内の各パスワードを使用して、SSH サーバーへのログインを試行し始めます。-tオプションを指定していないため、Hydra はデフォルトの 16 スレッドを使用します。つまり、16 個のパスワード試行を同時に実行します。-Vフラグは、各試行をリアルタイムで表示します。

-Vフラグに関する重要な注意事項：

-V（詳細）パラメータは、攻撃プロセスを観察するために非常に重要です。これを指定しないと、Hydra は概要情報と最終結果のみを表示しますが、各パスワードのテストを示す個々の[ATTEMPT]行は表示されません。この詳細な出力は、スレッドが攻撃速度とパターンにどのように影響するかを理解するのに役立ちます。

Hydra が進行するにつれて、次の出力と同様のものが表示されます。

Hydra vX.Y (c) YYYY by van Hauser/THC - Use freely but only for legal purposes.

Hydra starting at YYYY-MM-DD HH:MM:SS
[DATA] max 16 tasks per 1 server, overall 16 tasks, XXX login tries (l:1/p:XXX), ~XX tries per task
[DATA] attacking ssh://localhost:22/
[ATTEMPT] target: localhost - login: labex - pass: !@#$%
[ATTEMPT] target: localhost - login: labex - pass: !@#$%^
[ATTEMPT] target: localhost - login: labex - pass: 000000
...
[22][ssh] host: localhost   login: labex   password: labex
1 of 1 target successfully completed, 1 valid password found
Hydra finished at YYYY-MM-DD HH:MM:SS

より大きなワードリストを使用すると、Hydra が正しいパスワードを見つけるまでに時間がかかることに気づき、スレッド数の違いがより明確になります。Hydra が完了したときに Hydra が提供する時間情報を観察してください。

スレッド数を 32 に増やし、速度を比較する

このステップでは、Hydra が使用するスレッド数を 32 に増やし、クラッキング速度への影響を観察します。スレッド数を増やすことで、同時試行数を増やし、プロセスを高速化できる可能性がありますが、その有効性は、システムのリソースとターゲットサービスの制限によって異なります。

ターミナルで以下のコマンドを実行し、Hydra を 32 スレッドで実行します。

hydra -V -t 32 -l labex -P ~/project/password.txt ssh://localhost

このコマンドは前のコマンドと同一ですが、-t 32を追加した点が異なります。これは、Hydra に 32 スレッドを使用するように明示的に指示します。-Vフラグは、各パスワード試行を表示できるようにします。

出力を観察してください。Hydra が 32 個のタスク/スレッドを開始したことを報告するはずです。

Hydra vX.Y (c) YYYY by van Hauser/THC - Use freely but only for legal purposes.

Hydra starting at YYYY-MM-DD HH:MM:SS
[DATA] max 32 tasks per 1 server, overall 32 tasks, XXX login tries (l:1/p:XXX), ~XX tries per task
[DATA] attacking ssh://localhost:22/
[ATTEMPT] target: localhost - login: labex - pass: !@#$%
[ATTEMPT] target: localhost - login: labex - pass: !@#$%^
[ATTEMPT] target: localhost - login: labex - pass: 000000
...
[22][ssh] host: localhost   login: labex   password: labex
1 of 1 target successfully completed, 1 valid password found
Hydra finished at YYYY-MM-DD HH:MM:SS

速度の比較：

より大きなワードリストを使用すると、16 スレッド実行と 32 スレッド実行の間でより顕著な時間差を観察できるはずです。以下の点に注意してください。

Hydra が報告する開始時間と終了時間
ワークロードの分散を示す「試行回数/タスク」の計算
攻撃を完了するのにかかる総時間

32 スレッドを使用すると、特にターゲットパスワードがワードリストの後の方にある場合、完了時間が速くなる可能性があります。ただし、システムリソースの使用が増加し、同時に実行される接続試行数が増加する可能性もあります。

スレッド数を 4 に減らし、動作を観察する

このステップでは、Hydra が使用するスレッド数を 4 に減らし、パフォーマンスへの影響を観察します。このシナリオは、システムリソースが限られている場合、またはターゲットサービスが過剰なレート制限を設けており、過剰な同時接続試行をブロックする可能性がある場合に役立ちます。

ターミナルで以下のコマンドを実行し、Hydra を 4 スレッドで実行します。

hydra -V -t 4 -l labex -P ~/project/password.txt ssh://localhost

このコマンドは、前のコマンドと似ていますが、-t 4を使用してスレッド数を 4 に明示的に設定しています。-Vフラグは、各パスワード試行の詳細を表示します。

出力を観察してください。Hydra が 4 つのタスク/スレッドのみを開始していることがわかるはずです。

Hydra vX.Y (c) YYYY by van Hauser/THC - Use freely but only for legal purposes.

Hydra starting at YYYY-MM-DD HH:MM:SS
[DATA] max 4 tasks per 1 server, overall 4 tasks, XXX login tries (l:1/p:XXX), ~XX tries per task
[DATA] attacking ssh://localhost:22/
[ATTEMPT] target: localhost - login: labex - pass: !@#$%
[ATTEMPT] target: localhost - login: labex - pass: !@#$%^
[ATTEMPT] target: localhost - login: labex - pass: 000000
...
[22][ssh] host: localhost   login: labex   password: labex
1 of 1 target successfully completed, 1 valid password found
Hydra finished at YYYY-MM-DD HH:MM:SS

影響を観察する：

4 つのスレッドとより大きなワードリストを使用すると、パフォーマンスに大きな違いがあることに気付くはずです。

各スレッドがより多くのパスワードを処理する必要があるため、「試行回数/タスク」の値は大幅に高くなります。
全体的な完了時間は、16 スレッドおよび 32 スレッド実行と比較して、顕著に長くなります。
同時に実行される試行は 4 つしかないため、同時[ATTEMPT]メッセージは少なくなります。

この実験は、スレッド数を減らすと一般的にパフォーマンスが低下しますが、ターゲットシステムのセキュリティ対策による検出を回避する場合や、リソースが限られたマシンで動作する場合など、特定の状況では必要な調整であることを示しています。

スレッド数のパフォーマンスへの影響を分析する

このステップでは、これまでのステップで得られた観察結果に基づき、スレッド数のパフォーマンスへの影響を Hydra で分析します。Metasploit フレームワークから取得した大規模なワードリストを使用して、4、16（デフォルト）、32 スレッドを試行しました。

スレッド数に関する重要な考慮事項：

**システムリソース：**最適なスレッド数は、CPU コア、メモリ、ネットワーク帯域幅など、システムの可用リソースに大きく影響されます。スレッド数を非常に高く設定すると、システムがオーバーロードされ、コンテキストスイッチングオーバーヘッドやリソース競合によるパフォーマンス低下につながる可能性があります。
**ターゲットサービスの制限：**ターゲットサービス（今回の場合、SSH）には、レート制限やその他のセキュリティメカニズムが実装されている可能性があります。サービスが単位時間あたりのログイン試行数を制限している場合、ある一定のポイントを超えてスレッド数を増やしてもパフォーマンスは向上せず、セキュリティアラートや一時的なブロックを引き起こす可能性があります。
**ネットワーク遅延：**Hydra とターゲットサービス間のネットワーク遅延が高い場合も、スレッド数を増やす効果は限定的になります。各スレッドは接続を確立し維持する必要があり、高い遅延はこれらの操作を遅くし、並列処理のメリットを相殺する可能性があります。
**ワードリストのサイズ：**この実験で使用したような大規模なワードリストの場合、スレッド数の違いはより顕著になります。unix_passwords.txtワードリストには数百のエントリが含まれており、異なるスレッド数のパフォーマンスへの影響をより明確に観察できます。

観察結果と一般的なガイドライン：

**4 スレッド：**この設定は一般的に遅いですが、リソースが限られているシステムや、レート制限の厳しいサービスを攻撃する場合に適しています。システムのオーバーロードや即座のセキュリティアラートを引き起こす可能性は低くなります。大規模なワードリストを使用した場合、完了時間は大幅に長くなるはずです。
**16 スレッド（デフォルト）：**Hydra のデフォルトの 16 スレッドは、多くのシステムやターゲットサービスにとって、パフォーマンスとリソース使用量のバランスがとれた設定です。攻撃マシンやターゲットを通常は圧倒することなく、適切な並列処理を提供します。
**32 スレッド：**スレッド数を 32 に増やすことで、システムに十分なリソース（複数の CPU コアなど）があり、ターゲットサービスに過剰なレート制限がない場合、パフォーマンスが向上する可能性があります。ただし、システムのリソース使用状況を監視し、ボトルネックにならないようにすることが重要です。

考慮すべきパフォーマンス指標：

スレッドのパフォーマンスを評価する際には、以下の点を考慮してください。

**総実行時間：**開始から終了までの時間
**毎秒の試行回数：**パスワード試行が行われる速度
**システムリソース使用率：**CPU、メモリ、ネットワークの利用率
**ターゲットサービスの応答：**サービスが応答しなくなったり、ブロックを実装したりするかどうか

結論：

Hydra にとって最適なスレッド数は一概に言えません。最適な設定は、攻撃マシンとターゲットサービスの特定の要因によって異なります。速度とリソース使用量の最も効率的なバランスを見つけるために、さまざまな設定を試行し、システムのパフォーマンスとターゲットの応答を監視することが重要です。これらのダイナミクスを理解することで、さまざまなシナリオで Hydra 攻撃を最適化できます。

まとめ

この実験では、大規模なパスワードワードリストを使用して Hydra のスレッド数を調整し、パフォーマンスへの影響を学びました。まず、LabEx 仮想マシン上に基本的な SSH サーバーを設定しました。次に、Metasploit フレームワークのunix_passwords.txtワードリストを使用して、この SSH サーバーに対して、デフォルトの 16 スレッド、増加させた 32 スレッド、そして減少させた 4 スレッドのそれぞれでパスワードクラッキングを試行しました。現実的なサイズのワードリストを用いた各シナリオの速度と完了時間から、スレッド数が Hydra の効率性にどのように影響するかを実践的に理解しました。この実験は、パスワードクラッキング操作で最適なパフォーマンスを得るために、利用可能なシステムリソースとターゲットサービスの特性に基づいてスレッド数を最適化することの重要性を示しました。