2021年12月31日金曜日

セキュリティ・ミニキャンプオンライン2021 参加記 ~内容編2:マルウェアのトラフィックを分析・検知してみよう~

ミニキャンプオンライン2021「マルウェアのトラフィックを分析・検知してみよう」の募集課題、事前課題、講義、修了試験についての記事です。

他講義リンク

 

マルウェアのトラフィックを分析・検知してみよう

マルウェア検知システム(IDS)の中で、今回はネットワーク型(NIDS)を取り扱った講義でした。こちらも事前課題はありませんでした。

自分はこの分野はほぼ触ったことが無く、0からのスタートでしたが、事前知識も説明して頂けたお陰で無事進めることが出来ました。また、機械学習を利用した検知という現代な対応も知れて良い講義でした。

募集課題

配布されたpcapファイルをフロー形式に変換し、

  •  パケット数、フロー数などのエントリ数
  • 変化があった場合、その条件
  • フローの観測時間とエントリの出力順
  • L3プロトコル(UDP/TCP)による出力の違い
  • その他気づいたこと

 について考察するという問題でした。ミニキャンプオンライン概要ページ(https://www.security-camp.or.jp/minicamp/online2021.html)募集要項の問題2にあたります。

自分は応募時、この問題は選択しませんでしたが、修了後に軽く解いてみたのを以下に記述します。

Zeekのインストール

Zeek(https://zeek.org/)はLinux環境でしか動かないようなので、その環境を用意してください。自分はWSL2のUbuntu 20.04を利用しました。

その後、好きな方法でインストールしていいのですが、aptでインストールした場合だと/opt/zeek/binにパスを通してくれないため、手動で行う必要がありました。

Binary Packages(https://github.com/zeek/zeek/wiki/Binary-Packages)のページをみると恐らく他のインストール方法でも同様だと思われます。ご注意ください。

フロー形式への変換

pcapがあるディレクトリに移り、

zeek -r <pcapファイル>

と実行することで変換できます。ディレクトリのconn.logが当たります。

考察

パケット数、フロー数などのエントリ数

まず、変換したところフローのエントリは6つになりました。パケット数は送り元からのパケットが合計13、送り先からのパケットが10、合計23となりました。pcapファイルをそのままWiresharkで開いても23なので正しく変換されていると考えられます。

エントリ数がパケット数よりフロー数で減ったのは、TCPの3ウェイハンドシェイクがまとめられたためだと考えられます。(参考:https://docs.zeek.org/en/master/logs/conn.html)

フローの観測時間とエントリの出力順

自分が変換したものでは一部時系列に並んでいませんでした。この理由としては、時系列では「DNSの通信→UDP送信→TCP通信」となっているのですが、一度RSTが返ってきてしまっていて、TCP通信が後にまとまっているために時系列がズレてしまったと考えます。正直わかんないです…

L3プロトコル(UDP/TCP)による出力の違い

historyフィールドでUDPだとD、TCPだとSが先頭に来るのに気が付きました。これの理由はDは送り元からのデータパケットを指していて、Sが送り元のSYNパケットを指しているからだとわかりました。


全体を通して、この募集課題を行っていれば、Zeekのフィールドについて理解が深まり、講義で行った機械学習の演習に役立ったな…ってなりました。

講義

講義は大きく

  • マルウェアトラフィック検知の事前知識
  • Snortを使った演習
  • 機械学習を利用した検知
の 3つのセクションに分かれていました。

マルウェアトラフィック検知の事前知識

まず、マルウェア「ユーザやシステム」に対して意図しない動作を行うコードやソフトウェアを指していて、「トロイの木馬」、「ボット」、「ワーム」といったタイプによる分類、「DDoS」や「ポートスキャン」といった動作による分類、利用する権限等で分類することができます。

マルウェア検知システムは検知方法検知場所で分類することができます。

検知方法には、定義ファイルなどのルールに一致するかで検知するシグネチャベース、大量の良性活動と悪性活動からルールを学習し検知する機械学習ベースなどで分類が行えます。

検知場所は、PC等の端末で動き、プロセス情報等を利用して検知するホスト型、ネットワークの中間に設置し、トラフィックパターンを利用して検知するネットワーク型で分類が行えます。

今回利用したSnortはシグネチャベースの検知を行うネットワーク型のシステムとなっており、後半ではネットワーク型のシステムで機械学習ベースの検知を行う実習を行いました。

Snortを使った演習

今回は実際にルールを記述し、アラートが上がることを確認しました。

Snortのルールは

alert icmp any -> 192.168.1.xxx any (msg: "ICMP detected"; sid: 10001)

のように記述し、/etc/snort/rules以下に保存します。構造は

<action> <protocol> <送信元IP> <ポート番号> -> <宛先IP> <ポート番号> (options)

となっています。

actionには

  • alert:アラート出力、パケット内容記録
  • log:パケット内容記録
  • pass:パケット通過
  • activate:アラート出力、dynamicの処理実行
  • dynamic:指定された処理を実行
を指定することができ、protocolは
  • tcp
  • udp
  • icmp
  • ip

を指定することができます。

optionsでは

  • msg:指定された文字列をアラートまたはログに出力。"(ダブルクォート)でくくる
  • flags:TCP制御フラグ。F(FIN)、S(SIN)、R(RST)、P(PSH)、A(ACK)、U(URG)で指定
  • sid:シグネチャID。99以下は予約。100-999,999は配布ルール用。1,000,000以上はユーザが定義できるルール

を指定できます。

したがって、ルールの例で示したものであれば

「192.168.1.xxx宛てのすべてのICMPパケットを受信したら"ICMP_detected"とアラートを出しパケットを記録する」

というルールとなっています。

alertファイルは/var/log/snort/alert以下に存在しcat等で見ることができ、logファイルは/var/log/snort/log以下に存在しtcpdumpで見ることができます。

機械学習を利用した検知

前節でSnortを利用した検知を説明しましたが、デメリットとして「未知の攻撃(悪性活動)に対応できない」というものがあげられます。そこで既知の悪性活動と良性活動データを機械学習にかけることでそのデメリットを補うことができます。

学習に利用する活動データは事前課題で扱ったようにZeekでフロー形式にして利用します。

ミニキャンプではその後フィールドや機械学習アルゴリズム等を変換し、評価・考察を行いました。

この際、自分は深く考えず「コネクション継続時間」や「データサイズ」で学習を回してしまったのですが、学習が終わらないまま実習時間が過ぎてしまいました。終わった後に

の気づきを得ました。頭が弱い。

修了試験

修了試験は「示されたSnort定義ルールに反応するパケットを送信する」という問題になっており、そのルールが

alert udp any -> <競技サーバIP> <ポート> (content: "What is flag?";)

のようなものでした(記憶を辿ったものであり、細かい部分が違うかもです)。

パケット送信にはnetcatを利用し

$ netcat -u <競技サーバIP> <ポート>

->What is flag?

と入力することでフラグを得ることができました、やったね。



0 件のコメント:

コメントを投稿