G. Kambourakis, C. Kolias and A. Stavrou, "The Mirai botnet and the IoT Zombie Armies," MILCOM 2017 - 2017 IEEE Military Communications Conference (MILCOM), Baltimore, MD, 2017, pp. 267-272. doi: 10.1109/MILCOM.2017.8170867

Miraiで使われているコマンド類など詳しく記載されています

https://www.iij.ad.jp/dev/report/iir/pdf/iir_vol33.pdf

HajimeやMiraiについて詳細に書かれている文献(自分自身購入してはいないのですが、試し読みできる範囲ではかなり詳細に書かれていると感じます。めちゃくちゃ高いですが…)

https://www.amazon.co.jp/Botnets-Architectures-Countermeasures-Challenges-Security/dp/0367191547

2020-05-16

メモリ効率の良いトラフィック監視を可能にするSketch技術をまとめる（1/？）

Sketch Network Monitoring

はじめに

本記事は効率的なインターネットトラフィック情報監視技術であるSketch技術について，論文を読んで勉強したものです．実際のトラフィック監視業務や理論的背景となる諸定理の厳密な定義に明るくないため，誤ったことを書いている場合にはご指摘いただけますと幸いです．勉強しなおし，可及的速やかに対処いたします．
本記事では，ネットワークトラフィック監視に特化した手法ではなく，Sketch手法として有名なCount-min Sketch[1]を追い，Sketchの基本的事項についてまとめます．

ネットワークトラフィックの監視

統計量

ネットワークトラフィック監視の文脈では，トラフィックの統計情報を用いて異常や攻撃の検知を行います．インターネットが普及している昨今，ネットワークトラフィックは非常に大規模なデータストリームであるため，1パケットずつ監視を行うのは現実的ではありません．
そこでトラフィックを統計情報という縮約された情報に落とし込んで監視することが一般的となっています．
また到着する全てのパケットを対象に計算するのではなく，NetFlowやsFlow，一度サンプリングされたデータを以降の監視対象としそれ以外は無視するSample & Hold[2]，サンプリングに優先順位を付けるPriority Sampling[3]などを用いて計算対象となるパケットを減らすことなども行われています．

ここで統計情報というのは，例えば，パケットレートや，データレート，エントロピー（平均情報量）などです．

パケットレートやデータレートが，パケット量やデータ量の異常度を測るのに用いられることは容易に想像できると思うのですが，エントロピーは聞きなれない言葉ではないでしょうか．

エントロピーは主にDDoS攻撃やポートスキャンなどの攻撃を検知するためによく用いられます．

エントロピーは次の計算式で算出される値で，情報源の出現頻度の偏りを測るのに用いられます．ここで， $N$ は情報源の総数， $p(x_{i})$ は情報源 $x_{i}$ の出現確率です．

$E = - \sum_{i}^{N}p(x_{i}) \log p(x_{i})$

しかし当然全てのIPアドレスの真の出現確率は分からないので，実際には，ある単位時間（ウィンドウサイズ）に観測・サンプリングされたデータを使って以下のように計算します．ここで， $M$ はウィンドウサイズ内に観測されたパケットの総数， $X$ はウィンドウサイズ内で観測された情報源の集合， $m_{j}$ は，情報源 $j$ の出現回数です．

$E = - \sum_{j \in X}\frac{m_{j}}{M} \log \frac{m_{j}}{M}$

エントロピー値には，出現頻度がある情報源に偏っていると値が小さくなり，逆に分散されていると値が大きくなるという特徴を持っています．
例えば，DDoS攻撃が行われると，一般的には大量の異なるホストからの攻撃トラフィックが流入するのですが，情報源を送信元IPアドレスや宛先IPアドレスに設定したエントロピー値を監視することで，送信元IPアドレスが異常に分散していないか，または宛先IPアドレスが異常に集中していないかが分かります．

問題点

ネットワークトラフィックから統計量を計算する時に問題となるのは，メモリ効率です．

例えば，エントロピー値は情報源の確率密度分布（ここでは単にヒストグラムを仮定）を用いて計算されますが，これを実現するにはIPアドレスをキーにしてそのIPアドレスの出現数をデータとして保持しておく必要があります．

しかしIPv4アドレスは全部で $2^{32}$ 種類あり，かつ，大量のデータが到着することが予想されます．

そのため，全てのIPアドレスに対応可能な形式を単純に実装してしまうと，メモリ効率が悪くなってしまいます．

そこで考えられたのが，Sketchデータ構造の導入です．Sketchというデータ構造を用いると，メモリの使用量を抑えられ，次の章で示すように利用するメモリ量を事前に把握できます．これによって多くの場合はKB（キロバイト），多くてもMB（メガバイト）のデータ量でトラフィックを監視することが可能となります．

Sketch技術はネットワークトラフィック用に提案されたものではありませんが，今後，Sketch技術とは，ネットワークトラフィック監視にSketchデータ構造を用いている技術全般を指すことにします．

Sketchデータ構造

基本形式

Sketchデータ構造は，キーの候補数（カテゴリ数）が多い場合に使われるデータ構造[4]で，データストリームを計算対象とする，Streaming Alorithmの一種です．

Sketchは以下に示すように $H \times K$ 個の二次元カウンタで構成されたデータ構造です． $H$ はハッシュ関数の個数で， $K$ はハッシュ関数の値域の最大値です．

