セキュリティ・キャンプ2025 ミニ（山梨）の講義準備

t6o_o6t.icon

仮想環境における DoS 攻撃演習の実現性を検証する

要件

DoS

SYN Flood / SYN Cookies

ボットネットによる方法

脆弱性のあるコンテナが必要

ボットネットの動作イメージを再現した環境・スクリプトが必要

RDDoS

Smurf

偽装先サーバーが多く必要

攻撃先で ICMP が提供されている必要がある

DNS Reflection

すでに実施している人がいた。

SYN Cookiesを無効にしたうえで、Backlogの値を調節すれば再現できそうかな..

Dockerネットワークでよいのか？

ひとまず、よいと考えたい。

1. 帯域制限や複雑なトポロジの設定を tc でやるのはあとあとつらくなってきそう。

とくに、DDoS 対策まで講義したいので、ASを区切ってBGPでルーティングできることは必須になる。

2. Dockerには慣れているので、演習環境の開発効率がよさそう。

ネットワークの疎通さえできれば、特定の仮想マシンにSSHログインするのもある程度容易だろう...

メモ

防御手法

CAPTCHA

Project Shield

FBI捜査官による講演

DDoS検知に関する手法の比較

Internet weekでの講演

DOTSプロトコルについて

RFC 3882「Configuring BGP to Block Denial-of-Service Attacks」

IP Spoofing - uRPF

RFC5635「Remote Triggered Black Hole Filtering with Unicast Reverse Path Forwarding (uRPF)」

RTBHの実装について

BGP / ASについて

Cloudflare の SYNパケットの処理（SYN Cookies の有効性について）

DDoS Tools

Layer3, 4

hping3

Real world のツールを使う必要があるのかは要検討。むしろわかりにくくなるのでは？

ボリューム型、プロトコル型に関しては、次のようなステップを作ってみるとよいかも

1. Raw Socketを使って生のパケットを送ってみる

2. 大量のパケットを送ってみる

3. 複数のスレッドで送ってみる

アプリケーション型（Slowlorisなど）は、今回は考えなくてもよいか...

実際、DoS攻撃の大半が SYN Flood などの L3 の手法というレポートがあったはず...

DoS /DDoS を仮想環境上で実験 & 原理を講義している資料

リスト

hping3

SYN Cookies の解説

DDoS as a Serviceの日本での事例の存在について考える

送出パケットの速度は tc で制御する。いちど送出されたパケットは即座に対向ホストに到達するので、40ms程度の遅延をかける。

containerlab ならネットワーク上の全インターフェースに一斉にかけられそう？

GitHub Codespacesでも動くみたいなので、一度試してみる

150分の使い方

プログラミングやLinux操作、パケットキャプチャなど、手を動かして堅牢化されていく様子がわかったほうがよいはず...

こういう技術的な部分も一種の目標として設計したほうがよさそう

防御手法の自由な考察

さまざまなAttack Surfaceを考えてみるという方向:

機械学習に対して敵対的学習、...

USENIXに、Amp DoSへのFuzzingに関するPaperがあった。

目標設定

Basic Theory

Raw SocketをPythonのsocketを使用して送出できる。

マルチスレッドプログラミングにより、複数のIO処理を並行して行える。

TCPのパケットキャプチャを行うことができる。

TCPの3ウェイハンドシェイクの流れを説明できる。

SYN Floodを、Raw Socketを用いて行い、その原因と結果を説明できる。また、Linuxにおいてどのように堅牢化するかを説明できる。

scapyを使用してIP Spoofing を行うことができ、その挙動を説明できる。

ICMPがどのような目的で使用されているのかを説明できる。IP Spoofingと合わせて、Smurf攻撃の仕組みを説明できる。

パケットをキャプチャし、不正なIPを探し出してファイアウォール設定で遮断できる。

Routing Security

ネットワークにおけるルーティングの役割を説明できる。

ルーティングテーブルを見て、パケットがどのインターフェースに流れるかを説明できる。

インターネットにおけるBGPの役割を説明できる。

BGPによってどのように経路情報が構築されるかを説明できる。

RTBHによるBlackhole Routingの一斉設定を説明、設定できる。

BGP Flowspecによる柔軟な設定を説明できる。

IoT Security

IoT機器の一般的な脆弱性について説明できる。

IoT機器を使ったボットネットによるDDoSの流れを説明できる。

