今回の記事は「DDoS攻撃対策トリロジー」第二回です。前回の記事に我々はDDoS攻撃の基本原理が説明したが、だから今回テーマは一般的なDDoS攻撃の対策を教えなさい。

始め前に、何っで今回の記事はただの「一般的なDDoS攻撃」だけを説明する。まず、私で「一般的なDDoS攻撃」の理解はHTTP（S）フラッド攻撃そしてDoS類の脆弱性を利用するの攻撃以外のDDoS攻撃です。その原因は「一般的なDDoS攻撃」と「HTTP（S）フラッド攻撃」の対策方法は全然違う、そして「DoS類の脆弱性を利用するの攻撃」の対策方法は以前の記事にも教えましたから、だからこそう今回記事の対策はただの「一般的なDDoS攻撃」だった。

1. DDoS攻撃対策基本理論概要

「一般的なDDoS攻撃」の対策は、その理想な理念は**「防御コストには攻撃コストより低くされる。」**です。

この防御コストには、CPU、メモリ、サーバーの数など、要求を処理するためのリソース使用のコストが含まれます。最も簡単な理解は、私がDDoS対策に費やすお金を減らしたいということです。

しかし、現実は残酷だ。

個人と一般企業以外、大企業や巨大プロジェクトにとって、そんな理想的なの対策方法はほとんど実現できない。

DDoS攻撃に対する防御の基本は、防御側が十分な帯域幅と処理能力を持っていなければならないということです。このDDoS攻撃のピーク帯域幅が一般に50Gbpsを超える現在の状況では、防御側がDDoS攻撃を自分でクリーンアップするほし、回線帯域幅はこの数値よりもはるかに大きくなければならない。

ここで、日本で1GbpsのIPトランジットを購入するのにどれくらいの費用がかかるか私を少し明らかにすることができます。 NTTが一番安いです。1GbpsのIPトランジットは月額20万円から。そしてソフトバンク（BBTEC）の価格は月額100万円から。これは二年前NTTとソフトバンクは私に提出の価格だ、この価格は米国のISPより２０倍以上高いすぎで、だから私は「日本にクリーンアップセンターを設置する」なことをやめっだ。

それと「課金すれば、それほど強くなる」な課金ゲームに同じい感覚なんだ。だからこれはDDoS攻撃防御の現実だ。簡単に理解すれば、DDoS攻撃の防御は新しい重度課金ゲームだ。

そのせいって、一般企業なら自分でDDoS攻撃をクリーンアップしてはとんでも難しいことだ。難しではなく、無理なことだ。

でも先は「個人と一般企業以外」を書いているだよね？そうっだ。

個人と一般企業はまた方法あるよ。ここで、私たちにはあるの良心企業に感謝しなければならない。それは「CloudFlare」です。

CloudFlareは最初から無料プランを誰でもにを提供した。そして２０１７年の時に全員（もちろん、無料プランも入る）には無制限DDoS保護を提供した。これから、個人と一般企業は本当で「防御コストには攻撃コストより低くされる。」の理想理念を完全に実現した。個人にとって、これで防御コストはほとんどゼロだ。

だからこの記事は三部分が書いている。個人と一般企業なら、ただの自分のサイトを無料または低コストがDDoS攻撃を防御するが、この記事の「個人と一般企業向的なDDoS攻撃対策」部分に読むだけていい。別の部分がただの技術原理そして分析だけだ。

2. 個人と一般企業向的なDDoS攻撃対策

一般的に、個人と中小企業などの業務内容はほとんどHTTP関係ですが、モバイルアプリのバックエンドも大体はHTTP-APIだ。**だから既存のCDNサービスを直接使用するのが最良の選択だ。**例えば「CloudFlare」など。もちろん、世界中CDNサービスはただ「CloudFlare」ではなく、色々なCDNメーカーがある。ただし、「CloudFlare」はこの世界中唯一に無料プランが提供したのメーカーだ。だから、もし予算が足りないのばいは、「CloudFlare」は唯一の選択だ。

