Security – ページ 4 – k2-ornata（個人的「やってみたこと」ブログ）

セキュリティインシデント対応の自動化手順を検討してみた

最近、セキュリティ人材の不足やアラートの増加などの理由から、SOAR（Security Orchestration Automation Response）というカテゴリの製品が、少しずついろいろな会社に導入し始めているのではないかと思います。

しかし、いざSOARを使ってインシデント対応を自動化しようとしたときに、どこから手をつけはじめたらよいのかわからないといったお悩みを持つ方が、たくさんいらしゃるのではないでしょうか。

そんな中、今回いろいろなセキュリティや自動化に関するサイトも参考にしながら、既存のインシデント対応手順をどう自動化していけばいいか考察してみました。

以下、私の方で考えた自動化検討の手順になります。

１．インシデント対応を手順書化
２．インシデント対応をフローチャート化
３．定型的な判断・処理がないか洗い出し
４．SOARで連携可能なシステムを確認
５．自動化の優先度を検討

１．インシデント対応を手順書化

普段、実施しているインシデント対応手順を手順書に落としてみます。

そのときに対応の流れを記載するだけではなく、人が判断している部分や処理している部分をより具体的に書くとよいでしょう。

具体的に書けるということは、定型化できる可能性があるということになります。

２．インシデント対応をフローチャート化

手順書ができたら、次にそれをベースにフローチャートを書いてみましょう。

このときに、通常であれば、ある役割の人からある役割の人へと、人（もしくは部署）をベースとしてフローをつなげていくと思います。

人だけではなくシステムも考慮

しかし、自動化する場合には、人だけではなくシステム（メール、SIEM、インシデント管理、セキュリティ機器など）も含めてフローチャート化してあげるとよいでしょう。

こうすることにより、あるシステムから別のシステムに対して人が介在していることが明らかになり、そこが自動化検討のポイントになってきます。

ただし注意が必要なのは、人から人への流れであったとしても自動化できることがあるかもしれない、ということです。

例えば、SOAR製品によってはメールを人に送信し、そのメール内のリンクをクリックさせることでSOARが提供しているWebインターフェイスにアクセスさせ、その人から何らかのレスポンスを返信させる、といったことが可能な場合があるからです。

今できていないことも考慮

ここまでは今、実際にやっていることが対象となっていますが、追加で考えておくとよいことがあります。

今はいろいろな事情でてきていないけれども、可能であれば今後、やってみたいと思っていることです。

自動化によりインシデント対応のスピードアップが計れるようになります。しかし、そこで考えを止めておくのは少しもったいないかと思います。

スピードアップにより空いた時間を使い、これまでできなかったことを行える余裕が出てくる可能性がありますので、それらも自動化の検討対象に入れておくとベストだと思います。

３．定型的な判断・処理がないか洗い出し

以上により自動化検討のポイントが明らかになったら、次はそのポイントにおいて普段、定型的な判断や処理をおこなっていないか確認します。

つまりパターン化されていないかということです。もしパターンかされているのであれば自動化のロジックを作成できる可能性があります。

たとえば、あるシステムから取り込んだデータにおいて、その中のある項目の値によって決まった処理をおこなっていたり、追加調査などを行っていないか、などです。

こうして検討を進めていけば、以下のような処理以外はすべて自動化できる可能性が見出せるでしょう。

・どうしても人の経験値に頼って判断せざるを得ない部分
・関係者の総意が必要となる重要な意思決定
・ネットワークでは対処できない物理的な作業（被疑PCの利用者からの回収など）

４．SOARで連携可能なシステムを確認

SOARを導入済みの場合

もしすでに導入済のSOARがあるのであれば、それがフローチャートに書き出した各システムと連携できるかどうかを確認します。

もしSOARがそのシステムと連携できるのであれば、その部分は自動化候補となります。

また、直接連携可能となっていないシステムであっても、自動化できる可能性はあると思います。別途そのシステムと連携可能なプログラムを個別に作成し、それとSOARを連携させればよいのです。

