Help us understand the problem. What is going on with this article?

知っているようで意外と知らない、DDoSの基礎知識

More than 1 year has passed since last update.

どうも先日(2016年9月現在)からさくらインターネット様や技術評論社様でDDoS被害が相次いでいますね。

「DDoS対策しとけ」なんてよく言われていますが、セキュリティにステータス振ってない場合は「DDoSってF5連打じゃないの?」みたいな人も結構いるんじゃないでしょうか。あとはiptablesをとりあえず入れておけば大丈夫なんじゃないの?とか。

Web系の開発者にとってのセキュリティ対策は「フレームワークをちゃんとアップデートする」に尽きるので、フレームワークの脆弱性に依存しないDDoSって意外と知らない事が多いと思います。

知っているようで意外と知らないDDoSの世界、ちょっとまとめてみました。

TL;DR

  • スケールできる設計でDDoSに備えよう
  • nginxは置いとけ、キャッシュは甘く見るな
  • SYN cookiesは入れとこう
  • 最後はカネの力でセキュリティを手に入れろ

Akamaiセキュリティレポートに聞け

さて、いきなりですがDDoSの世界を個人が把握するのは困難なので巨人に頼りましょう。

CDN界の巨人、Akamai社はセキュリティレポートをインターネットにて公開してくれています。プレビュー版であれば誰でも読めるので、まずはこのあたりを読んでみると面白いと思います。

「100Gbpsを超えるDDoS攻撃が増加している」……ギガビットイーサの100倍??なんだかよくわかりませんが凄そうだ、という感じはしますよね。

セキュリティにおけるレイヤ

セキュリティレポートを読み進めると、「レイヤー3およびレイヤー4に対するDDoS攻撃」とか「レイヤー7に対するDDoS攻撃」とか出てきますね。

このレイヤーは、OSI7階層モデルを指しています。つまり、「レイヤー3およびレイヤー4に対するDDoS攻撃」とは「ネットワーク層・トランスポート層に対する攻撃」、すこし具体的に言えば「TCP・UDPパケットを投げつけてターゲット(ルーター・スイッチも対象)に負荷をかける攻撃」と言えるでしょう。

同様に、「レイヤー7に対する攻撃」は「アプリケーション層に対する攻撃」、具体的な例で言えば「HTTPサーバに対する攻撃」です。

F5連打や田代砲はHTTPリクエストを多量に流す攻撃なので、「レイヤー7に対する攻撃」というわけです。

誰でも思いつくのに意外と厄介。レイヤ7攻撃、HTTP Flood

HTTP Floodとは?

F5連打です。以上。

──というとチョロそうですが、いわゆるYahoo!砲のような「攻撃なのかアクセスが多いだけなのか判断できない」という厄介さを持ち合わせます。

単一IPからアクセスが多いだけならiptablesあたりでブラックリスト入りさせるだけで防げますが、実際の攻撃者はbotnetを通じて大量のIPアドレスからアクセスしてきます。こうなると全部弾くわけにも行きませんし、結構困るものだったりします。

HTTP Floodの対策は?

トラフィックにあわせてオートスケールする仕組みを入れましょう。以上。

──というと運用中のサーバが守れないじゃないか!とキレそうになりますが、静的コンテンツがメインであればWebサーバの前にnginxを置いてキャッシュから参照させてやるだけで結構耐えられたりします。ついでにセキュリティ系モジュールのNaxsiMod_Securityを入れておくとなお良し。ちょっと敷居が高いんですが。

もちろんnginxはセキュリティ製品でもないので、防げないHTTP Floodもある、というかランダムなクエリ文をURLに加えてやるだけでWebサーバにリクエストが到達して負荷をかけることができるので、 スケールさせてやるのが一番 ではあります。
ただ、無いよりはマシですし導入も簡単なので、 まずはnginx置きましょう。

古参ながら未だ現役、レイヤー3・レイヤー4攻撃の代表格。SYN Flood

SYN Floodとは?

セキュリティについて勉強すると間違いなく教科書に載ってるレベルの古くからある攻撃でありながら、未だに使われることの多い攻撃です。

前述のHTTP Floodは、実はDDoS攻撃全体の2%程度しか使われない攻撃なんですが、SYN Floodは7%程度使われている攻撃です。

さて、この攻撃は「レイヤー3およびレイヤー4に対するDDoS攻撃」なので、理解にはTCP/IPの知識が必要になってきます。SYN Floodは3way Handshakeで投げられるSYNをたくさん投げつける攻撃です。

3way Handshakeについてはググればいくらでも情報が出てくるので省きますが、だいたいどこも下記のような図が出てくるんじゃないでしょうか。

synflood.png

このとき、SYNパケットを投げつけ続けてリソースを消費させてやろう、というのがSYN Floodです。

未だに使われるだけあって結構強力なうえ、 SYN+ACKの受信を期待しないので、自身のIPアドレスを詐称しても攻撃が成立します。 要するに、1つのコンピュータからでも無数のIPアドレスを装った攻撃ができるので、 IPアドレスをブラックリスト入りさせる方法では防御できない のです。