**できれば、DDoS保護機能あるの仮想VPSやサーバーやクラウドを使用するはもっといいになる。**日本では、ほとんどのIDCはDDOS保護を提供していないですが、でも提供しているの企業まだあるだ。例えばAWS（Lightsailも入る）、GCP、Azure、Oracleなどの海外クラウド大手企業ほとんどDDoS保護機能が無料に提供している。無論、「Lightsail」以外の別のクラウドの月額料金は安くない。でも安いなサーバーがほしなとは別の選択があるの？もちろんあるよ。もしサーバーのロケーションは日本のみのばいは、じゃ「Linode」も良さな選択だ、安いし、そしてサーバーの性能も強し、DDoS保護機能のクリーンアップ効果もとても良いだ。

でも、もしサーバーのロケーションは日本以外でもいいのばいは、その選択はもっとたくさんがある。例えば「OVH」とか「BuyVM」とか、コスパが高いな企業がたくさんがあるよ。

ちょっとしたまとめ。個人と一般企業のDDoS攻撃対策は重要なことは：

1. 「CloudFlare」よなCDNサービスを使う。
2. DDoS保護機能あるのIDCを使う。

**上記の2つのポイントを全部満たせない場合、DDoS防御は不可能だ。**ただし、１つのポイントが満たすのばいは、大体８０％のDDoS攻撃を防御できる。無論、できれば2つのポイントを全部するがいい。ただし、１つのポイントが満たすのばいは、大体８０％のDDoS攻撃を防御できる。無論、できれば2つのポイントを全部するがいい。ちなみに、私自分もCloudFlareを使っている。確かに自分もDDoS攻撃対策CDNサービスを運営しているが、でもCloudFlareは本格世界一番最強のDDoS攻撃対策CDNサービスだ。

ここで見ったら、少し質問があるな？例えば、ある会社に開発したのDDoS攻撃防御ソフトウェアファイアウォールが効果があるか？

うむ、この問題はね、はっきり答えは、９割のDDoS攻撃防御ソフトウェアファイアウォールは効果がない。

具体な原因は、一般的にこのソフトウェアファイアウォールはただのIPtablesみたいなものだ、ただしIPtables自分で巨大なDDoS攻撃からの時も処理できない。だってIPtablesの前にLinux OSシステムのKernelも崩壊したが、だから一般的なソフトウェアファイアウォールはもっとう不可能だ。言うまでもなく、利用しているサーバーがDDoS対策機能を提供していない場合、ほとんどのIDCは、サーバーへのDDoS攻撃があった場合、このサーバーのIPを空ルート化したり、切断したりしてしまいます。その場合、攻撃側のゴールは達成されている。ただし、ソフトウェアファイアウォールは巨大なDDoS攻撃を処理するの可能性確かにある、具体的なテクニックについては、この記事を読み進めてくれ。

オーケー、「個人と一般企業向的なDDoS攻撃対策」を戻る。ここで、CloudFlareとDDoS保護機能あるのサーバーを使用仮定した。また、サービスをより安全にするために、いくつかの設定を行う必要がある。

2.1 Webサーバーソフトのデフォルトサーバー設定

典型的な攻撃者は、ターゲットがCloudFlareを使用していることを発見した後、直接CloudFlareに対してDDoS攻撃を開始することはない。だって勝てねいよ。そこで、ほとんどの攻撃者は、ターゲットサーバのソースIPを見つけようとする。ターゲットのソースIPを発見する一般的な方法は、ネットワーク全体のデフォルトホストのコンテンツをスキャンするか、CensysやShodanのようなツールを使用して発見することだ。

だから、そのデフォルトサーバー設定は変更しなければならない。できれば、デフォルトサーバーはNginxのデフォルトホームページを設定する。なぜなら、Nginxのデフォルトホームページ全世界何十万以上の結果がある、捜せるの可能性は低い。

