labsemi20210105
# labsemi 2021/01/05 13:30 -
## 参加者(敬称略)
shinoda,chinen,zin
codev,kanan,nuuma,tacker,yufu,craysin
win3,okashin,gibbs,shimac

# semi

## yufu

s:ノードは何？

y:
レビュアーID

s:
mistrustを「疑惑」に使っているのか

二重否定になっているのではないか
campaign ネガティブなもの

マイナスが二つあるのはおかしい
mistrust-graphの「-」はいらない
campaign-mistrust-graphだと
キャンペーンじゃないもののグラフになる

trustが悪い
ここで使うべき単語ではない

キャンペーンを行っているレビュワーを
キャンペーンレビュアー、キャンペイナー

y:キャンペーンレビューと呼んでいる

s:キャンペイナーも英語として成立する
キャンペイナーと呼ぶこととする

ポテンシャルキャンペイナーグラフでは

y:ポテンシャル　ポジティブな単語だと考えていた

s:潜在的なという意味なので問題ない

y
エッジを"書ける"
-> エッジを"与える"

campaign-mistrust-graph
->potential-campaigner-graph

y
重みをどうするのが最適化を考えた

重みのところでつまづいている

2つのやりかたを考えた
1. 固有ベクトル中心性に基づくクラスタリング
仕組みの妥当性が存在するのか疑問，議論したい
2. Louvain法

固有ベクトル中心性に基づくクラスタリングについて
s:
このグラフをみながらクラスタリングを行うと失敗すると思う
このグラフにはキャンペーンが入っていないのではないか

y: amazonの実データ
s:その中に正解データは存在するのか

y:　自分が正解とする基準を作った(正解はない)

s: 今使ったデータセットにはキャンペーンはないとかんがえるのが妥当
s:１つあるかも
右側の位数が5のやつ

s: 中心のレビューからエッジがはられないのはなぜ？
共通のものがないということ？

y:共通の商品がないということ

s:グループに基づくキャンペーンだったらこういうふうにはならない

y:グループに基づくキャンペーンはグループがあって同じ商品に対してレビューしている状態のことか　
s:そう

連結度が高いクラスタができるはず
それを想定してアルゴリズムを実装している
(persistantなグループに基づく)

* 右側の5つ
* 左側の3つのノード
これらは何？
これを説明するのが先

現象が埋め込まれている観測データが存在
それから統計的処理を行い、異常検出を行なった
検出されたアノマリーは何を示しているかはわからない

見つけようとしている含まれている場合もある
そうでないものが入っている場合もある

混ざっているもの(意図しないもの)も検出している
それを説明できるようにしないと，このグラフが何か説明できない

うまく説明できないとよくない
* 右側の5つ
* 左側の3つのノード
これらがキャンペーンなのかという説明が必要

真にもとめていたものではないとしても、キャンペーンを示しているのであれば、
使っていないパラメータなどを評価する必要がある
それらを考察するのはノードの塊を決めないといけない

y:

グループのキャンペーンが一人一人のキャンペーンに適用される
グループのキャンペーンは一人一人がキャンペーンとして実行していくので
potential-campaigner-graphで登場するレビュワーはキャンペイナーであると考える

ノードの数だけキャンペーンは存在することが言えると考える

s:キャンペーンは３つである？
y:自分も３つだと考えていた

s: 位数 = エッジの数
y:位数を用いてクラスタリングできると考えている

s:右のノードと繋がっているもの　三角形になっている
y: 左も三角形になっている

s:
固有ベクトル中心性
意外と使えそう
クラスタリング：　色で見ないといけない

y: 固有ベクトル中心性が正しいやり方なのかどうか不安

s: 位数-固有ベクトル中心性　直接の関わりはない？
位数が多いところが有利になっているのか？

y: 位数が高いところが大きくなる

固有ベクトル中心性に基づいてクラスタリングはできると考えた

s: 固有ベクトル中心性のアルゴリズムには欠陥がある
つながっているところがある非常に大きなクラスタが２つあるとする
間一本で繋がっていると仮定
一方はクラスタになるが，もう一方はクラスタになっているのにも関わらず薄くなってしまう

この処理一回行う
0.3以下のリンクを切る
0.3以上のもののみ取り出した後、再度処理を行う
-> 繰り返し適用する必要がある

Louvain法に基づくクラスタリングについて
類似研究でもLouvain法で検出しているものがあった

5つのクラスタに分類することが可能
３種類と仮定していたが、5つ検出できた