しかしこのとき注意が必要なのは、個別開発したプログラムとSOARとの間でトラブルが発生しても、SOAR提供ベンダーによってサポートされない可能性があるということです。

この場合、自己責任で対応しなければなりません。それを避けたいのであれば、SOARがサポートしていないシステムとの連携は避けたほうがよいでしょう。

これからSOARを導入する場合

もしSOARをまだ導入していないのであれば、フローチャートに記載した連携対象の各システムを数多くサポートしている、もしくはどうしても優先的に連携させたいシステムをサポートしているSOARを、購入の検討対象にあげるとよいと思います。

なお、今後自動化の対象範囲を広範囲に広げる場合には、それにより新たに連携が必要となるシステムとも連携が可能か、検討に含めておくとよいでしょう。

５．自動化の優先度を検討

自動化できる部分をピックアップし、それが複数ある場合には、どこから先に手をつけるかを検討する必要があります。

この自動化の優先度決めについては、自動化により何を目指しているかによるでしょう。
自動化のメリットとしては、以下のものが考えられます。

・スピードアップ
・人手不足の解消
・対応品質の均一化

これらをキーワードに自動化可能なポイントに優先順位をつけて検討していくとよいでしょう。

以降、2022.5.4 追記

スピードアップ

例えばスピードアップを目指す場合、現在、その対応にどれくらいの時間がかかっているか、整理してみるとよいでしょう。

時間がかかっている処理を自動化するほうが、ROI（Return On Investment）は高いですよね。

人手不足の解消

人手不足の解消ということであれば、頻繁に発生している処理を自動化するほうがROIは高いですね。

対応品質の均一化

これは自動化というよりその一歩手前のインシデント対応の手順書化によるメリットなのではないかと思います。
したがって、自動化という意味であれば、優先順位は低いかもしれませんね。

参考サイト

・セキュリティ運用④－「セキュリティ運用自動化」を実現するSOAR 導入の3つのステップ（MACNICA）
https://www.macnica.co.jp/business/security/manufacturers/fireeye/feature_07.html?utm_source=pocket_mylist

・インシデント対応の切り札「SOAR」とは何か？自動化とセキュリティ人材育成の強い武器に（NEC）
https://www.nec-solutioninnovators.co.jp/ss/insider/column17.html?utm_source=pocket_mylist

・「情報セキュリティ事故対応ガイドブック」の公開（情報セキュリティ大学院大学）
http://lab.iisec.ac.jp/~hiromatsu_lab/sub07.html

・「SOAR」は魔法の自動化ツールなのか！？～失敗しないセキュリティ運用自動化への道～（MACNICA）
https://mnb.macnica.co.jp/2021/03/soar.html?utm_source=pocket_mylist

ヘッダーfromをなりすましたメールを検知する方法を調べてみた

最近、Emotetが復活し、いろいろな企業から感染報告が上がっているなーと思い、こういったなりすましメールを簡単に検知できる方法がないのか少し調べてみました。

とりあえず思いついたのは、ヘッダーfromは簡単に書き換えられてしまうということなので、偽装が難しいエンベローブfromと突き合わせればいいんじゃないか、ということでした。

エンベローブfromとヘッダーfromの違い

エンベローブfromとヘッダーfromの違いについては以下のサイトで詳しく説明されていますが、簡単に言うと、

・エンベローブfrom・・・郵便物の封筒に書かれている差出人名
・ヘッダーfrom・・・封筒の中にある便箋にかかれている差出人名

となるようです。

＜参考サイト＞
「エンベロープFrom」と「ヘッダFrom」の違いとは？（ベアメール）
https://baremail.jp/blog/2021/05/25/1377/?utm_source=pocket_mylist

受信メールからエンベローブfromが確認できるのか

違いがわかったところで次に疑問におもったのが、エンベローブfromって受信メールのどこに書いてあるのかということです。