Sketchの配列を $S$ で表すとすると， $S[i][j]$ のカウンタは「 $i$ 番目のハッシュ関数を用いてハッシュ値 $j$ が出力される $key$ が何個観測されるか数えるためのカウンタ」となります．

Sketchはカウンタ（たいていはintを利用）を利用するので，カウンタ変数の型とSketchのサイズから，使用するメモリ量が事前に分かります．
理論的な空間計算量はSketchの設計によって異なります．例えば以下で説明しているCount-min SketchはPoint Query（あるキー値のカウンタ値がどのくらいあるか知るための操作）をするためだけでは，空間計算量は $O(\frac{1}{\epsilon^{2}} \log \frac{1}{\delta})$ となります．

（追記：2020/07/26 『メモリ効率の良い』と言いつつ空間計算量の話が明示的に書かれていなかったので追記いたしました）

f:id:madomadox:20200411194140p:plain — Sketchデータ構造

Update操作

データ構造に $(key, val)$ の組のデータを挿入することを考えます（以降この操作をUpdate操作と呼ぶことにします）．
ここで $key$ はIPアドレス， $val$ はIPアドレスの出現回数です．（ところで $val$ を計算するのにSketchが新たに必要となり堂々巡りになりそうな気がしますが，運用上，出現回数を数えることはせずに， $val$ を1に設定して，新たにパケットが到着するごとに更新しているのだと思います）．
updateは， $i = 0, 1, 2, ..., H$ について，次に示す手順で行われます．

入力となる $key$ を，ハッシュ関数 $h_{i}$ でハッシュ化し， $j = h_{i}(key)$ を取得
得られたデータ $j$ に対応するカウンタ $S[i][j]$ を $val$ だけカウントアップ

f:id:madomadox:20200411192738p:plain — Update操作

この更新方法により，管理しておくべきカテゴリの数が高々 $K$ 個に圧縮されます．
また，レアなカテゴリは基本的に寄与が少ない割にヒストグラムを無駄に大きくしてしまいがちなのでどこかに混ぜ込んでしまったりするのですが，Sketchだとそれが自然に行われるので，そういった点でも都合が良いと言えます[4]．
ここで，ハッシュ関数としてどのようなものを用いるかという話ですが，基本的には以下の式を用います．

$h_{i}(key) = a_{i} \times key + b_{i} \mod K$

ここで， $a_{i}$ と $b_{i}$ は整数であり，値域は素数 $p$ を使い， $[1,p]$ です．（ハッシュ関数やパラメータの選び方は手法によって異なります．）

Query操作

次にこのSketchを利用して， $key$ に対応する $val$ を取得します（以降この処理をQueryと呼びます）．ハッシュ値が，値域 $K$ によっては衝突する可能性があるため，どのような操作で取り出せばより推定値として適切かを考える必要があります．

今回は，Count-min SketchのQueryを考えてみます．Count-min SketchのQueryは以下の式で表現される操作を行います．

$\displaystyle Q(key) = \hat{v}_{key} = \min_{i} S[i][h_{i}(key)]$

文字に書き下すと，1行目から $H$ 行目まで $h_{i}(key)$ を計算した時の，対応するカウンタ値 $S[i][h_{i}(key)]$ の最小値を， $key$ に対応する $val$ の推定値として出力します．
この操作の意味を直感的に考えると「カウント数が最小値よりも大きい場合は確実に衝突しているので，より衝突の可能性の少ない最小値を推定値として採用する」となります．
この推定値がどのくらい良いかというのは，次の定理で示されています[1]．ここで， $\|x\|_{1}$ は $x$ のL1ノルムを指します．

$key$ の真の $val$ となる値を $v_{key}$ ，Queryによる推定値を $\hat{v}_{key}$ とすると， $v_{key} \leqq \hat{v}_{key}$ かつ $(1-\delta)$ の確率で $\hat{v}_{key} \leqq v_{key} + \epsilon \|v\|_{1}$ を満たす．

Count-min Sketchは $\epsilon$ と $\delta$ の2つのパラメータを持っており，Sketchのサイズは $w \times d = \frac{e}{\epsilon} \times \ln(\frac{1}{\delta})$ で決まります．なお， $e$ はネイピア数です．
定理から， $\delta$ と $\epsilon$ を小さくしていけば，比較的高い確率で真の値に近づいていくことが分かります．しかしその分Sketchのサイズが大きくなってしまうのでバランスを調整する必要があります．

実際に簡単にプログラムを作成して確認してみます．以下はSketchに $(10,1), (150,2), (132,3), (140, 4), (13, 5), (2, 6)$ の6つの $(key, val)$ の組を挿入し， $key=2$ の， $val=6$ を取得できたか試してみたものです．
cmsketch.cpp

#include <iostream>
#include "cmsketch.hpp"

int main()
{
    CMSketch cm_sketch(0.05,0.01);
    cm_sketch.setHash(173);
    
    cm_sketch.update(10,1);
    cm_sketch.update(150,2);
    cm_sketch.update(132,3);
    cm_sketch.update(140,4);
    cm_sketch.update(13,5);
    cm_sketch.update(2,6);
    
    cm_sketch.printSketch();
    int q = cm_sketch.query(2);
    std::cout << q << std::endl;
}

cmsketch.hpp