正当なクラスタリングができているかという評価方法について考えている
妥当性　使えるのではないかと考えている

s: 正解がわからないからしょうがない

* 気が付いたこと

クラスタリングアルゴリズムに限らず、過去の研究は---してたという表現

1番重要なのはどういう性質をもったグループを検出しようとしているのかということ
過去の研究で使われていたかは本質ではない
得意なターゲットを考慮しないといけない
そこを最初に考慮する

２番目は過去の研究で使われていた手法
アルゴリズムの選定が逆転しているように散見される

* 結果の妥当性について
平均的なレビューとキャンペーンレビューの割合
全体のものに対して、３、５(キャンペーン)がどれだけいるのか

商品が異常に多くて，レビューの数が少ないと偶然出現する（キャンペーンレビューと誤判定される）ものがある(ex. エッジが一本のもの)

s: 時間は見てる？
y:コサイン類似度の計算では使っていないが，別のところで使っている

s:6か月離れた間隔でレビュー投稿
同じジャンルであれば結構いるのではないか

キャンペーンの数が妥当であるかどうか
s:何年前のデータセット？
y:5年前
s:もっと最近のデータセットが欲しいね

データセット数: 5000件 -> 少ない

去年のプライムデー
175million売った(48h)

１秒間に１０００個づつ売れているとすると、
5秒間分のデータしかない

売れる速度が1/10だとしても1分間のデータ

ジャンルなどはきめてデータセットを用意している
s: ジャンルはいくつ?
y: 結構ある

s:ということで、母集団の性質を考えないで評価するのはよろしくない

グラフは悪くないと思う
potential-campaigner-graph
説明できないのがフラストレーションを感じる
母集団の性質を考慮していない点
位数3,5の評価についても同様

y:potential-campaigner-graphで登場するレビュワーはキャンペーンを持っていると考えられる

当初目標　キャンペーンの検出はできたと考えている
クラスタリング
キャンペーンの類似度　あとのこと
密集しているところなどを考察して評価したいと考えている

s:そう
全体をとらえていない傾向がある
一個例題があるとそれだけを見ている感じがする
式の変形などはそれで問題ないけど、現実世界の問題を解くときはそれではダメ

y:固有ベクトル中心性についてはあまり論文に書かなくてもいいか？
s:考えたことは余すことなく論文に書くべき

y:クラスタリングの部分はどこの章に書くか

s:
膨大なデータから行うなどをすればパラメータについても考察できる
どういうパラメータにすればいいかもわかっていない

s
クラスタリング・評価方法をどこで書くかという話？

y:そうです

s:全体もそうだが，
5000件のデータ　参照データにしか使えない
本当はもっと莫大なデータを食わせて評価しないといけない

好ましいのは5000件のデータを用いて手法を説明する
それでインプリメンテーションを書いて
評価実験をする　(正解がわかっている100万件)
そういうことをしないとcompleteな手法の提案にはならない

ぜひ考えてみてください

## tacker

s: どうしてこの実験をしたの
t:前回提案したデータを別のデータでやってみた
s: これは評価実験
t: トピックが似ているもので実験してしまった．別のものにした方がいいか？
s: まずい、
t: トピックの選定が難しかった
余りかけ離れたものを選ぶのもどうかと思った
s: これ１つだけ？
t: 今回は１つだけ
s:サイズいくつぐらい
t:文章量は前回の倍くらい

s:件数は？
t:件数40
前回とほぼ同様

s:文章の中身は感知しないで処理を行うよね
何について話しているかについては理解していない
名詞の出現頻度についてのみ考慮
鹿とかでも構わない

事件の意味的には似たような二つのデータセット
中身は関知していないのでサイズが違うものを持ってきたとできる
悪くないかもしれない

熊　人里に降りてきた銃で殺した
鹿　人里に下りてきたので弓で殺した
似たような結果になるはず

もうちょっと他の構造を持ったデータセットをつかってみて欲しかった

全然違うの入れたらどうなるの？
フェミニズムはまずい
コロナ系

t: 実験２，３で類似度が上がったり下がったりした
形態素解析の問題がある

考察

s:もうちょっと見てみないと分からない

スレッド分岐する場合がある
t:今回のは分岐が多かった
s:分岐をまとめるのはまずいかも
スレッドの長さを見て、言い合いを外す
スレッドの先頭意見を見る

いまは元に対する先頭意見だけやっている？
t:そうです