この点についても上記のベアメールのサイトに書かれていますが、エンベローブについては、残念ながら最後のメールサーバで削除されてしまうようです。
（最後のメールサーバがわざわざ封筒から便箋を取り出してくれるみたいですね。）

ただし、この時にメールサーバでエンベローブfromの値をヘッダのReturn-Path:に転記してくれるようですので、結論としては、受信メールを見るだけで確認できるようです。

Emotetのなりすましは検知がむずかしい

なんだ、じゃあなりすましメールの代表格であるEmotetのメールも簡単に見つけられるんじゃないの？と思いましたが

このEmotet自体は、

・感染した企業のメールサーバを使って社外にメールをばらまく
・フリーメールアドレスから送信する場合、ヘッダーfromのなりすましはしない

といった方式をとっているので、エンベローブfromとヘッダーfromを突き合わせても意味がない（なりすましメールかどうか判断できない）ようです。

Emotetがこのような方式をとっている理由としては、最近、企業にDMARKというなりすましメールを検知する方法が普及してきたからではないかと思われます。

DMARKはSPFやDKIMの結果によりメールの処理を変えるだけではない

いままで私は、DMARKの機能について、

・SPFやDKIMのチェック結果によってメールのフィルタリングを変える
・正しい送信元にレポートを送る

といったような管理機能だけが備わっていると考えていました。

しかしながら、よくよく調べてみると上記以外にも、ヘッダーfromの詐称がおこなわれていないか確認する機能があるようです。
具体的には、

・SPFと連携する場合には、エンベローブfromとの突き合わせ
・DKIMと連携する場合には、Dkim-Signatureのdタグとの突き合わせ

をするらしいです。（DKIMの方はちょっと私には難解です。。。）

このあたりの詳しい話は以下のサイトにに書かれていますので、興味がある方は読んでみるといいと思います。

＜参考サイト＞
大きく遅れる日本のなりすましメール対策：DMARC（ProofPoint）
https://www.proofpoint.com/jp/blog/email-and-cloud-threats/Japan-lags-far-behind-in-fighting-spoofed-emails-DMARC?utm_source=pocket_mylist

メールにおけるDKIMの仕組み（Carpe Diem）
https://christina04.hatenablog.com/entry/domain-keys-identified-mail

結論

メールヘッダーfromのなりすまし対策としてDMARKを利用すれば検知できるものの、残念ながらEmotet対策としての有効打にはならないようです。

今のところ、受け取ったメールの件名や本文や見てあやしいなあと感じたら、

・メーラーに表示されているヘッダーfromを確認する
・添付ファイルは開かない
・埋め込まれているリンクはクリックしない

を徹底するしかないかなさそうですね。

なお、Emotetメールの特徴は以下のサイトに書かれていますので、一度確認しておくことをお勧めします。

＜参考サイト＞
「Emotet（エモテット）」と呼ばれるウイルスへの感染を狙うメールについて（IPA）
https://www.ipa.go.jp/security/announce/20191202.html#L18

Snort3をMacにインストールしてみた

自分のPCとインターネットの間の通信をモニタリングする為にログを取得してみたいと思い、久しぶりにSnortを触ってみたので、その時の操作を記録しておきます。

もうかなり前のSnort 1のころに触ったきりで、ひさりぶりにSnortを調べてみたところバージョンが3になっており、ルールの設定などもかなり変わっているようでしたので少々てこづりました。

１．Snort3のインストール

インストールはかなり大変な作業になるのではないかなあと思っていたのですが、macappstore.orgというサイトにMacへのsnortのインストール方法が超簡単に書いてあり、その通りにやってみたところ、本当にそれだけで入ってしまいました。

具体的には以下の２つのコマンドをMacのターミナルからたたいただけです。

まず１つ目のコマンド

ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)" 2> /dev/null

そして２つ目はこちら

brew install snort

ちゃんとインストールされたか確認する為、以下のコマンドでsnortのバージョンを確認します。

snort --version

以下のような形でコンソールにバージョンが表示されたら、インストールは成功です。