バックドア、C2サーバの設置？

省略

Firewall などの実装: eBPFなどで実装するとして、その基礎の説明が必要

DNS Amp攻撃: DNSの仕組みの説明などをしていると、時間がかかりすぎる

CDN / IP Anycastによる負荷分散: CDNの説明に時間がかかる。また、演習の提供が難しい

Mitigation装置による緩和: 演習の提供が難しい

スクラビングセンター: 演習の提供が難しい

IDS・IPSによる検出・阻害: 演習の提供が難しい？

Slowloris: 可能であればやりたい...

その前に

受講者には、ネットワークに関する基礎知識を持ってほしい.

事前学習資料のようなものを用意できるとうれしいが...

Wiresharkなどが必要になりそうだったら、今のうちに...

containerlabに汎用のコンテナを置けるか？

構成

ボットネット

Theory

Penetrating

インターネットから脆弱なIoT機器に侵入する

バックドアを配置する

C2サーバへの通信を確立する

C2サーバから命令する

Defending

IoT機器の脆弱性をスキャンする

攻撃手法と防御

Basic Theory

TCP3ウェイハンドシェイクの概要

TCPパケットキャプチャ

ICMPの概要

Attacking

ScapyによるSYN Flood用パケットの送出

マルチスレッドによる効率化

IP Spoofingによる攻撃元の隠蔽

ScapyによるICMP用パケットの送出

Smurf攻撃の原理

Defending

全般：パケットキャプチャによる攻撃元の特定

ファイアウォールの設定

SYN Flood：SYN Cookiesの設定

IP Spoofing：...

インターネットレベルでの防御

これは後回し。最低限上の2つは講義できるように資料と演習環境を作らなければならない

Dockerネットワークはプロセスの所属するNetwork Namespaceを制御することで実現されている。そのため、SYN Cookies を設定するような演習は難しい

設定できたように見えても、動作が変わっていない..GitHub Codespace 上で演習をするのは難しそう

Volumetric Attack は環境に負荷をかける恐れがあり、SYN Flood は Dockerネットワーク上では適切に動作しない。これらは VMWare などの他の方法を使って演習することになる。

Vagrant 側環境

service

nginx を service として提供する。

tcpdump を利用できる。

$ tcpdump enp0s8 -n

Port forwarding でホスト側の 80 番からアクセスできる。

attacker

hping3 を利用できる。

$ hping3 --syn --rand-source ...

仮想マシンがフリーズする

service 仮想マシン側で、Backlog の増加を確認したい

14:14

ss -ntlp を実行していないがフリーズした。

VirtualBox マネージャーもフリーズした。

Windows Update が完了したところ、この現象は落ち着いた

環境

受講者は、各々の GitHub Codespaces 上で作業する。

containerlab

Containerlab Extension

ids-intrusion-csv

Repository

attack

volumetric

bots_and_cc.clab.yml

c2_server.py

c2_client

c2_client.py

install.sh (download hping3 and c2_client.py. then execute c2_client.py)

protocol

syn.clab.yml

detection

classify.py

filter.py

02-14-2018.csv

blocking

your_router

daemons

frr.conf

other_router

daemons

frr.conf

bgp_network.yml

requirements.txt (scikit-learn, etc, ...)

時間構成

時間から逆算して、どれくらいの要素を詰めこめるかを考えるべき

16人を4グループに分割（または15人を5グループに） → グループ内で支え合い、議論など。

Must

About（5分）

Attack Theory（40分）

Volumetric Attack（30分）

Build your own Botnet（20分）

UDP Flood（0分）

Amplification Attack - ICMP amp（10分）

Protocol-Based Attack（10分）

How the vulnerability causes DoS?

Lab: SYN Flood（10分）

How to harden your machines against Protocol-Based Attack?

Lab: SYN Cookies（5分）

Application-Based Attack（0分）

Detection and Filtering（40分）

Basic usage of scikit-learn（20分）

Find malicious packets using scikit-learn（10分）

Integrate your ML model with firewall using NetFilterQueue（10分）

Filtering by ISP（20分）

BGP（10分）

RTBH Implementation（10分）

Icebraking（5分） : 自己紹介をもとに話し合う

最新の DDoS 動向をチェックし、課題に取り組む（40分）

これまでの知識を踏まえてレポートなどを読み、疑問などを解消する。