#ifndef _CMSKETCH_H
#define _CMSKETCH_H

#include <iostream>
#include <vector>
#include <random>
#include <limits>
#include <algorithm>
#include <cmath>

class CMSketch
{
    public:
        CMSketch(float epsilon, float delta);
        void setHash(int prime);
        void update(int key, int value);
        int query(int key);
        void printSketch();

    private:
        int prime;
        int h;
        int d;
        std::vector<std::vector<int>> counter;
        std::vector<int> hash_coef;
        std::vector<int> hash_intercept;
};

CMSketch::CMSketch(float epsilon, float delta)
{
    h = ceil(log(1.0/delta));
    d = ceil(exp(1.0)/epsilon);

    counter.resize(h);
    for(int i = 0; i < h; i++)
    {
        std::vector<int> tmp(d,0);
        counter[i] = tmp;
    }

    hash_coef.resize(h);
    hash_intercept.resize(h);
}

void CMSketch::printSketch()
{

    for(int i = 0; i < h; i++)
    {
        for(int j = 0; j < d; j++)
            std::cout << counter[i][j] << "," ;

        std::cout << std::endl;
    }
}

void CMSketch::setHash(int prime)
{

    std::random_device seed_gen;
    std::default_random_engine engine(seed_gen());

    std::uniform_int_distribution<> dist(0,prime);
    int row_size = counter.size();
    
    for(int i = 0; i < h; i++)
    {
        hash_coef[i] = dist(engine);
        hash_intercept[i] = dist(engine);
    }
}

void CMSketch::update(int key,int value)
{
    
    for(int i = 0; i < h; i++)
    {
        int hash = (hash_coef[i] * key + hash_intercept[i]) % d;
        counter[i][hash] += value;
    }
}

int CMSketch::query(int key)
{
    int query = std::numeric_limits<int>::max();

    for(int i = 0; i < h; i++)
    {
        int hash = (hash_coef[i] * key + hash_intercept[i]) % d;
        query = std::min(query,counter[i][hash]);
    }

    return query;
}
#endif //_CMSKETCH_H

Count-min Sketchのパラメータ $\epsilon$ と $\delta$ は，それぞれ $0.05, 0.01$ ，そして $p=173$ として試してみました．
実行結果の一例を以下に示します．

f:id:madomadox:20200516204342p:plain — 実行結果

上の二次元に羅列されている数値がSketchのカウント数を表示したもので，一番下の数字が推定値として出力された値です．
Sketchを見てみると，2行目に「１１」という文字が見えます．これは，2と13のハッシュ値が衝突してしまっていることが原因です（ $key=2$ は $val=6$ ， $key=13$ は $val=5$ のため）．しかし衝突が発生していない行があるので，各行について $key$ のハッシュ値が示すカウンタ値（6,11,6,6,6）の最小値を取ると， $key=2$ の出現回数として，正しい結果の6が出力されています．

課題

しかし，Sketchデータ構造を用いたネットワークトラフィックの統計量の計算には，次の課題があります．

1つ目は統計量の精度が低くなることです．ハッシュを用いて確率的に処理を行う関係でどうしても実際の統計量との誤差が生じてしまいます．

2つ目はホストの特定ができないことです．異常検知ではその異常の原因となるホストのIPアドレスを特定する必要があるのですが，Sketchではそれができません．なぜならハッシュ関数を用いてIPアドレスをハッシュ化したものを用いるためです．~~ハッシュ関数は一方向関数なので，ハッシュ値からIPアドレスへの逆変換ができません．~~（追記：2020/07/26 ハッシュ関数の概念はあくまで「データ構造とアルゴリズム」で出てくるものであり，暗号学的ハッシュ関数に必要となる一方向性という性質にはそぐわないと考えたため訂正いたします．ただしハッシュ値からIPアドレスに変換するのはそのままでは困難であることは変わらないため，工夫が必要となります）

この二つの課題を解決するため，研究者はより精度の高い統計量を計算したり，ホストの特定が可能となるような手法を研究しています．

まとめ

大量にデータが観測されるネットワークトラフィック監視において，パケット単位で監視するのではなく，統計量を計算してトラフィック情報を縮約する必要があります．
しかし，IPアドレスという，考えられるキーの数が非常に多いデータを対象にした計算を行うとなると，単純な実装ではメモリ効率が悪くなります．
そこで，Streaming Algorithmの一種であるSketchデータ構造を利用し，メモリ効率の良いネットワークトラフィック監視手法が提案されています．
今回は有名な手法，Count-Min Sketchを実装して，Sketchの基本を確認しました．
次回以降は，実際にネットワークトラフィック監視に特化したSketch技術をまとめていきます．
どこかで，今回引用させていただいたサンプリング手法についても紹介していこうと思います．

（2021/04/11 追記）
1個書きました。
madomadox.hatenablog.com

参考文献

[1] Cormode, Graham, and S. Muthukrishnan. “An Improved Data Stream Summary: The Count-Min Sketch and Its Applications,” Journal of Algorithms & Computational Technology Vol. 55, No.1, pp. 58–75, 2005.
[2] Estan, Cristian, and George Varghese. “New Directions in Traffic Measurement and Accounting,” In Proceedings of the Conference on Applications, Technologies, Architectures, and Protocols for Computer Communications, SIGCOMM ’02. New York, NY, USA, pp. 323–36, 2002.
[3] Noga Alon, Nick Duffield, Carsten Lund, and Mikkel Thorup. "Estimating arbitrary subset sums with few probes," In Proceedings of the twenty-fourth ACM SIGMOD-SIGACT-SIGART symposium on Principles of database systems (PODS ’05). Association for Computing Machinery, New York, NY, USA, 317–325, 2005.
[4]機械学習のための特徴量エンジニアリング著 Alice Zheng, Amanda Casari，訳株式会社ホクソエム，株式会社オライラー・ジャパン，2019.