s:そうすると深いところに飲み込まれると分類が難しいのは当たり前
分類した意見が分岐したところの先頭にあるのかそうでないのかが興味深い

スレッドを意見のまとまりとして考えるのかどうか

実験1をやるまえにスレッド分解を行う必要がある
それを考えないといけない

分類したい意見がどこにあるのかを考える
それを検出するためにはどうすれば良いかを考える

結果を見て，上記の考察ができないといけない

スレッド分解する
P10. 上側の観察三つのうち、一番・三番は改善されるかもしれない

前処理として、木構造としてみるのではなく
長い枝を切って横に並べる
木の根っこから生えている幹を見るのではなく，幹から生えてる長い枝を切って横に並べてみたらどうか
分岐した先頭ツイートに分類したい意見が入っていると仮定すれば，一，三番が改善できるかもしれない
１、３が改善されて、それに引きづられて2も改善される

これを考えてほしい

## crayshin

c:官民のデータベースとは
t:それぞれの個人情報が官庁によって管理されている
それにアクセスするためにP3を説明する
マイナポータル　図の雲のあたり
マイナポータルを通してすべての個人情報にアクセスする

税務情報にアクセスしたいとき
自分も税務署も必ずマイナポータルにアクセスする

s:どこがうれしいのか
t:誰がどのにアクセスした情報が管理できる
z:どこを話しているかよくわからない

s:カード持ってる人がこれを見て何か嬉しいの？
s:自分の税務記録をみるの？
c:たまに見る.税務上必要なので
s:医療記録を見たいと思った人いる？
自分の車の登録情報を見たいと思った人がいる？
ユースケースがおかしい

c: trustサービスを実現するためにあるもの
マイナポータルがあるとそれぞれの官庁の間で行き来してデータがとってこれるようになる．生活保護受給者の取りこぼしが無くなる
s:どうやって取りこぼしをなくすのか？
c:税務申告でいくら取得しているかが確認できる
s:マイナポータル関係ないのでは
c:マイナポータルがあることで個人の情報を秘匿することができなくなる
s:カードを持っている人がマイナポータルに行って，生活保護の申請をしないといけない
c:しなくても勝手にやってくれるようになる
s:それではダメ
本人がいないところで情報が交換される

c:勝手に交換されるが，誰が見たかは記録される
省庁間で情報が交換することが可能になる
s:違うのでは
個人がマイナポータルに行く
財務省から引っ張ってきたデータに署名を付けて厚労省にデータを送る
本人が生活保護を受けたくない人にも生活保護を入れてしまう
好き勝手に他省庁の情報にアクセス可能ができてしまう
勝手に読み書きできるならマイナポータル要らないのでは
c:省庁もデータを見るが企業も個人情報を見れるようにする
s:どういう権限でそれができるのか

保険会社　医療記録をみることができるようになるの？
c:個人が許可をすれば見れるようになる
s:許可っていうのがポータルを参照
crayshinの言い方は勝手に起きる場合もあるということを言っている
c:勝手に配られて口座に送られるということはない(個人給付金の例)
s:あれは網羅的に調べていない
申請があったらその番号で引く
c:マイナンバー制度ができると網羅的にできるようになる
自分が申請しなくても，システム側から受け取るかどうかの選択がマイナポータルからくる
s:マイナンバー制度はいいので次
再識別されない部分に絞るのは危険では？
フラットモデル　再結合がおこりやすい

セクトラルモデル
セパレートモデル
表が余分に必要になる
IDのシャッフルなどが必要になる

シャッフルしたものを使わせるならセクトラルとかセパレートになるのでは

セパレート・セクトラル　ほぼ同じ
個人が見ている分

フラットモデルをベースにして
シャッフルして、アプリケーション側でべつのものがでてきても一番下と同じ

c:そうです．中でやってることはセクトラルモデルになる
s:共通IDを使わせない
という論文にしたら
結局セクトラルモデルが正解であるという論文のまとめ方もあり
フラットモデルからスタートして，再結合が防げる例を示してセクトラルモデルと同等ということを示す

s:アンカー書いてない
監督機関　ここがアンカーなわけ？
アンカーを監視しているだけではないか
c:アンカーになっている部分が技術標準機関で監督機関が監視する

s:トラストのアンカーを提供している主体はどこにあるのか？
c:技術標準機関が提供していると考えていた
s:NISTは標準化機関なのでサービスは提供しない

c:一般で言うトラストアンカーではなく，その技術が安全かどうかの標準を作っているところと、その責任をおう機関

s:スライドタイトルは