SYN Floodの対策は?

Linux kernelに防御用の設定があります。SYN cookiesを有効にしましょう。

echo '1' > /proc/sys/net/ipv4/tcp_syncookies

ググるとiptablesのレートリミットで多量のアクセスが来たらIPをブロックする、という方法が紹介されている場合もありましたが、前述のようにIPベースのフィルタリングはあまり有効ではありません。


9/5 追記
SYN cookiesがiptablesの設定である、と記載していましたが、正しくはLinux kernelの持つ防御でした。すみません!

iptablesの設定ではなくカーネルパラメータのため、CentOS 7等のfirewalld環境下でも設定内容は変わりません。
また、現在では多くのLinuxディストリビューションにてSYN cookiesがデフォルトで有効です。

世間を賑わす非常にやっかいな攻撃。Reflection DoS

Reflection DoSとは?

いま世間を賑わせる攻撃がReflection DoS、反射型DoSと呼ばれる攻撃です。なんと 現在のDDoSは50%がこの攻撃 だったりします。冒頭の「100Gbpsを超えるDDoS攻撃」はほぼ間違いなくこの攻撃の仕業でしょう。

この攻撃は、インターネット上に公開されているDNSサーバを経由する攻撃です。まずは通常のUDPパケットによるDNSのイメージを。

dns.png

DNSサーバにUDPでリクエストを投げたら、データ量がちょっと増えて帰ってくる。ポイントはこれだけです。(これだけなので、この攻撃に利用するプロトコルはDNSである必要性は無かったりします。最近はNTPなんかも使われます。)

次に、Reflection DoSのイメージを。

dns-amp.png

DNSサーバで何か反射してるっぽいですね。

UDPの通信はハンドシェイクが無いので、送信元アドレスが詐称できてしまいます。データ量がちょっと増える通信を、送信元を詐称したうえで送信することで、ターゲットに大きなトラフィックを流し込むわけです。

この攻撃は反射に利用されているDNSサーバからの通信をフィルタリングしてしまえば良いのでは?と思うところですが、世の中にDNSサーバは山程あるのでフィルタリングしきれません。

Reflection DoSの対策は?

この攻撃は分類すると「レイヤー3およびレイヤー4に対するDDoS攻撃」なので、Webサーバの耐久性を上げても効果はありません。

ではiptables等のFW設定で防げないのか?というと、トラフィックが大きすぎる場合は ルーターやスイッチが音を上げる ので、そもそも守るコンピュータまで通信が届かなくなってしまったりします。

業務用のスイッチですらスループットは1Gbps無かったりするので、100Gbpsのトラフィックが来た場合はまず耐えられません。

じゃあどうすれば耐えられるの?というと、正直確実なのは有償の対策サービス、WAF等を導入するくらいしか無かったりします。本気出されたら生半可には防げない攻撃だからこそ、大流行してるわけですね。


9/5 追記
有償サービスやWAFがどうやって守っているの?というと、大きく分けると2タイプなんじゃないかなーと思います。 以下、推測混じりな点に注意。

  1. インターネットバックボーン側で止める
  2. CDN+クラウドWAFに分散させて耐える

1点目は、「より上位のネットワークで止める」なんて言われたりするタイプの守り方です。ISPの対DDoSサービスなんかはこれに当たるんじゃないでしょうか。

上位のネットワークに対処を頑張ってもらうので、個人の設定でどうにかできる話ではありません。

2点目は、攻撃を分散させて耐えぬく方法です。
世界中に莫大な数のサーバを持っているCDN業者であれば、世界中にトラフィックを分散させてFWでフィルタリングしたり浄化したりできるわけです。

これも前提として莫大な数のサーバが必要なので、個人でどうにかできる話ではありません。

まとめ

──というわけで、以下のようにして守りましょう。

  • スケールできる設計でDDoSに備えよう
  • nginxは置いとけ、キャッシュは甘く見るな
  • SYN cookiesは入れとこう
  • 最後はカネの力でセキュリティを手に入れろ

DDoS攻撃も流行がありますし、紹介した手法以外にも攻撃方法は山程あるので、上記の知識があればダイジョーブ!ではありません。ですが、とりあえずDDoSってF5連打攻撃じゃないよ、というのは覚えておいて貰えると、対DDoSおじさん達が喜びます。

ueyasu
Why not register and get more from Qiita?
  1. We will deliver articles that match you
    By following users and tags, you can catch up information on technical fields that you are interested in as a whole
  2. you can read useful information later efficiently
    By "stocking" the articles you like, you can search right away
Comments
No comments
Sign up for free and join this conversation.
If you already have a Qiita account
Why do not you register as a user and use Qiita more conveniently?
You need to log in to use this function. Qiita can be used more conveniently after logging in.
You seem to be reading articles frequently this month. Qiita can be used more conveniently after logging in.
  1. We will deliver articles that match you
    By following users and tags, you can catch up information on technical fields that you are interested in as a whole
  2. you can read useful information later efficiently
    By "stocking" the articles you like, you can search right away
ユーザーは見つかりませんでした