2019-04-13

SecHack365の参加記録

SecHack365

はじめに

SecHack365に参加して1年が経ち、なんとか無事に修了することができました。軽い気持ちで受けたこのイベントでしたが、自分にとっては人生が一変するような刺激的な経験となりました。この場を用意してくださった全ての方々に対し感謝の念に堪えません。

sechack365.nict.go.jp

この記事では、SecHack365を通して学んだことについて，個人的な視点で書いていきます．とりとめのないトピックがつらつらと並んで大変恐縮ですが，少しでも次回以降参加される方に貢献できるならば幸いです．

応募時の気持ち

SecHack365というイベントを知ったきっかけは，Twitterでふと見つけたネット記事がでした．セキュリティ関連の研究をしていたので，NONSTOPを利用してみたいし（最終的に使いませんでしたが），第一線で活躍される研究者に指導されてみたいと思い応募を決めました．

アルバイトの時間が迫る中，締め切りギリギリまで課題を埋めた覚えがあります．非常に失礼な話なのですが，開発ができるわけではないし深い洞察が出来るわけでもないし…という消極的理由で表現駆動コースを選択しました．結果としてこのコースが一番自分に合っていたかなと感じ，選んでよかったと思いました．

応募に際して，学生の場合は担当教員との相談が必須であるとされていますが，自分は担当教員に特に相談せずに応募していまいました．自分の担当教員はこうしたイベントへの参加を好意的にとらえてくださる方だったための行動だったのですが，特にB4やM2は卒論・修論と被るので，いい顔をしない先生もいるかもしれません．なので，相談は必要そうだと感じました．

受かると思っていなかったので，電話で合格した旨を伝えられた際には嬉しさのあまり研究室でひとり棒立ちしていました．あふれる嬉しさをTwitter上でも表明したところ，経験のない「いいね」爆撃が発生し，何事かとTwitterを開くと，他のSecHack365参加者の方々にフォローされていました．

このときフォローしてくださった方のbio欄のすごさに自分は目を疑いました．スペシャリスト系の試験めっちゃ受かってるし，めっちゃ勉強会行ってるし，めっちゃ技術のこと詳しそうだし，「なんかやばいところに参加することになったな…」と戦々恐々としてしまいました．

表現駆動コース

自分は表現駆動コースに応募したと書いたのですが，本コースではとにかくアウトプットというか，まさしく「表現」を求められた印象です．

前半のオフライン回でのコースワークでは，自分のアイディアを発表してコメントをいただく活動が多かったです．自分で口に出したり，他の人からの指摘を受けたりすることによって，深く考えなおし，必然的に毎日自分の考えを磨いていくことになりました．

また，オフライン回では，Night Challengeという1-day（夕方から翌日の朝にかけてなので半日かも）のハッカソンが開催され，成果をプレゼン形式で発表しました．表現駆動コース内のトレーニーでランダムにチーム分けをして，テーマに沿ったプログラムを作ったり，将来のビジョンを提示したりしました．

これら二つの活動は，長期的な頭の使い方と，短期的な頭の使い方をそれぞれ学んでほしいという意図であったようで，非常に良い経験になりました．言われてみると頭の燃える箇所がそれぞれ違っていたようにも思えてきました．

チーム開発

SecHack365では，4人チームを組み，「プライバシーに配慮したTwitterクライアント “PEACE” 〜安心・安全なSNSを目指して〜」という作品名でデスクトップのTwitterクライアントを作成しました。ちなみに、PEACEとは"Privacy Enhanced Alternative Client for Education"の頭字語です。

本来応募時ではそれぞれ別のことをやっていたのですが，テーマが近かったり，興味があったり，といった動機で最終的に4人チームとなりました．2018年度のSecHack365では一番多い人数でした．

大体半分頃にチームが確定してから，週に1回，2時間程度のミーティングを行うようになりました．最終的に24回までしたので48時間くらいは話し合いました．重要な発表の前日にはほぼ毎回朝4時くらいまで作業したのを考えればもう少しいくかもしれません．忙しさにかまけて話し合いをしなかったら最終的によく分からない着地点に到達することはなんとなく想像できたので，ここを徹底することが出来てよかったです．

24回分のミーティングで，サービス開発や発表方法などを議論しましたが，そこまで掘り下げるかというところまで議論を掘り下げていったりもして，この点に関しては他のどのプロジェクトよりも考え抜いたのではないかという自負があります．

チーム開発ということで，Gitを利用してコードを管理していたのですが，自分は利用したことがなかったので苦労しました．根気よく教えてくれたチームメンバには感謝しかありません．

チーム開発で良かった点は，誰かが忙しい時に他の人がカバーできる点，機能を分担できるので最終的に開発物の規模感が大きくなりやすい点，より多くの人のチェックの目を通ることで発表資料のクオリティが上がりやすい点かなと思いました．

