labsemi20201215
# 2020/12/15 13:30 -
## 参加者(敬称略)
shinoda,chinen,zin
codev,kanan,nuuma,tacker,yufu
shimac,gibbs,win3,okashin

## semi

## yufu

shinoda
左がなに

yufu
ネットワーク分析をして出てきたグラフ全体

左　エッジがしっかりかかっているグループ

shinoda -> これは全部キャンペーン? yufu -> そうです

shinoda
キャンペーンの定義
グラフで示されているものは，もれなくキャンペーン？
キャンペーンでないものは含まれていない? yufu 含まれていない

shinoda -> 食べさせたデータはキャンペーンだけのデータなの？　yufu ->違う

shinoda
用語が定義する
検出しようとしているものはキャンペーン
生データがあって、処理、グラフを作成
この状態になっているものは確定的にキャンペーンなのか？
キャンペーン度が高いものなのか？

yufu
キャンペーン度が高いもの

shinoda
このグラフを人間が与えられた時にこれからキャンペーンを検出する作業をする必要がある

このグラフのことを別の名前をつける必要がある
登場しているノードの状態に名前を付ける

"これらのキャンペーン"という表現はどのキャンペーンかわからない

shinoda
何を見ている、何を処理したらでてくる？

yufu
Amazonデータセットがある，そこからお金をもらってレビュー投稿している人たち（わからない）
それらのキャンペーンの特徴を定義した
shinoda
キャンペーンを定義した？

yufu
そうです

shinoda
用語が曖昧
因果関係が揺れている

キャンペーンが判明して一番最後に出てくるもの
キャンペーンのユーザは何かしらの対価として報酬を得ている

一番最初にやったのは？

yufu
テキストを書いたとか，星の評価とか

shinoda
キャンペーンに特有のプロパティを持っているということで説明できる
それがキャンペーンを定義したという言葉になってしまっている
キャンペーンに特有なレビュー中とプロパティを定義

yufu
それらをもとに，レビュアーを取捨選択

shinoda
直前の定義は
レビュわーは洗濯できない
ここから直接レビュアーを選択できない
なにを選択するのか？

yufu
星，投稿時間とかを元に，プロパティを定義

shinoda
キャンペーンは定義できない

yufu
そこから定義して、そこから出てきた値がある　
星評価，購入したかどうか，

shinoda
それはキャンペーンに特有のプロパティと言えばいい

shinoda
レビュアーにそのプロパティが付いているわけではない
キャンペーンに特有のレビューが持つプロパティをほかの何かと組み合わせて作らないといけない
まだレビュアーは見えていない

見えているもの
レビューの集合
レビューには様々なプロパティがある
yufuさんが定義したキャンペーンに特有なプロパティ

yufu
レビュアーIDではなくレビューに対して
キャンペーンに特有なレビューのプロパティを元に値を出しました

shinoda
なんの値?

yufu
ベクトルで出した

shinoda
用語を短縮しよう
キャンペーンの一部であるようなレビューを特徴づけるプロパティ
キャンペーンレビュープロパティと呼ぶことにする

キャンペーンレビュープロパティがあって
これを一つのレビューにかけると
1つ1つのレビューに対して
per レビューの特徴ベクトルが出る

次に、特徴ベクトルの集合を相手にする
方向が同じベクトルを決める

yufu
レビュー同士でベクトルの類似度を見る　cos類似度

shinoda
二つ？複数?

yufu
2つのノードでやる (nC2)

shinoda
60C2の類似度ができる

yufu
それぞれのレビューごとの類似度
レビューの特徴ベクトルを計算して，

cos類似度が0.5で計算している
cos類似度が0.5以下のノード同士は「似ていない」としている・消去している

キャンペーンレビュープロパティを元に作られているので，
そこで出てきた繋がりがあるものはプロパティが類似しているということになる

shinoda
２つのペアの似ているものがたくさんあるとい状況
ここから先は？

yufu
二つの間に繋がりが出た

shinoda
確認
特徴ベクトルを比較するレビュー
レビュー(dataset)全体の集合　or ある商品にたいするレビューの集合？
cos類似度を計算する集合が存在

yufu
データセット全体のレビュー
そこから，0.5以下のcos類似度は似ていないと判断

