Start typing to search across invoices, services, domains, tickets, and more...
DDoS(分散型サービス妨害)攻撃は、Webサイト、ゲームサーバー、APIなどのオンラインサービスが直面する最も一般的な脅威の一つです。攻撃者は大量のデバイスを操り、標的に向けて同時にトラフィックやリクエストを送りつけ、帯域、接続数、計算リソースを使い果たさせます。その結果、正規のユーザーがアクセスできなくなります。攻撃の種類と防御の仕組みを理解しておくことが、サーバー選びやサービス展開で正しい判断を下すための前提になります。
SYNフラッド(ネットワーク層/トランスポート層):攻撃者は送信元アドレスを偽装したTCP SYNパケットを大量に送ります。サーバーは半開きの接続ごとにリソースを割り当てて確認応答を待ち続け、やがて接続キューが埋まり、正規の新規接続が確立できなくなります。
UDPフラッド:標的のランダムまたは特定のポートに大量のUDPパケットを送り付け、主に帯域を飽和させる攻撃です。UDPはハンドシェイクが不要なため攻撃コストが極めて低く、規模はGbps、さらにはTbps単位になることも珍しくありません。
リフレクション/アンプリフィケーション攻撃:攻撃者は被害者のIPを偽装し、インターネット上に公開されたDNS、NTP、Memcached、SSDP、CLDAPなどのサービスに小さなリクエストを送ります。これらのサービスはリクエストよりはるかに大きな応答を被害者に返します。増幅率は数十倍から数万倍に達し、大規模攻撃の主な発生源となっています。
CC攻撃(アプリケーション層 / HTTPフラッド):実際のユーザーを装い、ページ表示、検索、ログインなどリソースを多く消費するエンドポイントへ繰り返しリクエストを送ります。トラフィック量は必ずしも大きくありませんが、CPU、データベース、PHPプロセスを圧迫し、しかも通常のアクセスとの見分けが難しいのが特徴です。
次のコマンドで状況をすばやく把握できます。
# Summary of connection states
ss -s
# Count connections per TCP state; many SYN-RECV entries may indicate a SYN Flood
ss -ant | awk 'NR>1 {print $1}' | sort | uniq -c | sort -rn
# Top 20 source IPs by connection count
ss -ntu | awk 'NR>1 {split($6,a,":"); print a[1]}' | sort | uniq -c | sort -rn | head -20
# Watch live traffic (requires iftop or nload)
iftop -nNP -i eth0
# Capture a small sample of packets to analyze protocols and sources
tcpdump -nn -i eth0 -c 200
注意:IPv6アドレスにはコロンが含まれるため、上記のコロン区切りによる集計はIPv4でのみ有効です。あくまで簡易的な目安としてご利用ください。
攻撃トラフィックがデータセンターや回線の防御しきい値を超えると、同じネットワーク上の他の利用者を守るため、通信事業者やデータセンターは攻撃対象IP宛てのトラフィックをすべて破棄します。これを「ブラックホール」または「ヌルルート」と呼びます。ヌルルート中はそのIPに一切アクセスできません。通常は一定時間後に自動で解除されますが、攻撃が続く場合は延長されることもあります。ヌルルートは被害を食い止めるための措置であり、攻撃に「耐える」手段ではありません。そのため、高い安定性が求められるサービスには、十分な防御能力を備えた回線とサーバーが必要です。
比較検討の際は、次の点を重点的に確認しましょう。
正確な防御仕様については、IMIDC公式サイトの製品ページおよびサポートチケットでの回答をご確認ください。
DDoS対策サーバーが主に対処するのはボリューム型攻撃です。CC攻撃には、アプリケーション層での対策がより重要になります。
CDNやWAFを導入する:ユーザーにはCDNのエッジノードへ接続させ、悪意あるリクエストをCDN側で吸収・フィルタリングします。オリジンはCDNからのトラフィックのみを受け付けるようにします。
Nginxでレート制限を行う:httpブロックでルールを定義し、serverまたはlocationで参照します。
http {
limit_req_zone $binary_remote_addr zone=req_per_ip:10m rate=10r/s;
limit_conn_zone $binary_remote_addr zone=conn_per_ip:10m;
server {
location / {
limit_req zone=req_per_ip burst=20 nodelay;
limit_conn conn_per_ip 30;
}
}
}
編集後は設定をテストしてからリロードします。
nginx -t && systemctl reload nginx
SYN Cookieを有効にする(多くのディストリビューションでは既定で有効になっています。確認可能です):
sysctl net.ipv4.tcp_syncookies
sysctl -w net.ipv4.tcp_syncookies=1
オリジンIPを隠す:攻撃者に本当のIPを知られると、CDNを迂回して直接攻撃されてしまいます。推奨される対策は次のとおりです。オリジンの80/443番ポートにはCDNのオリジンプル用IPからのアクセスのみを許可する。メールサービス、サブドメインのDNSレコード、過去のDNS履歴からオリジンIPが漏れないようにする。すでにオリジンIPが漏えいしている場合は、CDNを導入したうえで新しいIPに切り替える。Cloudflareを例にとると、オリジンプル用のIPレンジはhttps://www.cloudflare.com/ips-v4で公開されており、これを使ってファイアウォールの許可リストを作成できます。
防げるのは小規模な攻撃だけです。ボリューム型攻撃はトラフィックがサーバーに届く前に上流の帯域を埋め尽くしてしまうため、データセンターや回線レベルでのスクラビング能力が必要です。
いいえ。CC攻撃はアプリケーション層を狙うため、CDN/WAF、レート制限、CAPTCHA、キャッシュ戦略を組み合わせて防御する必要があります。
自動解除を待つか、チケットを送ってヌルルートの継続時間やIP変更が可能かを問い合わせてください。あわせて攻撃元を調査し、防御プランのアップグレードが必要かどうかを検討しましょう。
CDNの防御能力が十分で、オリジンIPが漏れていなければリスクは下がります。ただし、ゲームなどHTTP以外のTCP/UDPサービスはCDNでカバーできないことが多く、引き続きDDoS対策回線が必要です。
DDoS対策は「ネットワーク層のスクラビング+アプリケーション層のフィルタリング+オリジンの秘匿」を組み合わせた総合的な取り組みであり、一つの手段だけで完全に解決できるものではありません。IMIDCは香港、日本、米国などの地域でDDoS対策付きのクラウドサーバーと専用サーバーを提供しており、複数IPやCN2回線と組み合わせて導入できます。攻撃を受けている場合や防御プランの検討でお困りの場合は、チケットを送信してください。技術チームが24時間365日体制で分析と調整をサポートします。