逆に欠点としては，個人でやるよりも意思決定が遅くなる点と，意思の共有に時間を費やしがちな点でした．気を付けないと何かと行動が遅くなる危惧があります．

チームでの議論を経て，いくつか反省したことがあります．一つは，自分が口頭で説明するのがめちゃくちゃ下手くそだったことです．話し言葉の語彙が貧弱な自分はすぐに「なんか」とか「あれ」とかで濁してしまうので，なかなか他の人に共有できずに申し訳なかったです．他のチームメンバはまさにドンピシャな表現で伝えてくださったので，議論するには議論の技術がいるなと思いました．

もう一つは，思うよりも論理の綻びに対して鈍感であったという点です．発表資料を作成する際に，気を付けないとすぐに良く分からない方向に進んでしまっていたので，チームメンバにその都度指摘していただいてなんとか形になる発表をすることができました．論理に対する美意識を常に持っておきたいです．

色々と思うところを書いてきましたが，チーム開発は本当に楽しくて，チームメンバの雰囲気も最後まで良かった気がします．考えの違う人同士でやるのでどうしても多少はピリつくこともありましたが，まさにこれこそ遅れてきた青春という経験でした．

開発能力の成長

成果物はVue.jsとPythonで作ったのですが，自分は授業で習ったC言語とJavascirptくらいしか書いたことがなかったので大変でした．

開発を進めていくうえで「REST APIって何？」「Node.jsとは？」と次から次へと疑問が出てくるありさまだったのですが，チームメンバの方々にも恵まれてどうにか乗り越えることができました．

今となってはこれらについてもある程度理解できたので，レベルとしては高くないとは思いますが，去年の自分に比べれば成長できたと言ってもよいのではないでしょうか．知らないことを知ることができて本当によかったです．

トレーニーとトレーナーの方々

最初のオフライン回でトレーニーの方々と対面したとき，オーラの違いというか，レベルの高さに愕然としました．同世代でこんなにもういわゆる天才エンジニアとしてバリバリやっている方がいるのかと，自分の見てきた世界の狭さを痛感したところでした．

実力的に，自分はどう贔屓目に見積もってもダメダメ村のダメダメ住人でしたが，それでも優しく接していただいて安心しました．自分の優秀さを鼻にかけることなく，ただひたすらに技術に誠実な方々ばかりでした．

トレーナーの方々にも本当に暖かく迎えていただきました．軍隊の教育を覚悟して臨んだ初回だったので，ほっとしたのを覚えています．

トレーナーの方はとにかくどんな話でも真剣に耳を傾けてくださいました．おそらくは日常に出すには憚られるようなエモも受け入れてくれて，すぐにポエムを吐き出してしまう自分にとっても精神的に過ごしやすい環境でした．

また，ただでさえ本業がお忙しいにも関わらず我々トレーニーに対し親身に接してくださいました．SecHack365ではプロジェクトとしてチームが固まり始めると，そのプロジェクトの担当トレーナーがつくようになるのですが，自分の場合は表現駆動，開発駆動，思索駆動のトレーナー陣が担当者になり，非常に多くの方にお世話になりました．特に週一のミーティングには遅い時間帯にも関わらず参加していただき，自分の生活を削ってまでサポートしてくださる姿に感動いたしました．若者のために命をかけられるような大人に自分もなりたいです．

習慣化とアウトプット

2018年のSecHack365では「習慣化」と「アウトプット」を特に意識してご講演されていたような感じがしました．

SecHack365オフライン会の初日にはマンダラートを埋めて自分がやるべき行動を分析し，それらを習慣化できるように各回でフォローアップされていました．

このブログも「勉強した成果をアウトプットする」の習慣化の一環として設立したものになります．

ブログ記事の投稿履歴を見れば一目瞭然だと思いますが，正直なところ今年は習慣化はうまくいきませんでした。2019年度はひと月に1回は更新したい…

もうひとつの柱としてアウトプットの重要性がよく語られました。SecHack365ではオフライン回がアウトプットの役割を持っており，ショットガンセッション，面談，ポスター，プレゼンと多様な形式で発表を行いました．

アウトプットに関わることでとても印象に残ったのは，トレーナーの方の「アウトプットはデバッグだ」という言葉です．アウトプットというと，とにかく批判に晒されるし，めちゃ怖いし…という印象だったのですが，単にエラーを潰すために行うものなのだと思うようになりました．考えてみれば当然のことなのですが，この言葉を聞いたおかげで，「うまくいくかな～」と軽くEnterキーを押すくらいの気持ちでアウトプットができるようになりました．

忙しさ

正直なところ，かなり忙しくなりました．自分は修士論文がなかなかうまくいかなかったこともあって，両方の成果が求められてくる11月から2月にかけては本当に精神が参ってしまい，幾度と体調不良に陥ってしまいました．

あまり良い印象を与えない物言いになりましたが，二足の草鞋を自らの意思で履いたのだから至極当然なことで，SecHack365が悪いのだということはもちろんありません．

念のためですが，SecHack365では習慣化が大事だということをモットーにされていて，とにかく無理をせずコツコツとやりましょうということを何度もお話しされていましたので，コツコツやらないとしわ寄せが来るという単純な話なのかもしれません．