プロパティが似ているものを検出できた
その商品の繋がりがあるので、プロパティからasin番号を抽出

shinoda
特徴ベクトルが類似しているレビューが２つの集合しかない

yufu
それがたくさんある．レビューのテキストの集合のasin番号
キャンペーンレビュープロパティは
星・時間・購入したか・テキストがあるか
レビューのプロパティにはレビューID,asin番号，投稿時間が入っている

レビューテキストで出てきたレビュアーID,,,?

shinoda
何言ってるかわからない

yufu
レビューのノードのつながりがある　２つのペアの集合がある

そこのペアを並べてそれの名前

shinoda
名前とは？

yufu
レビューのかたまり

shinoda
今見えてるのは，似てると判定されたレビューのペアの集合が見えている

yufu
ペアに名前を当てる

shinoda
ペアに名前を割り当てるの？

yufu
レビューに割り当てる

shinoda
それはレビューのIDがあるのでは

yufu
レビューのIDはない
レビューのIDはある

shinoda
テキストとは

yufu
レビューに入っているプロパティ
レビューのプロパティには
* 投稿者の名前(レビュワーID)
* テキスト
などがある

レビューに名前をつける
レビューにレビュあーIDを割り当てる

shinoda
同じIDのレビューがたくさんできてしまう

yufu
そうです
AさんがA,Bのレビューペア，AとZのレビューペアが出てくる

shinoda
レビューのペアがある
レビューにIDをつけて、そのIDはレビュアーのIDと同じ？

これ要するに今見てるレビューペアからそのレビューペアを生成しているレビュアーIDを計算していることになる？
例えばある特定のペアがあるとする
そこに入っているレビュアーID x-y
x-yという名前がペアに対してつくの？
同じ名前のペアがたくさんできそうな気がする yufu できると思う
名前として使うのかx-yというペアがいくつできるのかをカウントするのか
それぞれのペアを識別するのにつかうなら問題

yufu
y-xとかの組み合わせが出てくることはない
おなじ重なりになることはない

shinoda
いや、ある
全てのレビューを対象にしている

yufu
それはあります
同じ名前がたくさん出ていて，それを分類していないので見づらい
shinoda その結果がこのグラフ？
yufu まだやることがある

yufu
その前にペアが出てきたのがアマゾンのデータセットではなく、一つの商品にたいするものを測っている

shinoda
最初の定義が違う
特徴ベクトルの計算は同じ商品の内側で計算する
特徴ベクトル計算するなら別に全部やっても構わない気がする
違う商品に対するキャンペーンでも同じレビューする？

今回は特定の商品の特徴ベクトルを計算した

yufu
shinoda 特定のレビュアーIDで同じ商品に２回レビュー投稿はしない? yufu -> はい

shinoda
この演算は何をしようとしているかというと似たようなレビューをしたレビュアーのIDがわかる

yufu
プロパティが似ているペアを算出できた
これをもとにグラフを生成する
これを全商品分行なった

shinoda
どんなグラフができるの

yufu
完全グラフで作っている

shinoda
手元にあるのは，特定の商品に対する似たようなレビューを付けているレビュアーのIDを付けたレビュー
そのグラフにするならレビュアーIDがノードとするとノードの数、レビューの数と等しい
似たようなレビューが並んでいるグラフにしかならない？

yufu
同じレビュアーID，例えばA-B,A-Zというペアができたとすると

shinoda
これ、やめよう
終わらない

これは明日の午後14:00-研究室でやる

それまでに何に対してどういう操作をおこなったか明確にする
それぞれの操作を説明できる例題を用意しておく

## codev

shinoda
シナリオ埋め込みもできる
指示はコマンドでやる？ -> コマンドでできる
始まりも取れる

codev
reo-sanのフレームワークを参考にした
考察に用いる

## okashin
研究テーマ案

偽情報の拡散
* Deep fakeの特定

ネットワークセキュリティ
* ログの可視化

shinoda
* ログの可視化
やりたいことは分かるが，みんなやってる
何か別のネタが無いとダメ
有名な奴はNICTER
手法が伴っていないと，やりたいと言っているだけ　そこから進まない
最近のNICTERはアニメっぽくなってる
昔の10年ぐらい前，始めたころのやつは違っている
動画
飛び込んで入ってくるパケットが間違って来たか，攻撃
特定のセンサに来たパケット
奥がソース，手前がデスティネーション
横がIPアドレス，縦がポート番号
ポート番号をいくつか使って，異なるアドレスから送られてきたことを示している
縦に並んでいるもの
ブルーで行われている攻撃　ポートスキャン
あるIPアドレスのレンジに対してポートスキャンしている
インターネット上の複数のアドレスからやっている

