はじめに
password Crakerとして有名な「JTR：john the ripper」。
ハイスペックな単体PCでの運用ではなく、
安いマシンを複数用意して分散処理させようと試みました。(結果、失敗しました)
JTRを諦め、同様のpassword Crakerである「hashcat」を採用します。
その理由をざっくりですがまとめました。
JTRで分散処理を諦めた失敗ポイント
①OpenMPIとJTRの相性が悪い(かった)
②GPU処理を体感できなかった
③Slave追加してもupする演算回数(増加率)が減退していった
構成の概要
JTRは導入しましたが、hashcatはこれからです。
JTR分散処理環境の概要
流行のラズパイで構成しました。
JTRの構成ポイント：
・OpenMPIで分散処理を管理(ssh、nfsサーバが必要)
・OS: Kali (kali-linux-2019.1-rpi0w-nexmon.img)
※構築手順などは順次更新予定
hashcat分散処理環境の概要
ラズパイを使いこれから導入する予定です
hashcatの構成ポイント：
・処理の総量が計算でき、実行範囲を分割した分散処理が可能
→6桁パスワード(95文字)クラックを分散処理したい時
総量：「735,091,890,625」をhashcatで計算し
1台目：1～1000億
2台目：1000億～2000億
：
3代目：～735,091,890,625
・・・といった範囲指定で実行可能。
・OS: kaliもしくはraspbian ※予定
失敗ポイントの所感
①OpenMPIとJTRの相性が悪い(かった)
MPIを使ってJTRを実行した場合、
処理ステータスの確認がうまくいかない(かった)。
→Slaveでの実行プロセスが常に完了と表示。
また、処理中断オプションが使えなかった。
→「session」「restore」オプションで中断・再開処理が失敗。
また、1台不具合が起きると悪影響が全体に及んだ。
②GPU処理を体感できなかった
JTRはGPU演算に対応しているのですが、クラックするhash別に
あれはできる、これはできないこれは早いよ？みたいな書きっぷりでした。
https://openwall.info/wiki/john/GPU
※テストコマンドの実行結果もよくよく確認したのですが
GPU処理を行っている形跡はありませんでした。
一方、「hashcat」はそもそもGPUでの処理を目指しているイメージ。
https://hashcat.net/wiki/doku.php?id=hashcat
JTRにしろ、hashcatにしろGPU処理導入は少し難儀しそうですが
導入してみたいなぁとは思っています。
※ラズパイのGPUは「VideoCore IV」であり、
openCLがサポートする「NVidia」「AMD」製品ではりません。
ですが、GPU処理はいくつかの事例を確認しているため
ひょっとしたら導入できるかもしれません。
http://asukiaaa.blogspot.com/2018/11/raspberry-pigpuopencl.html?m=1
導入できた場合、3B+とZero Wは同じGPUを搭載しているため、
より安価にエコに処理速度を上げることができる可能性もあります。
③Slave追加してもupする演算回数(増加率)が減退していった
1台→2台→3台と構成を増やしたとき、演算処理の増加率が減退していきました。
ラズパイ単体で20000回の演算を行う性能があったとして、MPIを利用した分散処理は
2台目追加 +18000回up
3台目追加 +16000回up
といった具合に少しづつ減退していくため、
台数に単純比例するhashcatの方が魅力的です。
まとめ
JTRに不具合が発生した時は構成全体に影響し、再実行処理も現状うまくいかず
改善するのに手間もスキルも必要なことが、今回hashcatで再構成する最大の理由です。
hashcatは、「--keysotre」で総量を出力し、
「-s」「-l」で範囲指定すると処理を分割できます。(これから試します)
範囲指定のみで分散処理が実現できるので、
単体で処理を行っているのと変わりません。
構成が非常にシンプルです。シェル化も容易です。
分散処理を自動化する「hashtplis」なども気になります。
構成が単純なため、不具合が発生しても全体に与える悪影響は限定的で、
シンプルな分、再実行も単体実行時と同じように実現可能と考えています。
最後にJTRに関するログ・コマンドなど一切を割愛している点
今後ちょいちょい改善していく予定ですのでご容赦いただきたくお願いいたします。
おしまい