最終的に優秀修了生という栄誉ある称号をいただき，これらの苦労は報われました．ただ，報われなかったにしてもここで得た苦労は一生ものの宝であると考えていたことと思います．苦しむことを分かっていても，参加することに意義はあったと感じました．

ところで，いつの時期にSecHack365を受けるべきかという話があるのですが，正直いつの時期に受けても忙しいのは忙しいし，つらいのはつらいので，自分としてはそこはあまり考えなくても良いのではないかと思いました．ただ，修士一年の人は授業や就活が被ってかなり厳しそうだったので注意が必要そうでした．

まとめ

自分は正直なところ意識の高い人間ではありませんでした．ほんの少しの努力で評価されるような，自分にとってコスパの良い世界に進んで身を投じ，ぬるま湯でゆったりとした世界にいたいような人間でした．

しかし，SecHack365に参加して，人生観がガラッと変わりました．できないと思うことも少しづつやっていこうと思えるようになりましたし、もしかしたら自分も世の中を変えられるような人材なのかもしれないと，端から抱きようもない根拠のない自信感も身に付きました．この自信感を持ってたくさん失敗してたくさん成功して，やがて行動に裏付けされた自信に変えていきたいです．

最終回では、今後は君たちのSecHack365が始まるのだという言葉で激励されました．修了は単なる第一歩で，これからまさしく365日，誠実に研鑽していくことで，いずれセキュリティイノベーターの入り口が見えてくるのだろうと思いました．自分はまだまだ半人前ですが，ちょっとずつでも頑張っていこうと思います．

あまり関係の無い個人的感傷

つい先日，自分の敬愛してやまないミュージシャンであるwowakaさんが永眠されました．

究極の個人的感傷で本当に申し訳ないのですが，自分が修士論文とSecHack365で苦しんだ時期に発表された楽曲である『ポラリス』に心の底から救われたため，たとえどれだけ本記事の意図に沿わない内容だとしても，どうしても書かずにはいられませんでした．

www.youtube.com

自分としては，この曲の伝える内容は，SecHack365を通してセキュリティイノベーターという修羅の道に足を踏み入れる方々にとっても決して無縁ではないと思ったので，最後のサビの歌詞を紹介させていただき，本記事の締めとさせていただきます．

ひとりきりのこの道も　覚めない夢の行く先も
誰も知らぬ明日へ行け　誰も止められやしないよ

また一歩足を踏み出して
あなたはとても強いから
誰も居ない道を行ける
誰も居ない道を行ける

2019-02-26

DDoS攻撃の背景が知りたい（Webstresser編 2/2）

DDoS

前回は、Webstresserの仕様を調べましたが、実際Webstresserでどのような攻撃が行われるのかを調べてみます。知らない攻撃も多かったのでためになりました。

今回もまたYouTubeを探し回って、今度は攻撃リストを見てみます。（Webstresserのページが凍結されているため。ちなみにページのキャッシュって今でも残ってるんでしょうか。恥ずかしながら初心者なので見方が分かりません…）

www.youtube.com

聞いたことがあるのは、DNS Amplification攻撃、NTP Amplification攻撃、TCP-ACK、TCP-SYNなど。動画を見る限りSlow DDoS系は無さそう？

とりあえず聞いたことのない攻撃について表面的だけでも浚ってみました。

Webstresserで提供されていた攻撃

CHARGEN

It's an UDP based method whivh uses chargen service to amplify and reflect the attavk to the targeted IP address.

知識が無いのでCHARGENというプロトコルを知りませんでした。以下のRFCを読んでお勉強。単純に試験用に文字を送信するだけのプロトコルのよう。3分程度で読み終わりましたが、英語RFC読破実績解除してよいのか悩みます。

tools.ietf.org

一応DoS攻撃も確認されているようですが、文面的にも主流的にもAmplification攻撃の方ですかね。

www.npa.go.jp

Amplification Factorは358.8 。結構大きいような気がするんですが、CHARGENを解放したままにしているサービスは少なそうなので使われるイメージがあまり湧かないです。

www.us-cert.gov

ちなみに、2019/02/25現在にDDoS Monを確認したところでは19番ポートは見つからなかったです。

ddosmon.net

DOMINATE

攻撃名が汎用的であることもあって鬼のように関連文献を見つけられませんでした。関連がありそうなのは以下の2件。

asert.arbornetworks.com

DOMINATE is a newer (since January 2015) layer four flooding technique that has been advertised as a method to attack protected services by sending traffic to the actual IP addresses of those protected servers. Analysis of this attack method in the underground suggests that it is a modified version of a spoofed SYN flooding script (ESSYN) that adds the capability to use different TCP flags.

blog.ddos-guard.ir

Dominate Method Attack is a New method of DDoS Attack on Layer4 of Network. the method is able to drop servers from ddos protected networks such as OVH, Voxility by bypassing their firewall and sending the attack straight to the server itself, therefore causing it crash completely.

これだけだとSYN Flood攻撃の亜種感があるんですが、TCP Flagを色々と変えるのは何の目的でやっているのかがいまいち良く分からない。シグネチャ回避とかそのくらいなのだろうか。

"The attack code is the hype" (誇大広告)と言われているので、攻撃者にとってあまり効果が無いと認識されている攻撃っぽいですね。

COD

Its on UDP based method which can take down even highly protected Call of Duty servers.