赤いアーク　一つのホストからポートスキャンしてる
逆引きしてソースを国の真ん中から飛んでくるようにしたもの

ソースを逆引きして国旗を表示する
小さい四角の箱の中が座標になっている
ソース，ポート，プロトコルなどが座標にmappingされている
図形を見れば何をしたのかがわかる
色を見るとマルウェアの種類がわかる

可視化のためのアイデアがないといけない
学会まである
vissec ref: https://vizsec.org/
いろんなvisualizationをする

見たいものの性質を詳しく調べてクローズアップする
何を目的とするかがわからないといけない
ログが見にくいというのは確か
ログを見やすくしたいというのも確か
visualizationも一覧性がある形で見せてくれるものなど
DBに入れといてwebでシュってやる
安倍さん　そのログを取るマシンの研究

巨大なシステム(amazon, google)になると

安倍さん　ログに命を懸けている
１億レコード/min ぐらいのレコードが入ってきたときに
こぼさず、素早く検索できるデータベース
データベースの問題ではなくホストマシンの問題
みんなが何を見たがっているのか
需要がわからないとやりようがない

zin
visualizeとかではないけど、
重要なログを見つけやすくする
SIEM
相関とったりが主
すごくいっぱいあると思う

## gibbs
高速なログ検索基盤

通信のボトルネック検出

shinoda
高速なログ検索基盤
前半は安倍君のD論を読んでもらう
何を見つけたいかを決めておかないと表示はできるけど...というシステムができる
レイヤごとに何を表示して，それを表示すると何が見つかるのか
ログをレイヤごと，ホストごと，時間ごとに抽出してグラフ化するツールは，ネットワークオペレータの数だけある
そこでできないことは何かを調べないといけない　何を知りたがっているのか
ツールは山のようにある

通信のボトルネック検出
難しい　よくある
背景
一番簡単なのはtracertでできる
webExが不安定なのは高度なボトルネックで
WebExが不安定な原因の推測は，
WebExは少なくとも３つのストリームを使っている
* 音声ストリーム　明瞭に入っているので独立していることがわかる
* 映像・ビデオのストリーム　コマ落ちしなかったのでそこそこよさそう
* 画面共有のストリーム　問題が大きかった

ボトルネックがどこにあるのかというのを調べるのは，音，映像は通っているのに画面共有だけ通らないとはどういうことなのか
ネットワークレイヤーだとフルで帯域が出ていて問題がないように見える
もしネットワークレイヤに問題があってもフルに流れているので見つけられない
どこでスロットリングしているかはアプリケーションがしている
WebExはP2Pではなく，サーバーに上げて再配信している
観測すべきボトルネックが定義できても，どこで計測すればいいのか
障害があるのはyufuさんのwebExアプリからサーバまで
どこを調べればいいのかという問題になる
アプリケーションの使っている通信のパターンを知る必要がある
先ほどのようなボトルネックはわからない
アプリケーションの内部でスロットリングしてしまうと外ではわからない

なので，このボトルネック検出はかなり難しい
面白いのはマイクロバーストの検出

今のネットワークの測定　全部見ることはしない
全部見てると大変なのでサンプリングする
400個に１個とか
サンプリングの間に起きている現象は捕まえられられない
測定方法に由来する難しさもある

通信，アプリケーションのボトルネックを検出するのは必要
WebExの中では統計情報が見られる 統計情報を取っている
なんか遅いね，という漠然とした印象をテクニカルに調べていく研究もなしにもあらず
SINDANは，ユーザーが大したことをできないという前提で帯域も含めて調べる

### gibbs 研究テーマ案

