ごちゃごちゃしたIT勉強記録

自分用メモ。主にセキュリティで、その他色々書きたい。

T-Pot観測記録:2018/5/11〜5/17 vnc、またきたかおまいらw

最近、再びraspberry piarduinoを触り始めてはまってしまったのでちょっと遅れてしまいましたが、先週の分の記録をつけていきたいと思います。

...といいたいところなのですが、tpotにアクセスしたところ以下のような画面ががが。。

f:id:motojiroxx:20180521215929p:plain

 「なんでじゃー」ということで、Status Breakdownの部分を見てみると、elasticsearchの部分で"Elasticsearch is still initializing the kibana index"となっており、これが問題と思われる。

とりあえずこれをググってみる。....よくわからんがcurlをつかってREST APIクラスタヘルスをチェックできるらしい。が、みてもよくわからん!

ということで、私が参考にしているTKさんのブログに同じ現象の解決方法がありましたので、この手法を使ったところ無事復活しました(TKさん本当にありがたや)。

参考にした記事は以下の通りです。

tk-secu.hateblo.jp

 

色々ありましたが、はじめていきます。

 

全体の結果

f:id:motojiroxx:20180522022255p:plain

 

f:id:motojiroxx:20180522022807p:plain

 

私のところのハニーポットには、ずっとvncさんが定期的にきているという状況ですね。しかも、相変わらずロシアからです。ただ、ここまで時間が固定的だと自動化している可能性もありそう?

 

また、前回の記事で書いた内容に関連することですが、警察庁からRedisを標的とした探索行為の増加がみられる報告がありました。

www.npa.go.jp

4月ぐらいから急激に増えて、そのまま継続しているという状況でしょうか。

私のところでは先週はきていましたが、今週はきていないようでした。

 

ちょっと他も見てはみたものの面白いネタがないですw

 

ちょっと気になったこと

あと、私のところのSuricata CVEでは、今までCVE-20170143しか見たことないのですが、TKさんのところだと色々きていて羨ましい。

みなさんSuricataのチューニングとかやっているのでしょうか?

 

やってみたい!

これまたTKさんの記事にあるものですが、DionaeaとVTの連携は非常にやりたい!毎回コマンドうって確認するの疲れました。

なので、近々やろうと思います。

T-Pot観測記録:2018/5/4〜5/10

ちょっと遅れてしまいましたが、今週分の観測記録をつけようと思います。

全体の結果

f:id:motojiroxx:20180513030800p:plain
f:id:motojiroxx:20180513030812p:plain

先週まではvnclowpotに対するものが多かったのですが、この週は非常に変動がありました。継続してvnclowpotのイベントは多いのですが、それ以外のCowrie, Honeytrapのイベントが非常に多くなっています。なので、今回はこの3つを中心にイベントをみていきます。

vnclowpotのイベント

vnclowpotに対するものは依然としてある程間隔的にイベントが発生しています。ただ、その時間が少し変わっています。
 ・先週:毎日15:00近辺でスパイクしていた
 ・今回の週:6:00, 9:00などでスパイクしていることが多くなっている
攻撃元のIPは前回と変わらずロシアが大半を占めています。また、発信元はロシアのモスクワが圧倒的です。

ロシア(モスクワ)との時差は6時間(モスクワより日本の方が進んでいる)となるため、今回の週の時間をモスクワの時間で考えると
・今回の週(モスクワ時間):0:00, 3:00
となります。夜中にかけて攻撃を実施しているということなのでしょうか?たしかに、夜中にかけて攻撃した方が、日本の企業の人にとっては気づきにくい+対処しにくいでしょうね。

Honeytrapのイベント

こちらもロシアがほとんどです。すごいですね、ロシア。。
送信先ポートは以下の通り
 dest port : 6379, 2222, 2323, 5902, 3307

5902はvncらしいですね。というのも、vncではポート番号が基本的に「5900+ディスプレイ番号」になるとのこと。つまり、5902では2番のディスプレイ番号を使用していることを表します。
また、6379はRedisと呼ばれるインメモリ型のNoSQLデータベース(キー・バリュー型)らしいです。この、「インメモリ型のDB」という話ですが、最近話題になったmemcachedも同じようなものらしいです。分類としてもRedisと同じような分類(インメモリ型NoSQL(キー・バリュー型))らしいです。ここら辺の詳しい話はちょっとわかりませんが。。