使用するニュースサイト

課題例

脅威アクターに目を向ける

社会経済とDDoS

DDoS as a Serviceに目を向ける

国際政治とDDoS

DDoS攻撃は、戦争など国際政治の場に持ち込まれることがある。どのような事例があり、そのステークホルダーは誰なのか、相関図を整理しよう。

新しい攻撃ベクトルの検討

これまで学習した攻撃原理をもとに、新しい攻撃ベクトルを検討しよう。

課題に取り組む時間は25分。

課題で取り組んだ結果を発表しよう（1人2分 × 4 = 8分, +2分で 10分）。

発表の感想を交流しよう（5分）。

Lab: SYN Flood

講義: TCP 3ウェイハンドシェイク / Backlog の概念の概要

0.

$ vagrant up

$ cat /proc/sys/net/ipv4/tcp_max_syn_backlog

1. 攻撃側から SYN パケットを非 flood モードで送る

$ sudo hping3 --syn -p 80 (IP address)

2. tcpdump で service 側のパケット送受信を観察する

$ sudo tcpdump -i any

→ SYN に対して SYN/ACK → SYN/ACK に対して RST

3. RST が送られないようにする

4. 再度 パケット送受信の状態を観察する

5. すべてのソケット一覧を表示する

$ ss -nta

6. SYN-RECV 状態のソケットのみを表示する

$ ss -nta | grep 'SYN-RECV'

7. SYN-RECV 状態のソケットの個数を表示する

$ ss -nta | grep 'SYN-RECV' | wc -l

8. 定期的にソケットの個数と現在時刻をボリュームに記録する

$ echo "$(date -Iseconds) $(ss -nta | grep 'SYN-RECV' | wc -l)" >>

Lab: SYN Cookies

講義: SYN Cookies の仕組み

0.

$ vagrant halt

1. SYN Cookies を有効にする

2. もう一度 hping3 を実行する

3. tcpdump で、SEQ と ACK の様子を観察する（できるのかは分からない）

Learn More: Ping of Death など、他の Protocol-Based Attackについて調べる。

Lab: Build your own Botnet

Learn how CNC servers behave and how to operate a botnet.

Scenario

Establish connection to CNC server and receive operations to execute.

Scan random IP addresses using SYN scanning, then

Loader stores pairs of identifiers and credentials of vulnerable devices.

To store, initialize inner queue.

Setup a http server to receive credentials from bots.

Environment

binds

./src/cnc.py:/root/cnc.py

binds

./src/loader.py:/root/loader.py

Conclusion:

Using botnet, it is able to send a lot of packets for Volumetric-Based Attack.

サービスを守るというタイトルに立ち返る

Protocol Based Attackについては、攻撃と防御をセットで話すのが綺麗

ただし、長い時間を割くべきでもない

個々のホストで実施できる対策なのが特徴

攻撃の検出とIPS的な防御に時間を割く

IP Spoofingの検出

過剰なパケットの検出

Mitigation装置の説明に繋げる

ネットワーク事業者レベルでの遮断に踏み込む際は、BGP Flowspecまで話し切るべき

流れとしてBGP Community RTBHも話すべきだが、経由地に過ぎない

RTBHは完全な遮断なので

TODO

タイムゾーンの設定

キーボード配列の設定

何か大変そう

ボリュームを用意する

BGPメモ

BGP: ポート179のTCP接続上で動作するプロトコル。

eBGPとiBGP

eBGP: ルーターが相互に直接接続するので、TCPパケットのTTLは1。

iBGP: 直接接続しなくてもピアを確立できる。そのためにTCPパケットのTTLは255とする。

※ Neighbor は単一のASに複数存在しうることに注意する。

BGPのメッセージ

OPEN: BGPセッション開始

UPDATE: 経路情報更新・削除

NOTIFICATION: BGPセッション終了

Wiresharkで実際にキャプチャする様子

Path Attributes

ORIGIN: 経路情報が eBGP / iBGP / それ以外 のどれから生成されたのかを表す。

AS_PATH: 経路情報が経由してきたAS番号の一覧。

LOCAL_PREF: iBGP内のみで広告される、経路の優先度

LOCAL_PREF が高い経路がある場合、その経路が優先的に選択される。

COMMUNITY:

非常に非常に非常に分かりやすいスライド：