shinoda
- ログ
前半は阿部くんのD論を読んでもらう
大量というのがキーワードで、何を見つけたいかを決めないといけない
レイヤーごとに何を表示して何を見つかるのか
ログをレイヤーごとホストごとに抽出してみるとかは無数に存在する
その点を留意して何を研究したいかを考える必要がある
- 通信
これも難しいというかよくある
背景を言っておくとtraceoutが一番簡単に言える
さっき起きた高度なボトルネックで
webEXは少なくとも3つのストリームを使っている
一つは音声->明瞭に入ってきたので独立している
2つは映像のストリーム->yufu山はコマ落としになってないので明瞭
3つは画面共有のストリーム
画像共有はどこで異変があったのか？
ネットワーク層ではフル帯域は出ているはず(1,2はうまくいってるため)
誰がプレゼンを送るのを拒否しているか？
おそらくアプリケーションの方
なぜならwebEXのアプリで優先度を決めているから
p2pではないため一度webexのサーバーに送っている
障害があるのはおそらくyuhuさんと
yuhuさんの送っているサーバーに障害がある
アプリケーションの内部でスロットリングしていると外からは分からない
ボトルネック検出はかなり難しい
マイクロバースの検出
どこでどれくらい頻繁に起きているか検出できているか見る技術
ネットワークの測定は全部見ることはしない
全部見るのは大変、サンプリングして測定している
サンプリング間の現象は捕まえられない
通信のボトルネックを検出は重要
漠然とした通信を調べるのが知りたい

両方とももう少し深掘りが必要

## logi

### 攻撃
codevさんのftpサーバが攻撃を受けた件
general参照

userとかデフォルトのまま
日曜日にsshブルートフォースアタック
パスワードがばれる
C&C サーバとして使われてしまった

zin
そのマシンは117セグメント

どこから攻撃されたの？

codev
JAISTの寮からアクセス

zin
ブルートフォースはどこから来たのか

codev
今は分からない

sshの攻撃を受けていたのは篠田研関連で受けていた

shinoda
辞書攻撃された？

codev
そう考えられる

shinoda
篠田研のどうのこうのとは？

codev
sshのアクセスするときのuser:shinoda-labという名前で攻撃を受けていた

shinoda
どこのsshのログ？

codev
そうです

150.65.110.3 <- kanan-san

12/13
時間がわからないと攻撃を受けた時に大変

zin
前後関係を調べないと
問題が起こる前に誰かが入ろうとした形跡がある
問題が起きた後誰かが入ろうとした痕跡
よく関係を精査しないと大変な話になる

情報社会基盤センターから返事をする
指導教員に返事
知念先生

shimac kanan
寮からアクセスしに行っている

攻撃じゃなくて調べに言った形跡
調査した形跡

それ以前のアクセスがあるはず

Accessした時間から付け合せる

117のセグメント
JAISTのネットワークにしかつながっていないので、だれに攻撃されたのか確認する
朝10:30くらい

shimac
9:45-9:50くらいにアクセスしたのでログが残っているはず

yufu
実際の時間とログの時間はあっていた

kanan,shimac 12/13 20:30くらいのログが残っていた

実践したい人は共有して調査
解析してなにがやられたか有志を募って議論
反省を踏まえてデフォルトユーザのまま放置している人はいないか？など対応する

chinen
default-userはなんの話？

codev
shinoda-cloudでテンプレートからVMを作るとデフォルトパスワードとユーザが作られる

yufu
デフォルトユーザ名は見当たらなかった
多分、codevがテンプレート作成後、
ftpユーザを作った

そこでroot権限を使った

chinen
デフォルトユーザがないとは？

yufu
デフォルトユーザ名がない
(shinoda-lab)

chinen
shinoda-labのPWとかが撮られているならPWとかを全て変更する必要がある

テンプレートがおかしいのか，全部パスワードが流出したのかで対処が違う

### ３月修了の人

shinoda
3月に修了
https://shinoda-lab-students.slack.com/archives/C9P046PPC/p1608016971184600
3月修了予定者【連絡事項】
１．学生番号
２．学生氏名
３．取得希望学位
４．論文題目（仮題でも結構です）
５．審査委員（主査を含む４名）
６．学内進学試験受験の有無
７．社会人コース学生の審査でのテレビ会議システム利用の有無(⇦これは無視して良い)
８．審査会開催期間で不都合な日時

これを教える

### 年末年始の挙動
ホワイトボードで
横軸　日付
縦軸　名前
帰省期間の下に電話番号

## 次回日程
12/24(木) 13:30-