added update command #391

[hitenkoku]

closed #391

feature

• U --rule_updateオプションを追加
  • rulesフォルダがあればエラー文を出して終了。
  • rulesフォルダがなければhayabusa-rulesフォルダをcloneして終了。

evidence

• help画面

• rulesフォルダが既に存在する場合
  

• rulesフォルダが存在しない場合

[YamatoSecurity]

早速ありがとうございます！
動作確認しました。

まず、hayabusaだけを実行した時に更新しようとします。更新は-u / --update-rulesオプションが指定された時だけにして、hayabusaだけを実行する場合は今のまま、ヘルプメニューを出力したいです。

また、更新時に手動でrulesディレクトリを名前変更したり、削除したりすると手間がかかるので、最初のダウンロードはgit cloneで良いですが、その後の更新はgit pullの方が良いのでは？

オプション名はUTCが普段大文字なので、-u / --utc を　-U / --UTC （もしくは--utc)にして、ルール更新のオプションを -u / --update-rules にしても大丈夫ですか？

[hitenkoku]

@YamatoSecurity
ご指摘内容は以下で問題ないですか？間違いがないかご確認をお願いします。

• --rule-updateのオプションを指定していなければhelpを出す旨承りました。こちらはバグでしたので修正します。
• git pullを利用する場合だとユーザがルールの更新をしてしまっていた場合、衝突が起こってしまう可能性があります。もともとのニーズ(submodule指定をし忘れてしまい最新版のルールを取得するようにしたい)を満たすのであればgit cloneで十分かなと思っていましたがどうですか？更新を行うとしたらrulesフォルダが存在したらgit fetch + mergeを行うことになります(git pullに該当する関数がgit2になかったのでfetchとmergeをやって同様のことを行います)
• -u --utcを -Uオプションを割り当て、--rule-updateは-uにする

[hitenkoku]

以下の二つは 70771a5 時点で対処完了しました。

• --rule-updateのオプションを指定していなければhelpを出す旨承りました。こちらはバグでしたので修正します。
• -u --utcを -Uオプションを割り当て、--rule-updateは-uにする

[YamatoSecurity]

ありがとうございます！

空のrulesディレクトリで試していますが、この感じでプロンプトに戻るだけです。
あと、--rule-updateを--update-rulesに変更できますか？

[hitenkoku]

@YamatoSecurity 大変失礼いたしました。オプションの名前が一致していませんでしたので修正をしておきました。
c4d34e5 で対処完了しました。

PS >.\hayabusa.exe -u
[ERROR] Failed git clone to rules folder. Please renme rules folder name. 'rules' exists and is not an empty directory; class=Invalid (3); code=Exists (-4)
PS >.\hayabusa.exe

...
USAGE:
-d --directory=[DIRECTORY] 'Directory of multiple .evtx files'
-f --filepath=[FILEPATH] 'File path to one .evtx file'
-r --rules=[RULEDIRECTORY/RULEFILE] 'Rule file or directory (default: ./rules)'
-o --output=[CSV_TIMELINE] 'Save the timeline in CSV format. Example: results.csv'
-v --verbose 'Output verbose information'
-D --enable-deprecated-rules 'Enable sigma rules marked as deprecated'
-n --enable-noisy-rules 'Enable rules marked as noisy'
-u --update-rules 'Clone latest hayabusa-rule'
-m --min-level=[LEVEL] 'Minimum level for rules (default: informational)'
--start-timeline=[STARTTIMELINE] 'Start time of the event to load from event file. Example: '2018/11/28 12:00:00 +09:00''
--end-timeline=[ENDTIMELINE] 'End time of the event to load from event file. Example: '2018/11/28 12:00:00 +09:00''
--rfc-2822 'Output date and time in RFC 2822 format. Example: Mon, 07 Aug 2006 12:34:56 -0600'
--rfc-3339 'Output date and time in RFC 3339 format. Example: 2006-08-07T12:34:56.485214 -06:00'
-U --utc 'Output time in UTC format (default: local time)'
-t --thread-number=[NUMBER] 'Thread number (default: optimal number for performance)'
-s --statistics 'Prints statistics of event IDs'
-q --quiet 'Quiet mode. Do not display the launch banner'
-Q --quiet-errors 'Quiet errors mode. Do not save error logs.'
--contributors 'Prints the list of contributors'

[YamatoSecurity]

ありがとうございます。rulesフォルダに何も無い場合は最初のgit cloneはできるけど、その後の更新はまだできません。

user@504-MBP hayabusa % ./target/release/hayabusa -u
Finished clone hayabusa-rules repository.
user@504-MBP hayabusa % ./target/release/hayabusa -u
[ERROR] Failed git clone to rules folder. Please renme rules folder name. 'rules' exists and is not an empty directory; class=Invalid (3); code=Exists (-4)

[hitenkoku]

はい、そちらは git clone では対応ができませんし、まだ作っていません(2/3ではgit cloneのみでいいというお話だったと認識しています)。

git pull自体はfetch とmergeが必要なのでもう少し手間がかかります。個人的には以下のようにルール側での衝突を起こしてしまい、衝突の対処をユーザにさせようとする形になるのであまりよくないと思っていました

git pullを利用する場合だとユーザがルールの更新をしてしまっていた場合、衝突が起こってしまう可能性があります。もともとのニーズ(submodule指定をし忘れてしまい最新版のルールを取得するようにしたい)を満たすのであればgit cloneで十分かなと思っていましたがどうですか？更新を行うとしたらrulesフォルダが存在したらgit fetch + mergeを行うことになります(git pullに該当する関数がgit2になかったのでfetchとmergeをやって同様のことを行います)

