DDoS攻撃(SYN/ACK Reflection攻撃)の仕組み(転載)


Masafumi Negishi retweeted: 「IIJのSOCアナリストが検知と分析のサイクルを回すわけ DDos攻撃検知にAIを選ばなかった理由」 logmi.jp/tech/articles/… 昨年9月開催のIIJ Technical NIGHT vol.9で登壇した #セキュリティ 本部 守田 瞬の講演がログミーの記事になりました。 全2回で、後半はDDos攻撃の観測方法について紹介。:
Masafumi Negishi retweeted:
「IIJのSOCアナリストが検知と分析のサイクルを回すわけ DDos攻撃検知にAIを選ばなかった理由」
logmi.jp/tech/articles/…
昨年9月開催のIIJ Technical NIGHT vol.9で登壇した #セキュリティ 本部 守田 瞬の講演がログミーの記事になりました。
全2回で、後半はDDos攻撃の観測方法について紹介。

SYN/ACK Reflection攻撃はTCPの3wayハンドシェイクを悪用したものになります。リフレクション型の攻撃なので登場人物は3人。攻撃者とリフレクターと、被害者にあたる攻撃対象です。

攻撃者は何をするかというと、3wayハンドシェイクをしようと試みます。SYNパケットの送信元はIPスプーリングになるんですが、これは攻撃するサーバーのIPアドレスとか、ルーターだったら、そのルーターだったりとかに偽装されています。

リフレクターは、送信元が偽装されたSYNパケットが悪性かどうかというのは基本的に判断できないので、3wayハンドシェイクのルールに則って、素直にそのSYN/ACKパケットを偽装されたIPアドレス宛に応答として返送します。

攻撃者がスプーフしたSYNパケットをリフレクターに送ることで、スプーフされたサーバーやルーターにSYN/ACKパケットが集中してしまうというのが、DDoS攻撃の原理になっています。量が多いとDDoS攻撃が成立しちゃうよね、というのが脅威のポイントです。

当時、攻撃者はボットネットなのか攻撃ツールなのかわからないところから、実際はリフレクターなので裏にサーバーがいるんですが、我々のお客さまのファイアウォールを通過するように、SYNパケットを投げつけてきました。先ほども言った通り、SYNパケットは攻撃対象側の宛先にスプーリングされているんですが、リフレクターはSYNパケットが悪性かどうかを判断することはできません。

なので、素直に被害者側にSYN/ACKパケットを応答していたという事象を我々は1年半前ぐらいに観測しました。ファイアウォールを通過しているので、ログは情報分析基盤のデータベースに集約されています。情報分析基盤から分析をすることで、この事象を発見したというのが、スタートになります。


2019年は、ひどいときには日に数件(通知が)上がっていたんですが、どんどん観測が増えてきて早く検知を自動化したいなということで、検知コードを情報分析基盤に仕込みました。こうすること自分が能動的に「今日はSYN/ACK Reflection攻撃あったかな?」と探さずに済むような仕組みが整ったわけです。

そうすることでこの図の通り、それ以降SYN/ACK Reflection攻撃されると自動的にログが情報分析基盤に集約されて、検知コードが反応すれば私に通知が来るようになりました。通知が来たら詳細な分析を行います。

もちろん、誤検知もたまにはあるので、しっかり調査していきながら、裏付けができたものに関してはみなさんのところに(情報が)届くようにwizSafe Security Signalで紹介しています。ブログを書いているだけではなくて、裏ではこういった検知ロジックも考えながら、調査もしながらやっていたというのが実はの話です。