何だろうと読んでみたらまさかのゲームタイトル。Call of Dutyサーバ専用の攻撃なんてあるのか…。最近FF14がDDoS攻撃を受けていると聞きましたがBoosterにゲーム専用の攻撃が用意されていたりするのでしょうか。

PORTMAP

Amplification攻撃の一種。おそらくmemcachedくらい有名なんだと思いますが、2015年時点ではあまりセキュリティの勉強をしていなかったので知らなかったです。NFS (Network File System)で用いられるUNIX系のデーモンかな？ Amplification Factorは7から28。

scan.netsecurity.ne.jp

VOX

It's an UDP based method which is best used for downing highly protected servers.

名前で調べてみたんですが、詳細が不明。こちらのページや他の箇所でDDoS攻撃防御の企業としてVoxilityという名前がよく取り沙汰されているんですが、"highly protected servers"を見るに、Voxilityのサービスを利用している組織に対してこの攻撃を利用するということでしょうか。

www.voxility.com

Teamspeak 3

これも調べてみたらボイスチャット系のサービス名でした。もしかしてゲームをやる人には有名だったりするのかな。

このサービスに特化した攻撃だそうです。Discordに向けたDDoS攻撃もあるのかな？

もう一つkillモードの攻撃が用意されてあって、この場合はすべてのポートに対して攻撃を行うそうです。

VSE

Our custom made VSE which is based on the already well known valve source engine method. Our method should be about 20-90% more effective (depends on the targeted host) than the public versions.

Valve Source Engineというゲームエンジンに関連した攻撃。

以下の文献では、TSource Engine Queryを大量にゲーミングサーバに送信する攻撃であると説明されていました。ゲームエンジンはUnityしか知らないんですが、オンラインサーバもゲームエンジンで作るのだろうか。それとも、Minecraftみたいにサーバ建てます的な話なのかもしれない。もしかしたら、ゲームエンジンで作ったクライアントで攻撃するのかな。

（追記 2019/3/24 ）Valve社のSteam用サーバに対する攻撃とのことです[1]。PCゲームはまったくやらないので全然ピンと来てませんでした。

[1] Manos Antonakakis and Tim April and Michael Bailey and Matt Bernhard and Elie Bursztein and Jaime Cochran and Zakir Durumeric and J. Alex Halderman and Luca Invernizzi and Michalis Kallitsis and Deepak Kumar and Chaz Lever and Zane Ma and Joshua Mason and Damian Menscher and Chad Seaman and Nick Sullivan and Kurt Thomas and Yi Zhou, "Understanding the Mirai Botnet", USENIX Security Symposium, 2017.

調べてみると、Valve source engine flood攻撃という種類でMiraiの機能の一つとして実装されているようです。Webstressorの説明文に載っている"public versions"はMiraiやその亜種を指しているのかなぁ。

hothardware.com

https://www.janog.gr.jp/meeting/janog39/application/files/1514/8454/4304/JANOG39-dyn-simamura-01.pdf

https://www.joho-shimane.or.jp/files/original/201612121543425454713.pdf

まとめ

いかがでしたか？　と言わんばかりの何の結論もない内容ですが、備忘録として。らしい / ようです Flooding攻撃が行われています。

調べてみると、よく利用されるサービス、特にゲームに向けたDDoS攻撃が多く搭載されているようで、オンラインゲームの人口ってかなり多いんだろうなぁという印象。

今後は別のブースターなり、Miraiのソースコードなりをちまちま読んでいきたい。

2018-09-30

DDoS攻撃の背景を知りたい（Webstresser編 1/2）

DDoS

　この頃、DDoS攻撃の攻撃者側と被害者側双方のコストの実情が知りたくて色々と調べていました。今回は攻撃者側のコストとして、今年話題となったWebstresserを調べてみることにしました。（タイトルが「1/?」となっているのはどのくらい増えるか分からないためです）

概要

　Webstresserは2018年の4月にユーロポールに摘発されたDDoS攻撃代行サービスです。名前から明らかなように名目上はWebストレスの診断としてサービスを展開していたようです。

www.europol.europa.eu

　4月時点で136,000のユーザが登録しており、400万件の攻撃が観測されていたとのことです。すでにこのWebサイトはユーロポーロのオペレーションPowerOFFの一環によって差し押さえられています（下図）。これはもちろん正しい対応なのですが、自分のように今の時期にふと実態を調べようと思った人間にとっては由々しき事態です。

f:id:madomadox:20180716185116p:plain — 現在サービスにアクセスしようとするとこの画面が出てきます。かっこよい…。

　いろいろ検索していると、摘発以前に調査を行った方や、キャッシュが残っているうちに調査を行っていた方がいらっしゃったので参考文献に示した記事を基にいろいろ調査させていただきました。

www.orangeitems.com

www.forbes.com

securitytrails.com

サービス紹介

サービスとして以下を謳っていた模様です。(意訳多し)

レイヤー4, レイヤー7の「ストレステスト」を提供
DNS増幅攻撃、SYN Flood攻撃、HTTP Flood攻撃など複数の攻撃をサポート
最大で350Gbpsの攻撃を提供
24時間年中無休のカスタマーサポート
利用用途に応じてランクをご用意
PaypalやBitcoinでお支払い（Bitcoinであれば15%割引）
トラフィックはSSLで暗号化しているので安心

ちなみに、ランクとしては以下があります。

ブロンズ(Bronze)