また、proxy経由でのclone等は現状試せていない状態です。crate側に設定する関数があるので、場合によってはもう少し設定値を追加しないと対応できないかもしれません

[YamatoSecurity]

なるほど、説明不足ですみません。どちらかというと更新機能なので、git pull (実質はfetch + merge)がメインで、おまけに最初のダウンロードが楽になるようにgit cloneも対応できたら良いな〜と思っていました。なので、時間がある時にfetch+mergeの更新対応もお願いできまあすか？
proxy対応は任せます。あった方が良いのですが、実装が手間かかるのであれば、取り敢えず無くても良いと思います。

[hitenkoku]

承りました。とりあえずproxy対応はあとまわしとしておいて、git fetch + mergeの実装をしておきます

[hitenkoku]

git fetch + merge機能の作成が完了するまで一旦Draftします

[hitenkoku]

@itiB 以下のURLの件ですが、 #401 でsubmodule updateを活用した場合の方法を作ってみましたので、そちらの方で動作するかどうかご確認いただいてもよろしいでしょうか……？

• added update command #391 #392 (comment)
• added update command #391 #392 (review)

[itiB]

@hitenkoku なるほどーーー！！rulesディレクトリを削除したらupdateコマンドが通りました。
submoduleの方確認しますので少々お待ち下さい。

[YamatoSecurity]

@hitenkoku エラーメッセージの英語を少し修正したら、なぜかbuildできなくなりました。ごめんなさい！
確認して頂けますか？
また、動作確認が遅くなり、ごめんなさい！良い感じです。一つだけ気になるところがありました。
ユーザがファイルを編集したり、削除したりすると、ルールを更新しても、ファイルが更新されないようです。
(編集・削除されたままになります。）

[hitenkoku]

@YamatoSecurity 英語のご指摘をしていただき誠にありがとうございます。大変助かります。
buildができなくなった件について 45a5234 で対応完了しました cargo fmtを実施していないことが原因でした。

以下の件は少し難しいところです。強制的なチェックアウトをするとユーザが編集していたルールとかを破壊してしまう可能性があると思われます。それをどこまで許容するかですね……
個人的にはユーザが修正していたものが一発で上書きされたら怒るだろうなぁ……とも思っています。

ユーザがファイルを編集したり、削除したりすると、ルールを更新しても、ファイルが更新されないようです。
(編集・削除されたままになります。）

また、#392 での実装は通常のレポジトリに対して行っている形になるのでsubmoduleとかには動作をしてこない可能性が出てきています。

大変お手数ではございますが #401 でsubmodule対応版を作成させていただきましたのでそちらで確認いただいてもよろしいでしょうか(修正いただいた英語の内容は #401 側でも反映済みです)

[YamatoSecurity]

なるほど、では、取りあえず、ファイルを上書きしないようにしましょう。
ドキュメンテーションにルールを編集・削除したら、更新されないことを記載しておきましょう。

[hitenkoku]

#401 で機能面のところは対応できたので、ドキュメントに「rules側をuserで更新していた場合、conflictなどが起こった場合は失敗するので、その場合はruleフォルダを他のフォルダ名にrenameしてupdateコマンドを打てば最新版のルールがrulesフォルダに作成されます」という記載を追加したら、レビュー依頼を再度メンションで連絡します

[YamatoSecurity]

ルールが入っていない時に(スキャン時にルール数が0の場合）「No rules were loaded. Please download the latest rules with the --update option.」というエラーを出しますか？

[hitenkoku]

以下の件ですが、追加で対応します。

#392 (comment)

[hitenkoku]

@YamatoSecurity ドキュメントの修正とルールのロードが0件であった時のエラー出力対応が完了しましたのでご確認のほどよろしくお願いいたします。

[YamatoSecurity]

コンパイル時にこの警告が出ていますが、無くせますか？

[YamatoSecurity]

いつのタイミングで調子悪くなっているか分かりませんが、hayabusa-sample evtxをスキャンしたら、4688のイベントの%CommandLine%が半分正しく変換されますが、半分は%CommandLine%のまま出力してしまいます。
./target/release/hayabusa -d ../../hayabusa-sample-evtx -o sample.csv

この原因は何でしょう・・
イベンドID 4688だけなので、もしかして以前に発生したalias変換問題でイベントログのバージョンが違う(形式が違う）から？

(この件は別のissueにしましょうか？）

[hitenkoku]

@YamatoSecurity ご確認ありがとうございます。warnの削除については承りました(多分、ファイルリストとるための別issueの対応が紛れ込んでしまっていたようです。失礼いたしました。
以下の件は確かに状況がわかりませんね……。いったん別issueを切って管理します。

いつのタイミングで調子悪くなっているか分かりませんが、hayabusa-sample evtxをスキャンしたら、4688のイベントの%CommandLine%が半分正しく変換されますが、半分は%CommandLine%のまま出力してしまいます。 ./target/release/hayabusa -d ../../hayabusa-sample-evtx -o sample.csv

この原因は何でしょう・・ イベンドID 4688だけなので、もしかして以前に発生したalias変換問題でイベントログのバージョンが違う(形式が違う）から？

(この件は別のissueにしましょうか？）

[hitenkoku]

5457aea でunusedのwarningの対処は完了しました

[YamatoSecurity]

OKです。ありがとうございました！