機械学習を使わずにDDoS攻撃を観測
守田瞬氏（以下、守田）：次の事案は、これはまたちょっとマルウェアの通信とは違うんですが、DDoS攻撃の観測を2つ目の事例として紹介しようかなと思っています。このDDoS攻撃もいろいろ手法がありまして、SYN/ACK Reflection攻撃というのが今回の対象になります。
このあと簡単な概要図を出そうと思っているんですが、一旦説明します。このSYN/ACK Reflection攻撃とは何かというと、リフレクション型の攻撃の1つです。2018年や、特に2019年はけっこう観測していました。
特徴は、TCPの3wayハンドシェイクの悪用です。世の中インターネット上に広く開いているTCPのポートはWebサーバーとかで、80番とか443番のTCPが悪用されることがあります。これは正常通信に紛れてしまうリフレクション攻撃なので、単一のリフレクターを監視していても検知することがけっこう難しくなっています。
なので、我々みたいにいろいろなお客さまのファイアウォールのログを情報分析基盤に集約しているところが検知において優位性につながっていて、単一ではなくて、複数のリフレクターで監視をしているということも検知できる理由です。
検知ロジックなんですが、今回「AI」と言っていますが、実はAIを使っていません。これはあとでお話しするんですが、検知技術としては可視化と分析による検知ロジックの定式化で、私自身が数式をいろいろ考えて、定式化したロジックで検知をさせています。今回なぜ機械学習を使わなかったかというポイントが、下に書いてあります。
DDos攻撃検知に機械学習を選ばなかった理由
SYN/ACK Reflection攻撃は、2002年に一度あったみたいなんですが、そこからパタッと目立っていませんでした。それが2018年や2019年ぐらいから、チラチラと見え始めてきました。
機械学習を行う上では、データがポイントになるんですが、（SYN/ACK Reflection攻撃の事例が少ないために）教師として存在するデータがなかったというのが機械学習を選べなかったポイントの1つです。あとは、当時観測事例が1日数件の頻度でガンガン見つかっていたので、頻度と合わせて自動的に検知する仕組みを早く作りたかったという気持ちとしてあったので、定式化しました。
分析者として活動しながら、セキュリティ事案の対応をするので、どちらをベースに活動していくかがけっこう難しかったです。データ分析をやっている中で、事案を見つけてしまうとその事案調査をしなければいけなかったので、常にデータ分析をやっているという感じでは実はないんですね。
ただ、事案を見つけたらできるだけ早く傾向をつかんで、自動化するというのはポイントの1つになると思います。なので、AIを使うか別の手法を使うかというポイントは人それぞれだと思うんですが、機械学習を使う上では、そこを判断するというところが重要なポイントの1つになると思います。
SYN/ACK Reflection攻撃の仕組み
こちらはSYN/ACK Reflection攻撃の概要です。先ほど字面でつらつら言っていたんですが、初耳の人も多いかなと思ったので、ちょっと図にして表してみました。先ほど申し上げた通り、このSYN/ACK Reflection攻撃はTCPの3wayハンドシェイクを悪用したものになります。リフレクション型の攻撃なので登場人物は3人。攻撃者とリフレクターと、被害者にあたる攻撃対象です。
攻撃者は何をするかというと、3wayハンドシェイクをしようと試みます。SYNパケットの送信元はIPスプーリングになるんですが、これは攻撃するサーバーのIPアドレスとか、ルーターだったら、そのルーターだったりとかに偽装されています。
リフレクターは、送信元が偽装されたSYNパケットが悪性かどうかというのは基本的に判断できないので、3wayハンドシェイクのルールに則って、素直にそのSYN/ACKパケットを偽装されたIPアドレス宛に応答として返送します。
そうすることで左の図のような全体像が浮かび上がってきます。攻撃者がスプーフしたSYNパケットをリフレクターに送ることで、スプーフされたサーバーやルーターにSYN/ACKパケットが集中してしまうというのが、DDoS攻撃の原理になっています。量が多いとDDoS攻撃が成立しちゃうよね、というのが脅威のポイントです。
先ほど「定式化した」と言ったと思うんですが、数式を見てもちょっとわかりにくいかなと思ったので、SYN/ACK Reflection攻撃を検知して観測した内容をwizSafe Security Signalというブログの中で紹介しています。裏側に検知ロジックを作ったストーリーがあるんですが、今回はそこを簡単に、どういったことをやっていたのかを紹介できたらなと思って、このスライドを持ってきました。
通知内容を調査をしながら検知ロジックを考える日々
当時、攻撃者はボットネットなのか攻撃ツールなのかわからないところから、実際はリフレクターなので裏にサーバーがいるんですが、我々のお客さまのファイアウォールを通過するように、SYNパケットを投げつけてきました。先ほども言った通り、SYNパケットは攻撃対象側の宛先にスプーリングされているんですが、リフレクターはSYNパケットが悪性かどうかを判断することはできません。
なので、素直に被害者側にSYN/ACKパケットを応答していたという事象を我々は1年半前ぐらいに観測しました。ファイアウォールを通過しているので、ログは情報分析基盤のデータベースに集約されています。情報分析基盤から分析をすることで、この事象を発見したというのが、スタートになります。
2019年は、ひどいときには日に数件（通知が）上がっていたんですが、どんどん観測が増えてきて早く検知を自動化したいなということで、検知コードを情報分析基盤に仕込みました。こうすること自分が能動的に「今日はSYN/ACK Reflection攻撃あったかな？」と探さずに済むような仕組みが整ったわけです。
そうすることでこの図の通り、それ以降SYN/ACK Reflection攻撃されると自動的にログが情報分析基盤に集約されて、検知コードが反応すれば私に通知が来るようになりました。通知が来たら詳細な分析を行います。
もちろん、誤検知もたまにはあるので、しっかり調査していきながら、裏付けができたものに関してはみなさんのところに（情報が）届くようにwizSafe Security Signalで紹介しています。ブログを書いているだけではなくて、裏ではこういった検知ロジックも考えながら、調査もしながらやっていたというのが実はの話です。
SOCが提供するチャレンジングな環境
もうちょっと聞きたいなと思ったところもあるかと思うんですが、今日はここで最後にさせてもらいます。SOCだからできることを2つ書きました。これは私自身の視点なので、他の方だとまた違うできることがあるかもしれないですが、基本的に私はデータ分析者なので、データを分析しています。
SOC（Security Operation Center）の中でこういった多くのログを解析しているところがIIJ以外にあるかはちょっと疑問ではあるんですが、SOCの中でデータ分析をしつつ、セキュリティがイメージしているアプローチとは違うアプローチをすることで脅威を見つけている部隊です。なのでそういったところができることの1つかなと思っています。
他にはチャレンジングに活動ができますよというのがもう1つ言いたいことです。これは私自身、中途で入ってきて、セキュリティやネットワークとかの知識がない中でやってきたんですが、その中でもこういうことをやりたいんだというところをアピールしながら活動できているので、そういった意味ではチャレンジングに活動できているかなと思います。
最後にデータ分析の中でけっこう重要なポイントになるのはドメイン知識です。簡単に言うと、セキュリティやネットワークの知識ですが、セキュリティ機器の知識も案外必要になります。データ分析をやっていく中で、自然とドメイン知識も技術として習得できるので、そういった環境で仕事できているというのはすごくいいことだなと思っています。
ぜひ興味がある方は一緒に仕事したいですね、ということだけお伝えしておこうと思います。以上です。