server {
listen 80 default_server; # <---- 'default_server' を指定する
...
}

2.2 SSL証明書の設定

WebサーバーソフトのデフォルトサーバーからソースIPを発見できないのばいは、ほとんどの攻撃者さんはネットワーク全体で指定されたドメイン名のSSL証明書をスキャンする。

WebサーバーソフトのデフォルトサーバーからソースIPを発見できないのばいは、ほとんどの攻撃者さんはネットワーク全体で指定されたドメイン名のSSL証明書をスキャンする。だから私たちは自分でどんな情報でも自分たちでSSL証明書を発行して利用することができる（無論、そのサーバーのIPのデフォルトRDNSドメイン名を使って、「Let's Encrypt」を本物うSSL証明書に発行するもいい）。 CDNサービスとしてCloudFlareを利用しているので、サーバーで利用しているSSL証明書は、サーバーからCloudFlareへの通信内容を暗号化するだけだ。これは、通常のユーザーのアクセスには影響しない。

ここで注意して、もしこの方法を使なら、CloudFlareのSSL/TLSモードに「Flexible」または「Full」を変更が必要だ、変更したはCloudFlareはSSL証明書の有効性を検証しません、そのため、ユーザーはアクセス時にSSL証明書のエラーが発生することもない。

しかしその方法は欠点がある。これにより、通信セキュリティの一部が犠牲になります。

自分でSSL証明書を発行する：

openssl genrsa -out server.key 2048 //<----秘密鍵を生成
openssl req -new -key server.key -out server.csr //<----証明書アプリケーションファイルcsrを生成
openssl x509 -req -in server.csr -out server.crt -signkey server.key -days 3650 //<----自分の10年分SSL証明書を生成

WebサーバーソフトウェアのSSL証明書（デフォルトホストの証明書を含む）を、自分で発行したSSL証明書に置き換える。

2.3 CloudFlare以外のIPアクセスをブロックする

CloudFlareは、CDNサーバーがソースサーバーをリクエストする際に使用する可能的なのIPのリストを提供する。この IP セグメントを許可されたアクセス (例: nginx や iptables など) のリストに追加することで、指定されたホスト名に対するネットワークのフルスキャンに抵抗し、ソースサーバの IP が攻撃者に発見されるのを防ぐことができ、ソースサーバへの DDoS 攻撃を回避することができる。

CloudFlareのIPセグメントリストを表示するには、ここをクリックして

もちろん、ほとんどすべてのCDNサービスプロバイダが同様のリストを提供しており、ユーザーがCDNサービスのIPを簡単にホワイトリスト化できるようになっています。

ここでは、iptablesではなく、nginxを使用してアクセスホワイトリストを設定することをお勧めします。管理しやすいからだ。

もしもっとやすくしたい、以前私に開発したシェルスクリプトを使用して、このIPリストを自動的に更新できます。

Github: DeepSkyFire/AutoUpgradeCloudFlareIPv4

用法:

wget https://raw.githubusercontent.com/DeepSkyFire/AutoUpgradeCloudFlareIPv4/master/cfip.sh && chmod +x cfip.sh

そして、スクリプト内の「CF_NGINX_CONFIG」と、最後の行のnginxを再起動するためのファイルパスを、自分のサーバー上のnginxのインストール場所に応じて変更します。

bash cfip.sh

1回の実行で、nginxインストールディレクトリの「conf」ディレクトリに「cloudflare-allow.conf」という名前の構成ファイルが直接作成されます。このファイルには、CloudFlareの最新のIPセグメントが含まれています。

server {
    ......
    include cloudflare-allow.conf;
    deny all;
    ......
}

Nginxホスト設定ファイルのサーバー構成セクションに追加する。

0 2 * * * /root/cf.sh

Linux OSからcrontab -eを使って、定期アップグレードを設定します。上記の例では、１日１回、午前2時0分にアップグレードが実行される。