Cowrieのイベント

こちらについては、この週において非常に多く発生するようになりました。
 ・攻撃元:メキシコ、ベトナムアメリカ、ブラジルの順で多い(中国やロシアは少なかったです。
 ・ポート:2222(ssh), 2223(telnet)がほとんど。443と80はかなり少ない。
また、メキシコからの攻撃ではtelnetに対するものが多く、ベトナムからはsshという感じです。アメリカに関しては半々という結果でした。

では、Cowrieで使用されたアカウントとパスワードをみていきます。

アカウント名
f:id:motojiroxx:20180513052703p:plain
パスワード
f:id:motojiroxx:20180513052719p:plain

アカウント名は、前回の記事でも出たものがちらほらと見えます。新しいものであれば、以下のものでしょうか。

 e8ehome, telecomadmin,

両方とも、Miraiに似たネットワークスキャンで使用されるものっぽいですね。以下参考記事。
blog.trendmicro.co.jp

パスワードについても、上記の記事に書いているものが多いですね。
強いていうなら以下のものがちょっと特徴的でしょうか。

 nE7jA%5m

ただ、これも調べてみたら中国製のルータのデフォルトパスワードっぽいですね。

このようにみて見ると、デフォルトパスワードがいかに危険か実感できますね。なので、デフォルトパスワードは使用しないように気をつけなければ。


今はこんな感じで記録をつけていますが、他のハニーポッターの方はどんな風に(使っているツールとか)ログ解析しているのかは非常に気になりますね。

30日OS自作入門-1〜2日目-

前回までで環境構築を終わらせましたので、早速作業に入りたいと思います。

今回やっていく内容

  • 1日目の部分
  • 2日目の部分

1日目部分

やったことは以下の通り

  • おもむろにバイナリエディタを起動し、hexを写経(鬼w
  • テキストエディタを起動し、DB命令を使ってhexを記述(18万4314行の¥x00を打ち込む必要がある。これも鬼w)
  • アセンブリ命令を少しづつ加えながら、hex自体で書く量を減らしていく

主にhexを写経していくような作業。結構しんどいけど、「0x〜」を打鍵するスピードが上がった気がします

命令

DB(data byte)

  • ファイルに1byteのデータを直接書く命令
  • DB命令のオペランドはカンマで区切ると複数指定可能?(本では8バイト分)
  • ファイルに書くデータの大きさによって以下のような命令がある
    • DW(data word) : 2byteのデータを書き込む
    • DD(data double-word) : 4byteのデータを書き込む
  • DB命令については、オペランドに文字列を指定可能

   
RESB(reserve byte)

  • 指定したバイト数だけ0x00を書き込む

んで、RESBに関連する部分で$マークを使い余り部分を0書きするという部分がありました。

RESB  0x1fe - $

ここでの$は「先頭行から何バイト目か」を教えてくれる変数として機能します。なので、例として$マークの部分が先頭から0x1f0行目だったとしましょう。そうすると、

0x1fe - 0x1f0 = 0x00e

となるため、RESB命令部分は

RESB  0x00e

となり、ファイル内のアドレス0x1f0から14byte分0を書き込みます。

。。。という感じなのですが、私の環境(linux+nasm)では$のままだとアセンブルできないので(エラーが出る)、linux+nasmでやっている方であればこの部分のコードを以下のように変更します。

RESB  0x1fe - ($-$$)

これについては、以下の記事を参考にしました。
tsurugidake.hatenablog.jp

この2つの命令を使ってnasファイルにコードを打ち込みアセンブルしてimgファイルを作成し、それをqemuで実行します。


アセンブル

nasm helloos1.nas -o helloos1.img

qemuでの実行

qemu-system-i386 helloos1.img

そうすると、こんな感じで画面が出てきます。
f:id:motojiroxx:20180509030602p:plain
実際に起動して、ちゃんとhello worldの文字が見えるとやはり感動しますね。

まぁ、1日目については主に今後の作業の流れを掴むような作業でしょうか。

2日目部分

  • アセンブリ命令をじゃんじゃん使って、1日目にhexで書いた部分をアセンブリコードで書き直す
  • CPU内に存在する記憶領域であるレジスタや、CPUからみると外部記憶装置であるメモリに関するお話

2日目から少しずつアセンブリ命令とレジスタなどを使って処理を書いていきます。

命令

ORG(origin)

  • 記述した機械語をメモリ上のどのアドレスに読み込ませるか指定する命令
  • ORG命令を使ってメモリ上のアドレスを指定した場合、$マークの意味も「読み込まれるメモリ上のアドレス」になる(nasmを使う場合は注意)
  • コードの先頭部分でまずは以下のように指定を行う
ORG  0x7c00


INT(interrupt)

  • ソフトウェア割り込み命令(詳細は後日)


HLT(halt)

  • CPUを待機状態にする命令
  • 外部で変化があればCPUがプログラムの続きを実行

(節電したいのであれば、使うべき?)

レジスタ関連

レジスタについては、今の所16bitのものが出てきますが、そのうちAX, BX, CX, DXについてはそれぞれ8bitレジスタとしても使える(AXはAHとALとして指定することも可能)というところは覚えておく必要あり(あとで出てくるので)。

バイトオーダー

MOVなどの転送命令でメモリ上にデータを格納する場合には、データの下位バイトからメモリに格納される点に注意。このような、メモリ上にデータを格納する方式のことをバイトオーダーと言い、こん秋のようにデータの下位バイト(桁のくらいが小さい方)からメモリ上に格納していく方式をリトルエンディアン。
(ビッグエンディアンはデータの上位バイトから格納していく方式。直感的にはこっちの方がわかりやすいかも)

エラー、警告関連

記述したアセンブリコード(nasファイル)をnasmでアセンブルするたびに以下の警告が吐かれていました。

warning : uninitialized space declared in .text section: zeroing

ひとまず警告は出ていたとしてもimgは起動できたので置いておいたのですが、気になったので解決法を調べてみたところ、同じような環境でやっている方がブログに書いておりました。有難や。
d.hatena.ne.jp
tsurugidake.hatenablog.jp

基本的にはRESB命令をTIMES命令に書き換えて、格納する値を定義してやるという感じですね

TIMES  <繰り返す回数>  DB(データの大きさ)  値

書き換えることによって、上記の警告は出なくなりました。

30日OS自作入門-3日目(C言語導入前まで)-

最大の鬼門と言われる3日目に突入しました。ただ、今回はC言語導入前までのまとめをしたいとおもいます。

今回のまとめ

主に3日目の内容についてまとめていきます。3日目は主に割り込み命令を使って以下の処理を実現する内容です。
・ディスクからの読み込み
・ビデオモード設定(画面モードの切り替え)

アセンブリコードとimgファイルの中身

3日目のはじめのソースコードを、実際にアセンブリ命令を書いてimgファイルを作りqemuで起動しました。
書いたアセンブリ命令とマシンコードの対応関係については、以下のコマンドで生成されるlstファイルを見ると確認できます。

nasm  ipl.nas -l ipl.lst -o ipl.img

上記のコマンドでは、lstファイルの生成とimgファイルの生成を同時にやります。
lstファイルは以下のようになっています。

     1                                  ; haribote-ipl
     2                                  ; TAB=4
     3                                  
     4                                  	ORG		0x7c00
     5                                  
     6 00000000 EB4E                    	JMP		entry
     7 00000002 90                      	DB		0x90
     8 00000003 48415249424F5445        	DB		"HARIBOTE"
     9 0000000B 0002                    	DW		512
    10 0000000D 01                      	DB		1
    11 0000000E 0100                    	DW		1
    12 00000010 02                      	DB		2
    13 00000011 E000                    	DW		224
    14 00000013 400B                    	DW		2880
    15 00000015 F0                      	DB		0xf0
    16 00000016 0900                    	DW		9
    17 00000018 1200                    	DW		18
    18 0000001A 0200                    	DW		2
    19 0000001C 00000000                	DD		0
    20 00000020 400B0000                	DD		2880
    21 00000024 000029                  	DB		0,0,0x29
    22 00000027 FFFFFFFF                	DD		0xffffffff
    23 0000002B 48415249424F54454F-     	DB		"HARIBOTEOS "
    24 00000034 5320               
    25 00000036 4641543132202020        	DB		"FAT12   "
    26 0000003E 00<rept>                	TIMES	18	DB	0x00
    27                                  
    28                                  ; main program
    29                                  
    30                                  entry:
    31 00000050 B80000                  	MOV		AX,0
    32 00000053 8ED0                    	MOV		SS,AX
    33 00000055 BC007C                  	MOV		SP,0x7c00
    34 00000058 8ED8                    	MOV		DS,AX
    35                                  
    36                                  ; reading disk
    37 0000005A B82008                  	MOV		AX,0x0820
    38 0000005D 8EC0                    	MOV		ES,AX
 以下省略

一番左から順に「nasファイル内での行番号」「ファイル上でのアドレス」「マシンコード」「アセンブリ命令」という順になっています。

そして、先ほどのnasmコマンドで生成したimgファイルの中身をhexで表示してみます。imgファイルの中身をhexで表示する際は、以下のコマンドを使用。

xxd ipl.img | more

表示されたファイルの中身はこちら

00000000: eb4e 9048 4152 4942 4f54 4500 0201 0100  .N.HARIBOTE.....
00000010: 02e0 0040 0bf0 0900 1200 0200 0000 0000  ...@............
00000020: 400b 0000 0000 29ff ffff ff48 4152 4942  @.....)....HARIB
00000030: 4f54 454f 5320 4641 5431 3220 2020 0000  OTEOS FAT12   ..
00000040: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000050: b800 008e d0bc 007c 8ed8 b820 088e c0b5  .......|... ....
00000060: 00b6 00b1 02b4 02b0 01bb 0000 b200 cd13  ................
00000070: 7203 f4eb fdbe 8a7c 8a04 83c6 013c 0074  r......|.....<.t
00000080: f1b4 0ebb 0f00 cd10 ebee 0a0a 6e6f 2064  ............no d
00000090: 7269 6e6b 2c20 6e6f 206c 6966 6521 0a00  rink, no life!..
以下省略

先ほど示したlstファイルの「マシンコード」とimgファイルのhexを先頭から比較すると、対応していることがわかるかと思います。

毎回ではありませんが、たまにこういった確認をすると、自分で書いたコードがどのようイメージファイルになっているのかが確認できるのでいいかもしれません。

割り込み命令

今回出てくる割り込み命令では、「指定したディスクの場所を読み込む処理」と「ビデオモード設定」について。

ディスクの読み込み

  • ディスクアクセスの方式はCHS*1
    • Cylinder, Head, Sectorの頭文字
    • シリンダ番号、ヘッド、セクタを特定のレジスタに格納しディスク上のデータの読み込み開始位置を指定*2
  • 読み込む対象のドライブ番号を指定(FDDが1つしかない場合には0x00でおk)
  • int 0x13で実行(戻り値はCF(キャリーフラグ)にセットされる。CF=1の場合、エラーが発生しており、AHにエラーコードが格納)

詳細については、以下のサイトを参照。
http://oswiki.osask.jp/?%28AT%29BIOS


もし、ディスクアクセスに関連したエラー処理をする場合には、

int  0x13

命令のあとに以下のような処理を追加すればいいのでしょう。

  1. CFにフラグが立っているかどうかを判断する
  2. フラグが立っている場合には、AHに記載されているエラーコードをみて、エラーコードに応じた処理を行う(ラベルを作って、エラーコードに応じてジャンプさせればいいのかな?)

ビデオモード設定

本の通り、ビデオモードは以下の通りまずはやってみました。

MOV  AH, 0x00
MOV  AL, 0x13         ; 8bitカラー
INT  0x10

そうすると、本に書いてある通り真っ黒の画面がでてきました。カーソルもきえました。

ちょっと他のモードもになったので、本に書いてある以下のモードを試してみました。

1. MOV  AL, 0x12      ; 4bitカラー
2. MOV  AL, 0x03      ; 16色テキスト

そうすると以下のような結果になりました

  • 1. の場合、AL=0x13と同じ結果(画面真っ黒、カーソルも消える)
  • 2. の場合、画面は真っ黒になるものの、カーソルは点滅

(自分だけ違っていたら嫌なので、やってみた方コメください; )

イメージファイル内に記録されるファイル名とファイルの中身の位置

本の内容としては、haribote.sysのファイル名(haribote.nameと記載)とその中身については、イメージファイル上の以下の位置に記録されると書いてあります。

  • ファイル名  :0x002600
  • ファイルの中身:0x004200

んで、これらの位置というのがどのように決まっているのかがちょっと気になったので、調べてみました。
FAT12におけるHDD上の構成を図で書いてみました。
f:id:motojiroxx:20180516020319p:plain

Boot Sectorはいいとして、File Allocation Tableについてもとばします。
「Root Directory」は、FAT12ファイルシステム上で管理されているファイルの目次(ファイル名一覧)という感じです。Windowsで言えばMFT(Master File Table)に該当する部分。
その下の「File Storage Space」は、ファイルの中身を記録している部分です。Root DirectoryとFile Storage Spaceという2つの領域があるということは、ファイル名などのメタ情報とファイルの中身が別々に管理されている(格納場所が1まとめになっていない)ということがわかるかと思います。
でそれぞれの開始位置が0x2600と0x4200になっているので、haribote.nameというファイル名はRoot Directoryの先頭に記録され、haribote.sysファイルの中身はFile Storage Spaceの先頭に記録した、ということになります。

で、今までのOS作成で、自分がどのような部分を書いていたのかを上の画像と見比べて確認してみます。
f:id:motojiroxx:20180516020534p:plain
こんな感じで確認しておけば、自分が今どんな部分を作成しているのかわりと把握しやすくなるかなと。
上記の図の作成においては、以下のサイトを参考にいたしました。
The FAT File System

補足としてですが、クラスタのサイズについては、ファイルシステムによって違うので要注意ですね(NTFSは1cluster=8sector=512*8=4096が一般的です)。
ただ、今回本書では1cluster=1sectorで扱っていくっぽいので、あまりセクタとクラスタの違いは意識しなくて済みそうです(ファイルの論理サイズと物理サイズ、そしてファイルスラックの話があるのですが、フォレンジックの記事を書く際に出そうかと)。

セグメントレジスタ

今までよくわかっていなかったセグメントレジスタの使い方など。
時代背景的には、

  • 昔はレジスタの記憶可能なサイズが16bit(64KB)しかなかった
  • 容量の大きいメモリを積んでいる場合であったとしても、実質64KBしか使えない
  • レジスタの使い方とか工夫して、もっとメモリつかえるようにできんかねー?

という流れでセグメントレジスタができたという流れでしょうか。

このセグメントレジスタと既存のレジスタを使ってメモリの番地を指定することで1MBまでメモリの番地を指定できるようになったと。
セグメントレジスタをつかってメモリの番地を指定する際、アセンブリではこのように記述します。

MOV  ES, 0x0820
MOV  BX, 0x0012
MOV  AX, 0x4141
MOV  [ES:BX],AX

この例だと、

  1. セグメントレジスタESに0x0820を格納
  2. BXに0x0012を格納
  3. AXに0x4141を格納
  4. ES×16+BXで格納先メモリアドレスの計算を行う。メモリアドレスは0x0820 × 16 + 0x0012 = 0x8212
  5. メモリアドレス0x8212にAXのデータを格納

セグメントレジスタを使ってメモリアドレスの指定を行う際は、「セグメントレジスタで大雑把に場所を決める」「レジスタを使って細かな場所を決める」と覚えておけば問題はないかと。


今のところの疑問点など

・割り込み命令の時にはなぜ特定のレジスタに引数を入れておくのか?
・今回、読み込みのリトライの部分とエラー表示の部分を書いたので、わざとエラー処理に飛ばす方法はあるのかな?


時間はかかりましたが、かなり濃い勉強ができました。
次は、3日目の残り部分をやっていきます。時間があれば4日目部分もまとめてやろうかと。

*1:昔のディスクアクセス方式、今だとLBAが用いられる

*2:FDD1枚だと、シリンダは80、ヘッドは2つ、セクタは18あり、記録できるデータの合計は、80×2×18×512(byte per sector)=1,440KB

T-Pot観測記録:2018/4/27〜5/3

最近、ハニーポットの観測日記をよく見かけるのと、ハニーポットの人気が高まっている(?)ので、それに便乗して私も自分で飼っているT-Potの観測記録をつけていこうと思います。

観測記録の投稿周期

毎日やっている方もいますが、基本的には1週間に1度結果をまとめて記事にする、という形でいこうと思います。
また、世間的に気になる攻撃があった場合には、少し周期を短くして投稿しようかと。

T-Pot観測記録:2018/4/27〜5/3

全体の結果

f:id:motojiroxx:20180504003253p:plainf:id:motojiroxx:20180504003300p:plain

他のかたのブログを見るとCowrieに対する攻撃が多い感じがしますが、私のハニーポットではvnclowpotが多い状況です。

また、vnclowpotのグラフをみて見ると、アクセスが周期的に行われていることがなんとなくつかめます。確認したところ

  • 毎日15:00(JST)で5900ポートへのアクセスが多くなっている
  • vncへの攻撃(アクセス)のほとんどがロシアから

ということが判明しました。vnc関連であれば、昔このような記事がありました。
blog.trendmicro.co.jp

POS端末を狙っているのか、はたまた別の端末を狙っているのか。。。


また、ハニーポットの観測記事で有名なブログをみた際、「Webカメラ」の初期パスワードを狙った攻撃が観測された、という記述がありました(「サイバーセキュリティはじめました」というブログです)

私のところでも同じような攻撃があるかどうか確認してみたところ、Webカメラの初期設定ユーザー名と思われるものを使った攻撃を観測できました。
f:id:motojiroxx:20180504004831p:plain

  • username : vstarcam2015
  • password : ipcam_rt5350

(※この組みでアクセスされた、というわけではありません)


あまり、ログ解析はやったことがないので、これをいい機会に勉強しようと思います。
また、私の一番の興味はマルウェア解析になるので、dionaeaの改造なども挑戦していきたいですね。

30日OS自作入門-環境構築編-

先ほどの記事に続いて、環境構築に関して書いていきます。
環境については前回の記事に書いた通りですが、再掲します。

環境

macOS Sierra ver 10.12.6(ホストOS)
VMWare Fusion(仮想環境)
Lubuntu16.04 x64(ゲストOS)

Lubuntuにしているのは好みの関係ですw
画面としてはこんな感じ。デスクトップにターミナルのシンボリックリンクを置いています。
f:id:motojiroxx:20180502012303p:plain

さて、ではここからはゲストOS上で作業を行なっていきます。
まずは、ゲストOS上で自作したOSを動かしたいので、そのためのエミュレータをインストールします。
エミュレータqemuを使います。アセンブラについてはnasmを使っていこうと思います。

qemuインストール
sudo apt-get install qemu
nasmインストール
sudo apt-get install nasm

ここまで終わった時点で、試しにこの本の1日目で使用するhelloos.imgファイルを起動してみたいと思います。

起動コマンド
qemu-system-i386 helloos.img

そうすると、こんな感じで画面が出てきます。
f:id:motojiroxx:20180502020121p:plain

ひとまず起動は完了と。
あとは、本を読んでいきながら少しずつ進めていきたいと思います。

30日OS自作入門-OS自作はじめました編-

本日から、以前から興味があったOS自作をやってみたいと思います。
もともと興味はあったのですが、仕事上優先して勉強しなければいけないことが多かったので、なかなか今まで時間を作れなかったのですが、ようやく時間が空いたので少しずつやっていこうと思います。

モチベーション

仕事としてデジタルフォレンジックマルウェア解析をやっているとしているのですが、フォレンジックは基本OSなどの仕組みからでたアウトプット(ファイル)を元に調査をします。けど、やっぱり「OSの仕組みに詳しくなった方が絶対今後いいよなぁー」という思いと、あとは単純に仕組みを勉強する方が楽しいからw
(あとは、私自身文系の学部出身で、ちゃんとしたテキストを元にOSの仕組みを勉強したことがないので、けっこう知識が散発的というかなんというか。。。)

目標

まずは一通りの仕組みと実装を、ちゃんと自分でコーディングしながら理解する


今回参考にするのは、みなさんおなじみ「30日でできる!OS自作入門」です。
やるのであればまずはこの本!という風にセキュリティ仲間にも言われたので。
30日でできる! OS自作入門 | マイナビブックス


という風にやっていきたいと思います。

環境は以下のとおり(VMのゲスト上で実施します)
macOS Sierra ver 10.12.6(ホストOS)
VMWare Fusion(仮想環境)
Lubuntu16.04(ゲストOS)

Linux環境でやる際には、以下のようなブログがありましたので、この方の情報を参考にやっていきたいと思います。

tsurugidake.hatenablog.jp