c:マイナンバーにおけるトランキングアンカー

s:
トラストアンカー
根本になるサービスアンカー
そこからたどっていく

その言葉は正しくない
s: トラストアンカーの確立

c:研究としてトラストアンカーは必要ないが、
トラストサービスである必要がある
s:トラストアンカーは既にあるものとする

s: さまざまなトラストサービスがあるのは前提でよい
ポイントは漏れた時にどう再結合を防ぐか
観察しているだけで、その人であることがわかるというのを防ぎたい
今日話したような認証基盤の話ではない

c:特異な記載があると個人が識別されてしまうとか
s:性質についてうんぬんしないといけない

z:マイナンバーの話をして分かりにくくなってはのは
現行のシステムといろんな人が抱いている夢と将来像
混ざってしまっているので、いまのものとは違う、とかになってしまった
そんな制度になってないじゃんとか
そこは整理したほうがよい

再結合の話、行き着くところまで行ってマイナンバーを直接使うこと
マイナンバー直接使うのは現状制約がある
という背景を踏まえて
どういうシステムになるのかを説明したほうが良い
chi:修論にマイナンバーどれくらい関与するのか
c:参考にしようとしていた
マイナンバーが修論の中を占めるわけではない
chi:修論の柱(全体)は進んでいるの？
c:まだそんなに進んでない

## codev
co:
論文を書き始めていた
chinen先生と話して３章の設計の部分を仕上げようということになった

# logi

## shinoda-cloud

kanan:
diskを動かしていた電源が落ちた可能性がある
電源さえ治れば治るはず

- raidディスク(newtech) 電源LEDランプがつかない状態
- UPSは二台電源はいらない状態

### 原因
能美市内部の雷による瞬間停電
UPSがダウンした？
　UPSに繋いでいないマシンは生きていることからの推測

### 一時対応
UPS電源について放置(zin-senseiが対応中)
タコ足で電源供給

newtechのRAIDディスク
対応したものの、現時点では復旧していない

shinoda-cloudで扱っているディスク
- SATA RAID 3U(FCモデル)
- ディスク x16
- 電源ユニット NEW-Z230-A x 3

上記全て販売終了

### 対策
- 電源ユニット直す
- 業者に依頼
- 公式サポート(販売していないので、対応を見込めない)

- ディスク購入
- newtech supremacyⅢ RAID EIA 2U
- 新しく買うとなったら移行の可能性が高いのでは？

z:
データを抜き出さないといけない
電源をなんとかするしかない
sexyとも話した
１番が死んでると2,3番も動かない
入れ替えてみて動くか
k:入れ替えてみたけどダメだった
chi:3階にnewtech同型機があるはず

z: もともと篠田研で使ってたやつ
火が入ってないなら抜いていい
同じモデルは同じように死んでる可能性がある

生きているものを確認する

s:３重の冗長？
z:2+1
2ないと動かない
ファンだけ回るので電流引っ張るとダメっぽい？

s:電源12V 50A供給できれば問題ない
電源の冗長システムは別で，本体は12V来てればいい？
電源が２発無いと動かなくて1つしか生きていないというのをコントローラ側で認識していれば
コンソールにメッセージを出すとかが起きるはず
ステータスランプの点滅とか
ただ単に立ち上がろうとするということは，12Vをたくさん出せる電源があればとりあえず動くのでは

１、生きてるかどうか調べる
２，三つとも外して動かす
アップしたらハッピー
アップしなかったら冗長電源のコントローラかメインのコントローラが逝ってる
３，２発で動く位置を探す
４，一つは生きていることが確認できている電源を指して生きている奴を探す

もし、生きているやつがひとつでもあれば３つと生きてる4つを2つづつ確認

z:試して探してみて

s:ダメだったら中開けてメインのボードにどういう電源供給しているか探す
一か所で供給しているなら適当なやつ買ってきて動かす
それで動けば代替ディスクの選択が広がる

s: 最悪、コントローラが逝ってる場合
z:コントローラは多分大丈夫
電源は死んでるが，コントローラの部品はまだある

電源を確認する

z:今FCなのはたまたまFCのやつがあったから使ってるだけ
今ならSASのがいい
現状は限界

zin -> shinoda
研究協力　Comの書類
6日 -> 12日契約

chi: 今なら予算があると丹先生に言われた
７日まで 見積もり取れば考える -> kanan

kanan: まだ見積もりは取ってない
とりあえず、電源を確認する　今晩!!!