RTBH もこのスライドに書かれた方法の派生にすぎないことがわかる

NTTのルーティングポリシ（NTTが運用するCommunityの意味が示されている）

Blackhole の RFC は BGP での DDoS 防御の知見の結節点といえる。ここを重点的に読むべき

Path Attributes の種類と、UPDATEに含めたり通知したりする必要性の有無は下記から一覧できる。

実際の経路情報を見てみるのもあり

FRRでのCommunityの取り扱い

Ciscoなど一般的な場合の取り扱いを先に見ておくと納得しやすい

Communityを付加して広告する場合の処理

1. prefix-list を定義する。

これは、どの prefix に対して Community を付加するかを表す。

2. route-map を定義し、 prefix-list に matchするような条件を書く。

その中で、その経路の場合どのような Community を付加するかを定義する。

Communityを受信した場合の処理

1. community-list を定義する。

ふだんは Numbered Community List として定義すれば良い気がする。

2. route-map を定義し、community-list に match する条件を書く。

その中で、その条件を満たす経路に何をするのかを書く。

受信した Blackhole Community 付きの経路は、RFC にある通り、再広告すべきではない。FRRは、 Blackhole Community が付加された経路に対して自動で NO_ADVERTISE Community を付加する。

このあたりの挙動をしっかり理解するために、実際に Wireshark で解析できるのが理想

containerlab には機能として実装されているが、時間的にできるかが怪しい..

NEXT_HOP が謎

Next Hop を null とする経路を広告するのでは不十分なのか？

たぶんそう単純ではない

Blackhole Community を使うことで、経路の変動を最小限に抑えつつ、破棄フィルターの条件となるデータをやり取りできる

もちろん、破棄フィルターは各ルータが実装する必要がある。このあたりはルーティングポリシを見ると実感できるだろう

Blackhole Community 付きの経路情報が伝播しない理由について

直接接続していない Speaker からの Blackhole Community を信頼してしまうことの危険性

不正な情報を信頼すると、それだけで自 AS に格納された全ホストが対象ホストにアクセスできなくなるので、注意が必要なのだと理解している

Community を使わない RTBH もまた入口対策である

エッジルーターに iBGP で Blackhole Routing を伝播させるということが重要

ただ、経路情報は信頼できるので、Advertise して問題ない？

Customer と ISP というくくりで考えるべき

破棄フィルターの実装は、Next Hop をもともとある Static Route に向ける方法が一般的なのだろう

下図のような状況を考える

Edge-1 の BGP 設定で、外部の Neighbor に対しての Route Map でのみ、666 Community 経路に Blackhole Community を付加して広告するようにする。

Edge-1 でも No-Edge-1 でも、 Blackhole Routing の設定はしておく。

https://scrapbox.io/files/68c822a2de8abde60892384c.png

遮断については、DDoSの継続時間が短い傾向にある事も話しておく必要がありそう

Lab: RTBH Implementation

トポロジ

https://scrapbox.io/files/68c8292f5901f5f917f6cd9e.png

（Customer NW 内では、 Customer は自由に ACL を設定できる？）

Customer が Attacked への遮断を要求するとき、Trigger Router（Customer）から、ASN:666 を付与した経路を広告する。

通常の iBGP で伝播し、Other Customer のルーターにも伝播する。

Other Customer ルーターは、 ASN:666 に対する route-map をもとに Next Hop を変更し、Attacked へのパケットを Blachole routing する。

ISP Routerに伝播するとき、ISP Router は Other ISP への Neighbor 設定での route-map をもとに、Blackhole Community を付与した経路を広告する。

Direct peer ISP Router に伝播すると、他の Neighbor には伝播させずに Blachole Routing する。

このため、Indirect peer ISP Router や、 Direct peer ISP 内のルーターには告知されない。

疑問: ISP は Customer の IPアドレス範囲を丸ごと包含しなくてもよいのでは？

Lab contents

Configure the topology using FRR config file. Please separate configuration by ISP.

For beginners, we provide an example configuration.

Flowspec エントリを FRR 上で作成することはできないことがわかった

Flowspec エントリを受信して、インストール（ルールを反映）することはできるみたい

演習として Flowspec を取り扱うことはできないので、RFC や事業者の記事やスライドを参考に一般論として講義する

S/RTBH?

今まで考えていたのはすべて D/RTBH

Destination への到達を禁止するもの