2.4 LinuxシステムのSYN Cookie機能を有効にする

**個人的には、この設定は、DDoS保護があるのサーバーとVPSにのみ有効だと思う。**サーバー上でDDoS保護のないほとんどのIDCまたはDDoS攻撃を受けているVPSは、攻撃されたIPに空のルートを直接送信するため、DDoS保護がないのサーバーは何も効果はない。

SYN Cookie機能はLinuxシステム中、TCP-SYNフラッド攻撃を対抗するの方法です。簡単に言えば、SYN Cookie機能有効にいる時、LinuxオペレーティングシステムはSYNリクエストをSYN待機リストに保存しませんが、チェック値をSYN-ACKに書き込み、それをリクエスターに返する。このチェック値はSYN Cookieであり、Web分野のCookiesテクノロジーに少し似ている。

だから、SYN Cookie機能が有効の時、LinuxシステムはほとんどTCP-SYNフラッド攻撃を無視してもいい。

しかし、先「この設定は、DDoS保護があるのサーバーとVPSにのみ有効だと思う。」を書いているだよね？でもそのサーバーもうDDoS保護機能があるので、じゃSYN Cookie機能を有効するは何だろうな？

一般に、DDoS保護機能を提供するIDCは、広域のDDoSクリーニング設備を使用する。ただし、このような広域のDDoSクリーニング設備では、TCP-SYNリクエストの正当性を効果的に識別することは一般に困難だ。したがって、TCP-SYNフラッド攻撃が発生すると、DDoSクリーニングデバイスは、適切にブロックできない攻撃トラフィックをリークし、攻撃トラフィックがサーバーに到達できるようにする。

だからこそ、我々はSYN Cookie機能を有効してがいい。無論、攻撃のピーク帯域幅は、サーバーの帯域幅を超えることはできないなあ。

有効化方法:

echo "net.ipv4.tcp_syncookies = 2" >> /etc/sysctl.conf
sysctl -p

その中で、「tcp_syncookies」には3つのパラメーターがあります。パラメータ0は、SYN COOKIE機能を閉じるためのものです。パラメータ1は、SYN待機リストがいっぱいになった後でのみSYN COOKIE機能を有効にします。パラメータ2は、SYN待機リストを使用せず、すべてのSYNリクエストに対してSYNCOOKIE機能を有効にします。TCP-SYNフラッド攻撃を効果的に防御し、SYN COOKIE機能がオンになった後のTCP-ACKフラッド攻撃を容易に防ぐために、パラメーター2を直接選択して、すべてのSYNリクエストに対してSYNCOOKIE機能を有効にすることをお勧めする。

2.5 CDNサービスとオリジンサーバーの間にリバースプロキシサーバーを追加する

CloudFlareを使用しない場合は、リバースプロキシを追加することで、ある程度のセキュリティを確保できる。例えば、リバースプロキシを使用して、バックエンドサーバーのリソースを使用することなくTCP-SYNフラッド攻撃に抵抗できる。

しかし、CloudFlareが使っている時、大体HTTPフラッド攻撃の攻撃は何も心配必要ない、だってCloudFlareは全部クリアするだ。

したがって、この場合、リバースプロキシを使用する目的は、インフラストラクチャの安定性とスケーラビリティを強化することだけです。

リバースプロキシを設定することで、将来のHTTP（S）フラッディング攻撃に抵抗するための基盤を築くこともできる。そのとき、リバースプロキシはWebアプリケーションファイアウォールとしても機能する。もちろん、最大のメリットは、管理と将来の水平方向の拡張を容易にすることができることだ。

2.6 IDCのファイアウォールコントロールパネルで直接すべてのUDPトラフィックをドロップするように設定します。

これは非常に怠惰な方法だっが、でも非常に効果的な。しかし、使用条件には制限がある。まずは、WebなどのTCPサービスのみ。そして、HTTP３どQUICは使わない。