,,_ -> Snort++ <-
o" )~ Version 3.1.14.0
'''' By Martin Roesch & The Snort Team
http://snort.org/contact#team
・・・

この状態で以下のコマンドを実行すれば、ネットワークトラフィックのダンプがコンソールに出力されると思います。

snort -i en1 -L dump

ちなみに、Macの無線LANのデバイス名は”en1″になるようです。

２．Snort3の設定

とりあえずIDSとして動かす為に準備が必要なファイルは、「snort.lua」と「local.rules」の２つです。

2.1 snort.luaファイルの修正

snort.luaはSnort2まででいうsnort.confに相当するようで、サフィックスがconfからluaに変わっております。
このファイルは/usr/local/etc/snortのディレクトリ配下にありますので、以下のコマンドで編集します。

vi /usr/local/etc/snort/snort.lua

ファイルを開くといろいろと書かれていますが、HOME_NETの変数だけ以下のように修正すれば大丈夫です。
なお、192.168.0.0/24はサンプルなので、自分の環境に合わせて変更する必要があります。

HOME_NET = '192.168.0.0/24'

2.2 local.rulesファイルの作成

そして次にlocal.rulesファイルを新規に作成します。

私はsnort.luaファイルと同じディレクトリ（/usr/local/etc/snort）に以下のコマンドで作成しました。

vi /usr/local/etc/snort/local.rules

なお、local.rulesへの記述はとりあえずテストなので以下の１行だけでも大丈夫です。

alert icmp any any -> $HOME_NET any (msg:"ICMP connection test"; sid:1000001; rev:1;)

これで設定作業は完了です。

ちなみに設定ファイルの記述が正しいかどうか以下のコマンドでチェックすることが可能です。

sudo snort -c /usr/local/etc/snort/snort.lua -R /usr/local/etc/snort/local.rules

３．Snort3をIDSとして動かす

正直、-Aと-s, -k の３つのオプションの意味はちゃんと調べてませんが、以下のコマンドで「２．Snort3の設定」で編集・作成したsnort.lua（-cオプション）とlocal.rules（-Rオプション）ファイルを読み込めば、SnortがIDSとして起動します。

snort -c /usr/local/etc/snort/snort.lua -R /usr/local/etc/snort/local.rules -i en1 -A alert_fast -s 65535 -k none

なお、ネットワークインターフェイスとして、-iオプションでen1を指定しています。

試しに他のPCからMac（Snortを入れたPC）に向けてpingを打ったところ、無事に以下のログがコンソールに表示されました。

10/24-10:05:57.123629 [] [1:1000001:1] "ICMP connection test" [] [Priority: 0] {ICMP} 192.168.0.*** -> 192.168.0.**
10/24-10:05:57.123661 [] [1:1000001:1] "ICMP connection test" [] [Priority: 0] {ICMP} 192.168.0.*** -> 192.168.0.***
・・・

４．ログをファイルに出力する（無理やり）

あとはこのログを-lオプションを使ってファイルに吐き出すだけ、、、と思ったのですが、いまのところそれではうまく言っていません。（なぜだろう。。。）

4.1 ログディレクトリの作成

まずは、ログを出力するディレクトリを作成します。

インストールしてもログディレクトリは無いはずなのでmkdirで以下のように作成しておきます。

cd /var/log
mkdir snort

なお、作成した/var/log/snort のパーミッションには注意が必要です。Snortからログが書き込めるようにパーミッションは与えておいてください。

4.2 ログの出力

冒頭で書いたとおり、いまのことろ-lオプションでの出力がうまくいっていません。

そこでとりあえず以下の通り、リダイレクト”>”をつかってファイルに無理やり吐き出しています。

 snort -c /usr/local/etc/snort/snort.lua -R /usr/local/etc/snort/local.rules -i en1 -A alert_fast -s 65535 -k none -q > /var/log/snort/test01.log

なお補足ですが、リダイレクトで普通に吐き出すとSnort起動時や終了時のメッセージまで出力されてしますので-qオプションを利用して不要のメッセージは出力されないようにしています。

上記のコマンドの後、再度、他のPCからpingを投げてみて、/var/log/snort/test01.logにログが書き込まれて入れば成功です！

５．参考情報

Snort3を動かすまでにかなりてこずりましたが、参考にしたのは主に以下のサイトになります。

■Install snort on Mac OSX
macappstore.org/snort/?utm_source=pocket_mylist

■faceitnet.
faceitnet.blogspot.com/2016/11/snotr-intrusion-detection-system.html

■snort3
www.snort.org/snort3

Autoruns v14.0でVirusTotal連携機能を確認してみた

最近、Windowsのスタートアッププログラムをチェックするツール Autoruns の最新版が公開されたというニュースが流れていたので使ってみました。

私は知らなかったのですが、v13.0からVirusTotal連携機能というものが実装されており、Autoruns でピックアップされたプログラムのリストから、右クリックで簡単にVirusTotalでマルウェアではないかどうかのチェックができるようです。

Autorunsはインストール不要

マイクロソフトのページからAutorunsのZipファイルをダウンロードします。

ダウンロードしたZipファイルを解凍すると以下の５つのファイルが展開されます。

このようにインストーラは無く、exe ファイルが含まれているだけなので、これを実行するだけで Autoruns のGUIが起動します。

64bitマシン用としては、Autoruns64 と 64a の２つのexeがありましたが、aはAMD用かなと思い、Autoruns64を実行したところ、ライセンス同意書が表示された後、無事に起動しました。

VirusTotalと連携

それでは、AutorunsをVirusTotalと連携させてみます。

上部の[options]から[Scan Options]を選択します。

以下のポップアップが表示されますので、[Check VirusTotal.com]とその下の[Submit Unknown Images]にチェックを入れ、[Rescan]を押します。

ただ、これだけだと何も起きませんでした。

そこで、プログラムを右クリックし[Check VirusTotal]を選択してみました。

すると、下図の赤枠の通り、VirusTotalの実行結果が [0/75] と表示されました。

なお、[0/75]のところをクリックすると、VirusTotalのサイトがブラウザで表示され、詳細な結果を確認することが可能です。

このツールを使ってみると、予想外にスタートアップで起動しているプログラムが多いことがわかりますので、一度、使ってみるといいと思います。

<br />

IE 11のTLS 1.0, 1.1をバッチで無効化してみた

最近、TLS 1.2の利用が推奨されてきていることで、Windows 10 のIE 11 の詳細設定でTLS 1.0, 1.1を無効化してみたのですが、IEを再起動する度に設定が元に戻る現象が発生しています。

その度に毎回、IEの詳細設定を開くのも面倒なので、バッチにより直接レジストリを変更する方法を確認してみました。

reg addコマンドでレジストリを直接編集

実際にコマンドプロンプトから入力したコマンドは以下の通りです。

reg add “HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings” /v SecureProtocols /t REG_DWORD /d “0x0800”

ここでは、以下の３つの情報を設定しています。

レジストリの場所：HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings
レジストリの名前：SecureProtocols
レジストリの種類：REG_DWORD
レジストリの値　：0x0800

また、設定した値が正しく反映されているかは、以下のコマンドで確認できます。

reg query “HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings” /v SecureProtocols

実際にコマンドプロンプトで実行した結果は以下の通りです。

その後、実際にIE の[インターネットオプション]から[詳細設定]を見てみましたが、以下の通り正しく反映されているようでした。

Windowsのセキュリティチェックに使えそうなコマンドについて

セキュリティ関係のお仕事をしているにもかかわらず、Windowsを使い始めてあまりコマンドラインを使わなくなってきている為、これではまずいと思い、いろいろ調べてみようと思っています。

なぜなら、外部から攻撃してくるハッカー（クラッカー）は通常、コマンドラインをつかって情報収集した上で攻撃を仕掛けてくるので、その知識を吸収し防御に生かしていければと考えています。

WMIC コマンドでいろいろな情報を取集する

そもそもwmicとは何かということですが、最近のWindowsには「Windows Management Instrumentation」というWindows管理（計測）機能が実装されていて、それを操作するコマンドがwmicコマンドらしいです。（たぶん）

このコマンドはWindows Homeでも実装されていて、インストールした直後から利用することができます。以下はその一例です。

１．wmic qfe で適用済みのパッチ情報を入手

wmic コマンドに qfe をつけるとWindowsに適用されているパッチの一覧が表示されます。
ちなみに、qfeは、Quick Fix Engineeringの略らしいです。

以下は、適用済みパッチに関するCaption,Description,HotFixID,InstalledOn情報を表示した結果です。

wmic qfe get Caption,Description,HotfixID,InstalledOn の実行ｒ

【コメント】
重要なパッチが適用されていない場合は、攻撃対象となりますので早急な適用が必要です。

ちなみに、systeminfo コマンドでも適用済みのパッチを確認できますが、wmic の方がこまかく情報がとれそうです。

２．wmic useraccount でユーザアカウントを確認

こちらはwmic useraccount でWindowsに登録されているアカウントと有効状態を確認した結果です。

wmic useraccount get caption,domain,disabled の実行例

【コメント】
不要なユーザは無効にしておくことをお勧めします。これらのアカウントを利用して攻撃される可能性があります。また、攻撃された結果、身に覚えのないアカウントが作成されている可能性もあります。

ちなみに、net userコマンドでもユーザアカウントの情報は取れますが、やはりwmicの方が情報を細かくとれそうです。

とりあえず現時点では気になったwmicコマンドのみ調べてみましたが、今後いろいろ追加していきたいと考えています。

EmoCheck を使って、PCがEmotetに感染していないか念のため調べてみた

Emotet の情報を調べていたところ、今更ながらEmoCheckというEmotetにPCが感染していないか調べるツールがあることを発見したので、自分のPCで実際に動かしてみました。

GitHubからダウンロードしてダブルクリックするだけ

上記の通り、EmoCheckを使えば、GitHubからツールをダウンロードして、マウスでダブルクリックするだけで、PCがEmotetに感染していないか確認できます。

GitHub – JPCERTCC /EmoCheck
https://github.com/JPCERTCC/EmoCheck/releases

１．GitHubからexeをダウンロード

GitHubに以下のとおり32bit OS用（x86）と64bit OS用（x64）のexeが置かれていますので、自分のPCの環境に合わせてダウンロードします。
利用しているOSがWindows 10なら、たぶんx64の方でよいでしょう。

２．Exeを実行

そして、1.でダウンロードしたexeをダブルクリックします。

私はここで、ファイルの展開、もしくはインストーラの実行が行われるものだとおもいましたが、いきなり以下のようにチェックが始まります。
しかも数秒で完了です。おそらく特定のファイルやレジストリだけチェックしているものと思われます。

３．念のため、出力ファイルを確認

２．の最後の画面のとおり、EmoCheckを実行すると、同じフォルダに結果が出力されますので、それを確認します。

結果のファイルは、「PCのホスト名＋実行日時」のファイル名で出力されていますので、それを開いて念のため、中身を確認します。

今回は自分のPCにEmoCheckをダウンロードして実行しましたが、企業であればファイルサーバに置いておいて、それを実行するバッチを配布＆実行するようにしておけば、各PCの実行結果がすべて同じフォルダに保存されるので、便利かもしれませんね。

ウィルスバスター for Mac がアップデートされました

先週、Macをいじっていたところ、今年春ごろから利用しているTrendMicroウィルスバスターから以下のようなポップアップメッセージが出たので、アップデートしてみました。

このアップデートによりWebのセキュリティ機能が強化されていたのでご紹介しておきます。

Googleで検索されたサイトの安全性が表示されるようになった

FireFoxやChromeのアドオンとして、Trendツールバーが使えるようになりました。

これをONにすることで、Googleで検索された各サイトの安全性が自動的に色で表示されるようになります。

これはなかなか安心かもと思いましたが、何ということでしょう！このサイトが未評価となっており、グレーで塗られています。

これは営業妨害だ〜ということで、上の画面からトレンドマイクロに評価をお願いしていますが、いまのところ変わる気配はありません。

ちなみに上の画面から「トレンドマイクロに依頼します」というリンクをクリックすると以下のような画面が表示さて、任意のサイトの安全性を調べることができます。

SNSのプライバシーチェック機能も（できるようになる？）

Googleの検索検索結果の安全性以外にも、FacebookやTwitterなどのSNSサイトのプライバシーチェックもできるようになるようです。

いまのところ残念ながらFacebookとTwtterについてはサイトの最新仕様に対応中とのことで動作しないようですが、どんなチェックをしてくれるのか楽しみです

さいきんトレンドマイクロは頑張っているようですので、このままいい製品を作り続けてほしいですね。

Splunk社が提供するBOTS環境でSPL言語を勉強する

先日、Splunk FreeをMacOSにインストールした後、Splunk 社が提供しているBOTS（Boss of the SOC）用のデータとQ&Aをダウンロードして、SPL（Search Processing Language) 言語の勉強中です。

SPL 言語が書けるようになれば、Splunk に取り込んだログデータを簡単に検索、分析できるようになり、また日本においても多くの企業でSpunkを導入している為、勉強しておいて損はないかと思います。

なお、以下サイトにSPL言語の入門書/説明書が置かれていますので、参考になるかと思います。

https://www.splunk.com/ja_jp/goto/book

ちなみに今年の3月にその最新版であるv3がリリースされたようですね。

https://www.splunk.com/en_us/blog/security/botsv3-dataset-released.html

また、私がAWS環境にSplunkをインストールした時の記事を以下に載せていますので興味があれば見てみてください。

http://k2-ornata.com/splunk-install-on-aws/

BOTSv1をトライしたときに利用したSPL言語

まだSPL言語初心者ではありますが、BOTv1を通じて勉強したことを記載しておきたいと思います。

０．Splunk内のインデックスを確認

さっそくSPL言語を利用してみたいところですが、SPL言語を使う際に、indexを指定することが多々あります。

そこで、どんなインデックスがSplunkの中にあるのか確認する方法を記載しておきます。

いろいろ方法はありそうですが、まずはOSのコマンドで確認する方法を記載しておきます。

Splunk がインストールされているディレクトリ（Macの場合、通常、/Applications/Splunk ディレクトリにインストールされています）の配下のbinディレクトリに移動し、splunk list index とコマンドを入力します。

% /Applications/Splunk/bin
% ./splunk list index

すると、以下のようにインデックスの一覧が表示されます。

１．インデックスに取り込まれているデータの一覧表示

以下のように最初にパイプを書いた後、metadataコマンドを以下のようにつかうことで、botsv1インデックスに含まれるhostsの一覧と概要が表示されます。

| metadata type=hosts index=botsv1

また、hostsの代わりに sourcesや sourcetypes を指定することもできます。

| metadata type=sources index=botsv1

２．時間を整型する

上の例だと、各時間（*Time）がなにやら数字の羅列になっているので、これをわかりやすい表記にすることが可能です。

| metadata type=sourcetypes index=botsv1
| foreach *Time [eval <>=strftime(<>,”%d/%b/%y %H:%m:%S”)]

とりあえずSPL言語の出だしだけ書いてみましたが、また気が向いたら、続きを書いてみたいと思います。

VulnHubをMacOSで動かそうとしたら、/dev/vmmon を開けないというエラーが出た

諸事情によりVulnHub（脆弱性が残された仮想イメージ）を自分のMacOSにインストールしてみたくなったので、トライしてみました。
その時に、VMware Fusion 11.5で仮想イメージを起動しようとしましたが、「/dev/vmmon を開くことができませんでした：パイプが壊れています。」というエラーが発生したので、そこの対処方法も含めて記載しておきます。