値段：$18.99/月
有効期限：1カ月
最大攻撃期間：1,200秒

シルバー(Silver)

値段：$28.99/月
有効期限：1カ月
最大攻撃期間：3,000秒

プラチナ(Platinum)

値段：$49.99/月
有効期限：1カ月
最大攻撃期間：7,200秒

生涯ブロンズ(Lifetime Bronze)

値段：$120.00/月
有効期限：999年
最大攻撃期間：1,500秒

www.youtube.com

※値段は以上の動画を参照。他にも用途に応じたプランを用意していた模様です。

ユーロポーロの示している最低15ユーロとはブロンズの料金でしょうか？18.99ドルを2018年4月24日時点のレート（×0.82）で換算してみたところ、15.57ユーロとなったので恐らくこれで合っているかな？と思います（15%0ffは適用外？）

また、

私たちはオンラインでのPaypalの巨大な可能性を信じています。多くの他のIP Stresser / Booterは、彼らが顧客をだましているので、Paypalを有効にしていません。(Operation Power Off（パワーオフ作戦）によるwebstresser.orgの摘発の件を調べた - orangeitems’s diaryより引用)

という話がWebstresser.org上であるようですが、信用を勝ち取るための話なのかもしれないですね。Paypalでは買い手保護制度により商品が正しく利用できない場合に返金が保証されるようです。

www.paypal.com

「彼らが顧客を騙しているので」の例は以下にありました。攻撃するにもリテラシーが必要らしいです。

まず初めに、おそらくは誰もが想像するように、サービスプロバイダの多くは、代金を騙し取るだけで、実際には何の攻撃も開始されないものでした。(https://www.watchguard.co.jp/security-news/black-hat-2016-%E3%81%A7%E3%81%AE%E3%83%97%E3%83%AC%E3%82%BC%E3%83%B3%E3%83%86%E3%83%BC%E3%82%B7%E3%83%A7%E3%83%B3%E3%81%AE%E3%81%94%E7%B4%B9%E4%BB%8B-ddos-as-a-service-%E3%81%AE%E7%A0%94.htmlより引用)

おわりに

今後は具体的にどんな攻撃を用意していたかを調査してみようと思います。

こうしたサービスを調査する際、YouTubeって結構情報が多いですね。

2018-06-10

SecHack365に合格しました

SecHack365

はじめまして、まどと申します。この度、SecHack365に合格したということをきっかけにブログを開設することにしました。今回は応募に至った経緯を書き記そうと思っています。

前述の通り、私はSecHack365に何の幸運か合格することができました。これは国立研究開発法人情報通信研究機構さんが主導で行っている長期のハッカソンで、25歳までの学生や社会人を対象に公募を行い、第一線で活躍されている素敵なトレーナーの方々のお力添えをいただきながら、サイバーセキュリティに関わるモノづくりを行っていくセキュリティイノベーター育成プログラムです。

sechack365.nict.go.jp

参加に至った経緯

実は私は今年のネットでの紹介記事を見るまではSecHack365のことは存じていませんでした。軽い気持ちで記事を読んでいると「学生は50万の参加費が無料」という文章に目が釘付けになりました。自分は陸の孤島と称される田舎に住んでいるため、移動費という点がネックでこうしたイベントは今まで諦めていたのですが、無料だったらワンチャンあるなということでとりあえず応募して課題を見てみました。

規則上どんな課題が出たのかを説明することはできませんが、けっこう難しそうというか、時間がかかりそうな課題が出ていて、さっそく心が折れました。

「移動費がネックでこうしたイベントを諦めてきた」とイキってみたのですが、どちらかというと諦めてきた理由としては「課題にビビった」という理由の方が大きなものでした（セキュリティキャンプも一度参加してみようと課題を見てみたのですが、なんか別次元だなと思って諦めた経験があります）

ただ、現在の年齢を考えるとこれが最後のチャンスだと思い、心を入れ替えて頑張ろうという気持ちが沸々と湧いて、SecHack365に応募することを決心しました。実際にはギリギリまで踏ん切りがつかず、提出日当日に課題に取り組み始め、書きながら何度も「やっぱやめるか…」「いやどうせダメで元々だし…」と気持ちが揺れつつ、公式の方からのまずは応募しないと始まらないというメッセージにも勇気づけられ、なんとか書き上げることができました。

合否の連絡は電話で行うという旨が公式Twitterに記載されていたのですが、自分はそれを知らなかったので電話をすぐに取ることができませんでした。30分ほど遅れて電話があったことに気づいた私は急いで折り返しそこで合格の旨を告げていただきました。まさかあんな状態で応募した自分が受かるとは夢にも思っていなかったのでかなり驚きました。

結論

実際に参加してみるとプロの方が多く、大変萎縮してしまったのですが、自分のできるところから、そのドメインをじわじわとでも伸ばしていけるように努力をしているところです。

ここまで課題に対する不誠実だった部分を書き並べてしまうのは落選してしまった方に対する侮辱にあたりそうで非常に悩んだのですが、来年度もしかしたら私と同じように直前で諦めてかけてしまう人がいるかもしれないと考えて書き残しておくことにしました。

来年度SecHack365の参加を迷った方がメッセージ検索でこの記事を見つけ、もしかしたらいけるかもと安心したり、こうはなるまいと反面教師にしたりすることを願い、筆を置きます。