何でUDPをドロップするのは、原因は現在世界中に８割のDDoS攻撃はUDPフラッド攻撃だ、そしてそのUDPフラッド攻撃中には９割の攻撃源は有料のDDoS攻撃プラットフォームからの攻撃です。だからこそう、すべてのUDPを直接にドロップするが、そのUDPクラスの攻撃は直ぐに無意味だ。

ただし、ファイアウォール設定を提供するIDCは多くないですが、そしてそのファイアウォールはホストのiptablesではなく、ハードウェアファイアウォールなどのこの種のネットワーク機器が最適です。

でもあんまり心配じゃない、大体一般的なクラウドにも同じみたいなの設定がある。一番効果強いのは「OVH」だ、その「OVH」の設定は正真正銘な本当のハードウェアファイアウォール本物だ。そしてAWSやGCPやAzureやLinodeのクラウドは本当の意味でのハードウェアファイアウォールではないですが（実際にはゲートウェイ）、でもパフォーマンスは悪くない。

もしファイアウォールルールが設定できるる場合は、すべてのUDPプロトコルのデータパケットを破棄するように直接設定して、ほとんどのDDoS攻撃に抵抗できます。

ただし、それにを設定したら、すべてのUDPサービスやソフトは全部使わないが、例えばDNS。このサーバーはすべてのドメイン名を解析できないの可能性がある。だって一般のDNSはUDPが使うから。だからこそう、その時我々は「DNS over TLS」それとも「DNS over HTTPS」が代わりに使ってくれ。

結果から、私たちにできることは本当に多くないが。しているのことは、実際にはただ変装だった。でもこれはDDoS対策の一環だ、ただの技術に対抗するは無理だ。

3. 自律システム（Autonomous System）があるの個人と企業向的なDDoS攻撃対策

この部分から、一般人に言えばほとんど関係ないですか、６割のインフラエンジニアは自律システムが何であるかを全然知らない。でもこれはこの部分のインフラエンジニアのせいではない、自社が自律システムを持っているの会社はあまり多くないですが、個人に言えばもっと不可能だ。

実際に、自分の自律システムを申し込むするれば複雑じゃない、そしてただのIPv6を使うれば一年の料金もとんでも安い。でもただのIPv6なら本気に言えばそれとおもちゃは同じだ、何も意味がない。ところで、自分の自律システムとIPブロク本当に使っている時、たくさんの学費にを払わせってが「BGPプレーヤー」の宿命だ。

前に言ったんのは、DDoS対策の究極目標は「防御コストには攻撃コストより低くされる。」、うむ、距離はどんどん遠くなっているよ。

ですから、自律システムを使うのば、DDoS対策れば、もはや「スタートラインでも負けった」。

3.1 賃貸ネットワークインフラ施設

この分類中には、大体は「BGPプレーヤー」。じゃ何が「BGPプレーヤー」？

「BGPプレーヤー」は、自律システムとIPセグメントを申請したが、楽しみのためだけに使用した人々を風刺するために使用される。

そのような人々は、大切なIPリソースを合理的に使用するのに十分な資金を持っていないため、基本的に、一部の小規模なIDCマーチャントでのみホストできる。

もちろん、ある会社は様々な要件などの原因で、同じくに自社のネットワークインフラ施設はない。でも大体はAWSなどのクラウドでホストしている。ただし、AWSなどのクラウドはDDoS保護機能を提供しているから、ほとんどDDoS攻撃な問題が考え必要ない。

しかし、小規模なIDCマーチャントはDDoS保護機能きっと不可能だ。

そんな状況で、**唯一の方法はDDoS保護サービス業者から「IPトランジットを介したDDoS保護（DDoS Protection with IP Transit）」を購入するだけだ。**先に言ってますけど、このようなのDDoS保護サービス全然安くないよ。