z: そろそろ真面目にUSP考える
ディスク移行する必要がある

s:コントローラ起きなかったら死んじゃう

z:コントローラ違っても動く

s:動いているやつにディスク差し替えると動く可能性がある
内外もSAS

kanan:とりあえず電源変えて動いたら３月まで動かす？
調達までは時間かかるからとりあえず動かす

s:いつ壊れるかわからない

chinen:ピンチヒッター作ったほうがいいかも
(代理システム)

## codev
-> zin-sensei
侵入レポート
コメントに対する見解

z:この報告書
見せたくないなどの意図がないなら共有したほうがいい

s:ファイル作る時、なんの論文かわかるようにするようにしたほうが良い
結構言われている
癖をつけるべき

z:ルートをとられたという根拠についてがポイント
ルート取られたか取られてないかが重要
そことちゃんと明記して欲しい

最初に辞書攻撃受けたログ
古すぎてなくなっているのか、
消されたという根拠はあるのか

codev:WIDE合宿の期間
9/8,9,10 に立ち上げ(9/6の週)
9月のログは消えないのかと思っていた
9/22のログは残っていた
ログを漁ってもなかったので

z:これ、もしとられているのであったら
研究室のPWなどを変更するなど、
片っ端から全部変える必要がある

非常に危機感を持たないといけない事
取られた可能性があるのは否定しないが
他の可能性ないの？
rootとられたならどういう経路で取られているのか、など
そこをもうちょっと掘り下げないとダメかと思う
そのあとのログとかファイルは残っている?

codev:ファイル残っている

z:rootをとってるなら真面目に消す気がすると思う
rootを取られていないと考えてまったりと指導していたが、
rootを取られたならば危機感を持つべき
rootを取られたという根拠はログが残っていないという１点だけ？

codev:残されたログを見る限りなかった

z: 簡単すぎるPWなので、つないで3分にやられていた可能性もある

z: xflowについて
TCPセッション情報がある
これとログイン元が一致しない
なぜ？
踏み台を経由して接続したならsshのログにも
踏み台のログが残るはず

codev:攻撃者のIPが記録されるという認識だった
s:攻撃者の鍵なんて登録するか？
operatorが付いてるマシンを直接使ったりはしない
自分のところに攻撃が来てしまう
攻撃者のマシンは直接繋がない

chinen:何が言いたいのか

codev:xflowのIPアドレスが一つも一致しなかった

s:辞書攻撃してるやつと，C&Cから命令を受け取れるマシンが分れている
s: 辞書攻撃用のマシンと高度な攻撃をするマシンは別れているという事であれば辻褄が合うのでは

z:一致しなかったというのはsshのログにある時間のxflowで出てこないという話？それとも時間を幅広くとっても一致しないという話？

codev:どちらでも一致しなかった

z:前者の場合はログがちゃんと取れてない
とっているインターフェースが以外からアクセスされた
sflowの場合、サンプリングから外れて運悪く取れなかった
ちゃんとフローが取れていると想定するなら取れていないのはおかしい

s:その場合はログの書き換えをしているので，そこまでやる人が一時ファイルを置いて行くのはおかしい
取れてる

なんか調べ方が浅い
分からない事を可能性があるで終わらせている気がする
rootが取られていたらヤバい

z:少なくともrootが取られたかどうかを真面目に調べてほしい
もうちょっと真面目にやるべき

chinen:root取られてるなら2次，3次災害が起きる可能性が十分ある

z:xflowとマッチしないのも何かおかしい

前半　俯瞰的に調査して、ちゃんと調べられていない
まとめ　フワフワしている

最後　flow <-> sshマッチしない理由などを調べればrootが取られているかとかわかる
z:ログがいつから残っているのか
chinen: マルウェアらしきものがインストールされた時期はわかったのか？
codev:12/10にcrontabが編集されてマルウェアを実行するようになった
そのタイミングで不正アクセス・ダウンロードしたと考えられている

s: ftp-userのcrontabいじるのは変
rootのcrontabがいじられていない -> rootは取られていない(?)

z:このユーザだけでやってみようという感じ

chinen:おとりかもしれない

z:おとりの可能性はある
急がなくてよいので全体的にPWを変える

y:パスワードを変えようという動き
まだ変えていない
root奪取関係せず、変更する方針で動く

s:変えるときはなるべく短時間で一気に変えないとダメ
リストとかを作って現行でログインできるか確認して一気に変更を行う

## 次回ゼミ
1/12 13:00-15:00
一人15-20分程度