「IPトランジットを介したDDoS保護」を選択する際には、価格だけでなく、DDoS攻撃トラフィックのリーク率にも注意を払う必要がある。一部の「DDoS保護サービス」と同様に、DDoS攻撃トラフィックのリーク率は40％と高く、月額は非常に安いですが、ネットワークがDDoSに攻撃された場合、このような低品質の保護効果は何も意味はない。

現在、「IPトランジットを介したDDoS保護」を提供しているのDDoS保護サービス業内、効果一番良いのはやはりCloudFlareの「Magic Transit」だ。「Magic Transit」のDDoS攻撃トラフィックのリーク率はほとんど１％くらい、大体は１００％クリーニングと同じいだ。無論、「Magic Transit」の価格は本気に言えば全然安くない。別の同じみたいな「IPトランジットを介したDDoS保護」がたくさんがある、例えば「Incapsula」どが、「Voxility」どが、「Arbor」などたくさんがある。

以上の「IPトランジットを介したDDoS保護」大体同じのポイントは、価格全部高い。だからこそう「スタートラインでも負けった」言ったんだ。

しかし、本当にお金がないなら、「BGPプレーヤー」たちにとって本当に何も方法はないのかな？

もちろん、慎重に自律システムを設定した上で、ある程度の規模のDDoS攻撃には抵抗してはできる。

例え「BGPプレーヤー」たち中、一番人気なホストIDC「Vultr」。その「Vultr」は特定の地域でのみ有料DDoS保護を提供する。しかしその有料DDoS保護は最大帯域幅ただの１０Gbpsだけ、そして「Vultr」全１７地域はただの１１地域その機能がある、その１１地域中には、アジアエリア全部ないだ。

でも、AnyCastネットワークを構築して、ネットワークがDDoSによって攻撃されたときに、すべてのネットワークトラフィックをDDoS保護を使用してさまざまなエリアに分散させることができる。しかし、もし攻撃規模大き過ぎて、まだDDoS攻撃に耐えることができないだ。

3.2 自律ネットワークインフラ施設

この分類は大体は規模があるな企業そして経験があるな人。だからこの部分で私はその「高性能ネットワークの構築方法」などの基本方法は言わないだ。

自律ネットワークインフラ施設があれば、そのDDoS対策の主目的は「DDoS攻撃トラフィックがバックボーンネットワークに入るのを止めさせる」。

自律ネットワークインフラ施設があれば、そのDDoS対策の主目的は**「DDoS攻撃トラフィックがバックボーンネットワークに入るのを止めさせる」。だから自分のネットワークの外部で大部分のDDoS攻撃トラフィックを止めるは一位要務だ。**そのために、一番良いの方法はやはり「IPトランジットを介したDDoS保護」の外部DDoS保護サビースを買う。しかし、日本のネットワークインフラは欧米に比べて非常に弱いため、大規模なDDoS攻撃に対抗するためには、基本的には欧米にネットワークを迂回しなければならない。これは明らかな結果として、アクセス待ち時間の増加をもたらう。

だけど、「IPトランジットを介したDDoS保護」を買ってしまうれば、自分のネットワークはDDoS攻撃軽減設備（ファイアウォール）も必要だ。その原因は先の「賃貸ネットワークインフラ施設」部分は言ったんですが、ど「DDoS攻撃トラフィックのリーク率」問題だ。

ここが新しい問題だ、その「DDoS攻撃軽減設備（ファイアウォール）」何処でデプロイしてがいいの？「DDoS攻撃トラフィックがバックボーンネットワークに入るのを止めさせる」ために、DDoS攻撃軽減設備はもちろんPOP（Point of Presence）のエッジルーターの後ろうでデプロイしなければならない。

じゃエッジルーターは崩壊されではどうしよかな？うむ、別の「IPトランジットを介したDDoS保護」プロバイダーに乗り換えればいいだけだ。

ここはもう一つの問題が発見した。一般的に「DDoS攻撃軽減設備（ファイアウォール）」の価格はとんでも高いですが、予算はたりないだ。別の方法があるか？うん、もちろんある。お金ないなら、もっと力を入れないといけない。自作ファイアウォールも可能だ。以前の記事に私「Linux は大量のリクエストを処理できない」の事実が言った、ですから、ここで「FreeBSD」を使って、「PF」を使うには、自作ファイアウォールは完成しましたよ。でも、これからは本当の地獄タイミングだ。何故「DDoS攻撃軽減設備（ファイアウォール）」の価格がそんなに高いの？その原因は、ファイアウォールのルールベースは、ファイアウォールのハードウェアよりも価値がある。ですから、自作ファイアウォールは、私たち自分でファイアウォールのルールを作らなければならない。

また、コアルータのアドレスを公開してはいけないという点にも注意が必要です。 そうでなければ、コアルータがDDoS攻撃を受けた場合、ネットワーク全体に影響が出てしまう。

ここで見ったら、多分少しでもすぐ分かる。そのDDoS対策と課金ゲームとても似ていうでしょう？そっだ、「課金すれば、それほど強くなる」は永遠の真理だ。

4. DDoS保護サービス業内大企業のネットワークとインフラまたはDDoS防御対策方法の解析

この部分で、DDoS保護サービス業の代表的な2社だと思うの会社のネットワーク基盤やインフラや対策方法に私の個人的な見解をもとに、簡単に分析してみよう。

まずはCDNサビース業内規模最大手「CloudFlare」、この会社の技術とても独特そして十分に代表性がある、別の会社には全然みったことない。

そしてフランスの大手ホスト企業「OVH」。この会社を知らない人も多いと思うですが、しかしこの会社はヨーロッパで第一位そして世界第三位のホスト企業だった。この会社の技術は独自の特徴もある。

だからこの部分でこの二社を簡単的に解析する。

4.1 CloudFlare

「CloudFlare」は私が３つ尊敬しての企業中の一つ。まずその企業は略奪で利益を得るのではなく、すべてのサイトを安全に運営し続ける。そして技術とても独特だ。

「CloudFlare」の2つの最も重要な部分、つまり「ネットワークインフラ」と「DDoS攻撃クリーニングテクノロジー」を分析する。

4.1.1 CloudFlareのネットワークインフラ

まず、CloudFlareのノード分布マップを見てみましょう。

これを見ろう、ほとんど全世界の国でノードがある。

今まで、CloudFlareの総アクセス帯域幅は３８Tbps。まあー、１８年の時５０Tbpsが保有したですが、今は代わりに少しくなっている。でも３８Tbpsの帯域幅れば、今後3年間、起こりうるDDoS攻撃からを守るには、すでに十分余裕だ。

「CloudFlare」は世界最大級のAnyCastネットワークを維持しています。実際、DDoS対策にAnyCastネットワークを利用した初のCDNサービスとなる可能だ。大規模なAnyCastネットワークを維持するのは非常に難しいことを説明しなければなりません。 ISPの状態に応じたルーティングの調整が頻繁に行われるため、「CloudFlare」は独自のインテリジェントな経路制御システムを開発した。

訪問者のルーティングを制御するためにDNSの地理的解像度を使用するよりも、AnyCastネットワークの方が明らかに精度が高いでしょう。ただし、すべてのAnyCastネットワークでできるわけではありません。そのための前提条件は、AnyCastネットワークに十分なISPが接続されており、訪問者の最適なルーティングを可能にしていることです。そのため、AnyCastネットワークに十分なISPが接続されていない場合は、AnyCastを使用しない方が良いでしょう。

だから、CloudFlareはAnyCastテクノロジーを使用しているため、近くのすべてのネットワークトラフィックを処理できます。同時に、DDoS攻撃に直面しても、単一のノードが負荷を超えることはほとんど不可能だ。

CloudFlareのノードはすべてDDoS攻撃をクリーニングするの能力がある。だけど、実際CloudFlareはいくつかのスーパーDDoS攻撃クリーニングセンターがある。分析後、「ドイツのフランクフルト」や「アメリカのロサンゼルス、サンノゼ、シアトル、アッシュバーン、ニューヨーク」や「オランダのアムステルダム」や「イギリスのロンドン」や「シンガポール」が以上のノードはスーパーDDoS攻撃クリーニングセンターだった。同時に、これらの都市はインターネットの重要な交換ポイントだ。もし超大規模なDDoS攻撃にあれば、CloudFlareはこれらのスーパーDDoS攻撃クリーニングセンターへの訪問者のルーティングを調整する。

このようなネットワーク構造により、CloudFlareの処理能力は非常に効率的になる。

4.1.2 CloudFlareのDDoS攻撃クリーニングテクノロジー

CloudFlareは最初から最後までLinuxの熱心なファンだ。CloudFlareのルーター、DDoSクリーニング設備はすべて、オペレーティングシステムとしてLinuxを使用している。

一般的に、普通のLinuxはそんな大き規模のネットワークトラフィックを処理するが不可能だ。普通のLinuxネットワークスタックは、このような高密度のデータパケットを処理できないだ。２０１７年以降が確かに新しいの方法があるですが、しかしCloudFlareは最初から（２００９年の時）は自分でLinuxカーネルのネットワークスタックを再構築した、FreeBSD のような大量のネットワークデータパケットに耐えられるようにしまう。

でも今のLinuxは「XDP（eXpress Data Path）」新しい機能を提供した、それ機能を利用すれば、簡単的に超高性能のネットワーク関連処理機能が得られる。もちろん、CloudFlareいまはこの技術をすぐに利用していった。

また、CloudFlareは非常に多くのISPにアクセスしているため、偽IPからの攻撃パケットがどこから来ているかを検知することで、偽IPからの攻撃パケットに対抗しています。これは非常にシンプルな原理なのですが、この機能もCloudFlareのようなものでないと全く実現できない。

4.2 OVH

「OVH」はヨーロッパで第一位そして世界第三位のホスト企業だ。

しかし、「OVH」はホスト企業だから、「CloudFlare」ようなの方法はほとんど使わない。

だからこそ、CloudFlareと比較して、OVHは非常に保守的なネットワークインフラを備えている。それでも気になる点はあるよ。

4.2.1 OVHのネットワークインフラ

OVHのネットワークインフラは、標準的なISPのバックボーンアーキテクチャです。そうだ、実際OVHはフランスではISPだった。でも事実は、ホスト事業はISP事業よりもっと大きくだ。

CloudFlareとは異なり、OVHには世界に5つのDDoS攻撃クリーニングセンターしかありません。各POPノードにはクリーニング機能がない。すべての攻撃トラフィックは、OVHのバックボーンネットワークを介してDDoS攻撃クリーニングセンターに転送され、クリーニングされます。ただし、すべてのデータセンターには小型のDDoS攻撃クリーニング機器があります。より洗練されたフィルタリングを実行するため。

つまり、OVHは強力なバックボーンネットワークを備えているため、DDoS攻撃を簡単に処理できる。

4.2.2 OVHのDDoS攻撃クリーニングテクノロジー

OVHのDDoS攻撃クリーニング設備とCloudFlare同じに自作ファイアウォールだ、それに同じくLinuxがつかっていった。

しかし、OVHとCloudFlare使うの技術は全然違う。OVH使っているの技術は「６Wind」会社開発したのLinuxの超高性能のネットワーク関連処理技術。うむ、簡単に言えば、使っているの技術は「DPDK（Data Plane Development Kit）」。確かに、この技術はファイアウォールにとってとんても似合う。でも、OVHは自作ものはただのファイアウォールですが、別のものはほとんど通常品だ。

5. 結論

結論はやばり「課金すれば、それほど強くなる」。

この記事は簡単な言葉で表現してみました。それでもたくさん書く。次にの記事は「HTTP（S）フラッド攻撃の対策」だ、楽しみにしていてくださいね。