抵抗 DDOS 攻擊

助您維持效能與可用性不墜的固定費用制 DDoS 攻擊防護

分散式阻斷服務 (DDoS) 攻擊的頻率與強度日益升高。由於有數以百萬計不安全的物聯網 (IoT) 裝置太容易讓人入侵，如今要建立僵屍網路來發動高度分散的巨流量攻擊，不僅較以往更容易，受影響的範圍也更大。除了攻擊量變大，攻擊者還逐漸將攻擊目標從網路層和傳輸層轉往應用程式層 (第 7 層)。應用程式層攻擊在結構上更為複雜，而且通常只需要較少的資源就可以讓網站或應用程式無法正常運作，進而使得作業中斷，造成更大的影響。

DDoS 攻擊透過讓網站與應用程式的效能與可用性降低，使得公司無法正常運作，有時甚至完全斷網。因基礎結構故障而造成的停機損失平均每小時可高達 $100,000 美元。這類攻擊一旦得逞，將可能有客戶流失、品牌形象受損、最終失去業務線的慘重後果。

網站和應用程式需要有個具備復原能力與充足情報的可擴充式網路，來幫忙抵擋規模最大、最新式的攻擊。在抵擋威脅的同時，效能不應因安全防護造成了延遲而降低，且安全性服務必須容易設定，不會讓人有設定不當而引發新弱點的機會。

遭到 DDoS 攻擊嗎？

與我們的團隊連絡

安全性概觀

相關產品

連規模最大的攻擊也能抵擋

Cloudflare 的網路處理能力較史上規模最大的 DDoS 攻擊大上 15x 倍。有了 30 Tbps 這樣的處理能力，要應付現代任何分散式攻擊 (包括以 DNS 基礎結構為目標的攻擊) 都不是問題。

共享網路情報

每有一個新的網路資產加入，Cloudflare 的網路就變得更聰明。Cloudflare 的 IP 信譽資料庫可為整個 Cloudflare 網路上所有 7 百萬個網路資產識別並封鎖新興與變種的威脅。

效能不打折

透過與 Cloudflare 中的效能服務整合，包括 CDN、智慧型路由、網站最佳化以及最新的 Web 標準，以往因安全防護造成的延遲將不復存在。

常見的 DDoS 攻擊類型

DNS 洪水攻擊

DNS 洪水攻擊藉由癱瘓 DNS 解析，讓網站、API 或 Web 應用程式因等候解析結果而卡住或完全無法使用。

UDP 放大攻擊 (第 3 層和第 4 層)

攻擊者利用開放式 DNS 或 NTP 解析器的功能來產生放大的要求流量 (也就是讓承載體積大於原始要求的體積)，藉以癱瘓目標伺服器或網路。

HTTP 洪水攻擊 (第 7 層)

HTTP 洪水攻擊會以多個來源大量產生以應用程式層為目標的 HTTP、GET 或 POST 要求，造成服務效能降低或完全無法使用。

分層式安全防護

Cloudflare 的分層式安全性防護服務集多項 DDoS 攻擊防護功能於一身，一邊將惡意的流量擋下以免其使服務癱瘓，一邊則讓善意的流量通過，讓網站、應用程式和 API 得以保有高度的可用性與效能。

主要成果

226,500,000

次攻擊於 2015 年 8 月至 2016 年 11 月期間被封鎖，相當於每天有 50 萬次攻擊被封鎖；沒有一次攻擊得逞。

95%

的每月總頻寬得以省下。

$250,000

閱讀案例研究

「Cloudflare 讓我們得以用較其他候選人少許多的成本來經營川普總統的競選網站，同時還享有所需的安全保護。」

Brad Parscale

Giles-Parscale 公司總裁

川普競選團隊數位總監

固定收費

所有的 Cloudflare 方案均提供固定費用制、無流量上限的分散式阻斷服務 (DDoS) 攻擊緩解服務，無論攻擊規模有多大均不加收費用。客戶不應因分散式攻擊相關網路流量激增，而感覺好像因此受到懲罰。Cloudflare 的 DDoS 防護可確保所有的網際網路資產都不會被癱瘓，且基礎結構成本不會有意外波動。

過去減輕過的重大攻擊

翻開過往記錄，Cloudflare 工程師見證了史上一些最大規模的攻擊。歡迎前往我們的開發人員部落格了解我們當時解決這些攻擊的方式。

400Gbps：嚴冬中規模驚人的第 3 層 DDoS 攻擊

2016 年冬季，Cloudflare 減輕掉本身迄今所遇過最大規模的第 3 層分散式攻擊。我們不僅阻止了這場攻擊，更進行了精確的測量與分析。閱讀詳情

一場 400Gbps NTP 放大攻擊背後的細節

分散式攻擊的形式千奇百怪，讓人意想不到，有個攻擊者就僅從一部頻寬只有 87Mbps 的來源伺服器，利用 4,529 部 NTP 伺服器將攻擊放大。
閱讀詳情

幾乎令網際網路癱瘓的 DDoS 攻擊

7 年多來，Cloudflare 成功對抗了許多史上最嚴重的分散式攻擊。2013 年，所遭受的 120 Gbps 攻擊是公認的一場大規模攻擊，但 Cloudflare 卻能夠讓其網站不致斷網。閱讀詳情

針對一切攻擊提供保護

Cloudflare 會擔任您一切網路流量的 Proxy，直接為您擋下任何的分散式阻斷服務攻擊，包括以下所有類型的攻擊：

第 3 層/第 4 層攻擊

大多數的攻擊都是以通訊系統的傳輸層與網路層為目標。這些層在 OSI 模型中是以第 3 層與第 4 層表示。在網路堆疊中，所謂的「傳輸層」會指定同一個網路上的兩部主機互相通訊時所用的通訊協定 (例如 TCP 或 UDP)。以第 3 層和第 4 層為目標的攻擊是設計成對網路介面發動洪水式的攻擊流量來癱瘓其資源，造成其無法回應正當流量。更明確地說，這類攻擊的目的是要讓網路交換器的容量達到飽和，或者是要癱瘓伺服器的網路卡或是伺服器的 CPU 處理攻擊流量的能力。

要利用內部部署解決方案減輕第 3 層與第 4 層攻擊雖非不可能，但會很困難。如果攻擊者有辦法傳送超過網路連結負荷的流量，您就算再加多少的硬體資源，都無法減輕這類攻擊。例如，如果您路由器上的連接埠能夠負荷 10Gbps，而攻擊者傳送 11Gbps 的攻擊流量給您，只要網路連結塞爆，您就算再加多少的智慧型軟體或硬體，也無法阻止攻擊。

所有規模超大的第 3 層/第 4 層攻擊幾乎都是有許多個來源，每個來源都對同一個網際網路位置傳送攻擊流量，形成一股超大流量，造成攻擊目標的資源癱瘓。由此可知，這類攻擊通常都是分散式的。攻擊流量的來源可能是一群互相合作的個人、由被駭個人電腦組成的僵屍網路、由被駭伺服器組成的殭屍網路、設定失當的 DNS 解析器，甚至是密碼太弱的家用網際網路路由器。

由於第 3 層/第 4 層攻擊的攻擊者不需要所送出的要求獲得回應，因此攻擊封包不需要有正確的內容或格式。攻擊者通常會變造攻擊封包中的所有資訊，包括來源 IP 在內，讓攻擊看起來彷彿是來自無限個不同的來源。由於封包資料完全可以隨機捏造，就連上游 IP 過濾之類的技術也幾乎是拿它束手無策。

有了 Cloudflare 的 DDoS 防護，所有原本會直接襲擊您伺服器的攻擊流量，都會自動被移轉到 Cloudflare 的全球 Anycast 資料中心網路，然後我們就能夠在自家網路這頭利用我們網路超海量的全球胃納量，還有層層交疊的伺服器基礎結構，吸收掉猶如洪水般的攻擊流量。換句話說，只要是傳統第 3 層/第 4 層攻擊的攻擊流量封包，全都會被 Cloudflare 擋掉，沒有一個能傳到受 Cloudflare 保護的網站。

DNS 放大攻擊

DNS 放大攻擊 (一種 DRDoS 攻擊) 日益普遍，如今已成為第 3 層/第 4 層攻擊的最大來源。Cloudflare 所減輕的攻擊經常會超過 100Gpbs，最近甚至幫某個客戶擋掉超過 300Gbps 的攻擊，該次攻擊被紐約時報評為「網際網路史上所公開最大宗的 DDoS 攻擊事件」。

在 DNS 反射攻擊中，攻擊者會向大量的開放式 DNS 解析器傳送索取大型 DNS 區域檔案的要求，但要求中的來源 IP 位址已變造成目標受害者的 IP 位址。接著解析器便回應要求，傳送大型 DNS 區域檔案到目標受害者的 IP 位址。攻擊者的要求儘管在體積上較回應小很多，卻能讓攻擊者將攻擊放大到攻擊者所能控制頻寬的許多倍。

沒有 CloudFlare 保護時的 DNS 反射攻擊

攻擊者收集僵屍網路或不安全的 DNS 解析器等眾多資源，然後偽裝成目標的 IP 位址。接著眾資源便一起傳送猶如洪水般的回應給目標，造成目標斷網。

有 Cloudflare 保護時的 DNS 反射攻擊

攻擊者收集僵屍網路或不安全的 DNS 解析器等眾多資源，然後偽裝成目標的 IP 位址。接著眾資源便一起傳送猶如洪水般的回應給目標，但這些回應在 Cloudflare 的區域資料中心就被擋下，因此正當流量仍然仍能存取網路資產。

要進行放大攻擊，必須符合兩項條件：(1) 能夠以變造的來源位址來傳送查詢 (例如使用 ICMP 或 UDP 等不需經過交握程序的通訊協定)，以及 (2) 對查詢做出的回應較查詢本身體積大許多。DNS 因為是個無所不在的網際網路核心平台，而且又符合這些條件，如今已然成為放大攻擊的最大來源。

DNS 查詢通常是透過 UDP 傳輸，換句話說，它就像 SMURF 攻擊（見下文）中使用的 ICMP（見下文），一旦傳送出來，以後就會完全自行運作。因此，DNS 查詢的來源屬性可以經過變造，而接收方卻無法在做出回應之前先判斷其真偽。DNS 也能夠產生較查詢大許多的回應。例如，只要傳送以下小小一條查詢 (其中 xxxx 是某開放式 DNS 解析器的 IP)：

dig ANY isc.org @x.x.x.x +edns=0

就能得到以下超龐大的回應：

; <<>> DiG 9.7.3 <<>> ANY isc.org @x.x.x.x
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 5147
;; flags: qr rd ra; QUERY: 1, ANSWER: 27, AUTHORITY: 4, ADDITIONAL: 5
;; QUESTION SECTION:
;isc.org. IN ANY
;; ANSWER SECTION:
isc.org. 4084 IN SOA ns-int.isc.org. hostmaster.isc.org. 2012102700 7200 3600 24796800 3600
isc.org. 4084 IN A 149.20.64.42
isc.org. 4084 IN MX 10 mx.pao1.isc.org.
isc.org. 4084 IN MX 10 mx.ams1.isc.org.
isc.org. 4084 IN TXT "v=spf1 a mx ip4:204.152.184.0/21 ip4:149.20.0.0/16 ip6:2001:04F8::0/32 ip6:2001:500:60::65/128 ~all"
isc.org. 4084 IN TXT "$Id: isc.org,v 1.1724 2012-10-23 00:36:09 bind Exp $"
isc.org. 4084 IN AAAA 2001:4f8:0:2::d
isc.org. 4084 IN NAPTR 20 0 "S" "SIP+D2U" "" _sip._udp.isc.org.
isc.org. 484 IN NSEC _kerberos.isc.org. A NS SOA MX TXT AAAA NAPTR RRSIG NSEC DNSKEY SPF
isc.org. 4084 IN DNSKEY 256 3 5 BQEAAAAB2F1v2HWzCCE9vNsKfk0K8vd4EBwizNT9KO6WYXj0oxEL4eOJ aXbax/BzPFx+3qO8B8pu8E/JjkWH0oaYz4guUyTVmT5Eelg44Vb1kssy q8W27oQ+9qNiP8Jv6zdOj0uCB/N0fxfVL3371xbednFqoECfSFDZa6Hw jU1qzveSsW0=
isc.org. 4084 IN DNSKEY 257 3 5 BEAAAAOhHQDBrhQbtphgq2wQUpEQ5t4DtUHxoMVFu2hWLDMvoOMRXjGr hhCeFvAZih7yJHf8ZGfW6hd38hXG/xylYCO6Krpbdojwx8YMXLA5/kA+ u50WIL8ZR1R6KTbsYVMf/Qx5RiNbPClw+vT+U8eXEJmO20jIS1ULgqy3 47cBB1zMnnz/4LJpA0da9CbKj3A254T515sNIMcwsB8/2+2E63/zZrQz Bkj0BrN/9Bexjpiks3jRhZatEsXn3dTy47R09Uix5WcJt+xzqZ7+ysyL KOOedS39Z7SDmsn2eA0FKtQpwA6LXeG2w+jxmw3oA8lVUgEf/rzeC/bB yBNsO70aEFTd
isc.org. 4084 IN SPF "v=spf1 a mx ip4:204.152.184.0/21 ip4:149.20.0.0/16 ip6:2001:04F8::0/32 ip6:2001:500:60::65/128 ~all"
isc.org. 484 IN RRSIG NS 5 2 7200 20121125230752 20121026230752 4442 isc.org. oFeNy69Pn+/JnnltGPUZQnYzo1YGglMhS/SZKnlgyMbz+tT2r/2v+X1j AkUl9GRW9JAZU+x0oEj5oNAkRiQqK+D6DC+PGdM2/JHa0X41LnMIE2NX UHDAKMmbqk529fUy3MvA/ZwR9FXurcfYQ5fnpEEaawNS0bKxomw48dcp Aco=
isc.org. 484 IN RRSIG SOA 5 2 7200 20121125230752 20121026230752 4442 isc.org. S+DLHzE/8WQbnSl70geMYoKvGlIuKARVlxmssce+MX6DO/J1xdK9xGac XCuAhRpTMKElKq2dIhKp8vnS2e+JTZLrGl4q/bnrrmhQ9eBS7IFmrQ6s 0cKEEyuijumOPlKCCN9QX7ds4siiTIrEOGhCaamEgRJqVxqCsg1dBUrR hKk=
isc.org. 484 IN RRSIG MX 5 2 7200 20121125230752 20121026230752 4442 isc.org. VFqFWRPyulIT8VsIdXKMpMRJTYpdggoGgOjKJzKJs/6ZrxmbJtmAxgEu /rkwD6Q9JwsUCepNC74EYxzXFvDaNnKp/Qdmt2139h/xoZsw0JVA4Z+b zNQ3kNiDjdV6zl6ELtCVDqj3SiWDZhYB/CR9pNno1FAF2joIjYSwiwbS Lcw=
isc.org. 484 IN RRSIG TXT 5 2 7200 20121125230752 20121026230752 4442 isc.org. Ojj8YCZf3jYL9eO8w4Tl9HjWKP3CKXQRFed8s9xeh5TR3KI3tQTKsSeI JRQaCXkADiRwHt0j7VaJ3xUHa5LCkzetcVgJNPmhovVa1w87Hz4DU6q9 k9bbshvbYtxOF8xny/FCiR5c6NVeLmvvu4xeOqSwIpoo2zvIEfFP9deR UhA=
isc.org. 484 IN RRSIG AAAA 5 2 7200 20121125230752 20121026230752 4442 isc.org. hutAcro0NBMvKU/m+2lF8sgIYyIVWORTp/utIn8KsF1WOwwM2QMGa5C9 /rH/ZQBQgN46ZMmiEm4LxH6mtaKxMsBGZwgzUEdfsvVtr+fS5NUoA1rF wg92eBbInNdCvT0if8m1Sldx5/hSqKn8EAscKfg5BMQp5YDFsllsTauA 8Y4=
isc.org. 484 IN RRSIG NAPTR 5 2 7200 20121125230752 20121026230752 4442 isc.org. ZD14qEHR7jVXn5uJUn6XR9Lvt5Pa7YTEW94hNAn9Lm3Tlnkg11AeZiOU 3woQ1pg+esCQepKCiBlplPLcag3LHlQ19OdACrHGUzzM+rnHY50Rn/H4 XQTqUWHBF2Cs0CvfqRxLvAl5AY6P2bb/iUQ6hV8Go0OFvmMEkJOnxPPw 5i4=
isc.org. 484 IN RRSIG NSEC 5 2 3600 20121125230752 20121026230752 4442 isc.org. rY1hqZAryM045vv3bMY0wgJhxHJQofkXLeRLk20LaU1mVTyu7uair7jb MwDVCVhxF7gfRdgu8x7LPSvJKUl6sn731Y80CnGwszXBp6tVpgw6oOcr Pi0rsnzC6lIarXLwNBFmLZg2Aza6SSirzOPObnmK6PLQCdmaVAPrVJQs FHY=
isc.org. 484 IN RRSIG DNSKEY 5 2 7200 20121125230126 20121026230126 4442 isc.org. i0S2MFqvHB3wOhv2IPozE/IQABM/eDDCV2D7dJ3AuOwi1A3sbYQ29XUd BK82+mxxsET2U6hv64crpbGTNJP3OsMxNOAFA0QYphoMnt0jg3OYg+AC L2j92kx8ZdEhxKiE6pm+cFVBHLLLmXGKLDaVnffLv1GQIl5YrIyy4jiw h0A=
isc.org. 484 IN RRSIG DNSKEY 5 2 7200 20121125230126 20121026230126 12892 isc.org. j1kgWw+wFFw01E2z2kXq+biTG1rrnG1XoP17pIOToZHElgpy7F6kEgyj fN6e2C+gvXxOAABQ+qr76o+P+ZUHrLUEI0ewtC3v4HziMEl0Z2/NE0MH qAEdmEemezKn9O1EAOC7gZ4nU5psmuYlqxcCkUDbW0qhLd+u/8+d6L1S nlrD/vEi4R1SLl2bD5VBtaxczOz+2BEQLveUt/UusS1qhYcFjdCYbHqF JGQziTJv9ssbEDHT7COc05gG+A1Av5tNN5ag7QHWa0VE+Ux0nH7JUy0N ch1kVecPbXJVHRF97CEH5wCDEgcFKAyyhaXXh02fqBGfON8R5mIcgO/F DRdXjA==
isc.org. 484 IN RRSIG SPF 5 2 7200 20121125230752 20121026230752 4442 isc.org. IB/bo9HPjr6aZqPRkzf9bXyK8TpBFj3HNQloqhrguMSBfcMfmJqHxKyD ZoLKZkQk9kPeztau6hj2YnyBoTd0zIVJ5fVSqJPuNqxwm2h9HMs140r3 9HmbnkO7Fe+Lu5AD0s6+E9qayi3wOOwunBgUkkFsC8BjiiGrRKcY8GhC kak=
isc.org. 484 IN RRSIG A 5 2 7200 20121125230752 20121026230752 4442 isc.org. ViS+qg95DibkkZ5kbL8vCBpRUqI2/M9UwthPVCXl8ciglLftiMC9WUzq Ul3FBbri5CKD/YNXqyvjxyvmZfkQLDUmffjDB+ZGqBxSpG8j1fDwK6n1 hWbKf7QSe4LuJZyEgXFEkP16CmVyZCTITUh2TNDmRgsoxrvrOqOePWhp 8+E=
isc.org. 4084 IN NS ns.isc.afilias-nst.info.
isc.org. 4084 IN NS ams.sns-pb.isc.org.
isc.org. 4084 IN NS ord.sns-pb.isc.org.
isc.org. 4084 IN NS sfba.sns-pb.isc.org.
;; AUTHORITY SECTION:
isc.org. 4084 IN NS ns.isc.afilias-nst.info.
isc.org. 4084 IN NS ams.sns-pb.isc.org.
isc.org. 4084 IN NS ord.sns-pb.isc.org.
isc.org. 4084 IN NS sfba.sns-pb.isc.org.
;; ADDITIONAL SECTION:
mx.ams1.isc.org. 484 IN A 199.6.1.65
mx.ams1.isc.org. 484 IN AAAA 2001:500:60::65
mx.pao1.isc.org. 484 IN A 149.20.64.53
mx.pao1.isc.org. 484 IN AAAA 2001:4f8:0:2::2b
_sip._udp.isc.org. 4084 IN SRV 0 1 5060 asterisk.isc.org.
;; Query time: 176 msec
;; SERVER: x.x.x.x#53(x.x.x.x)
;; WHEN: Tue Oct 30 01:14:32 2012
;; MSG SIZE rcvd: 3223

以上查詢雖僅佔 64 個位元組，卻引發了足足 3,223 個位元組的回應。換句話說，攻擊者能夠利用向開放式 DNS 解析器傳送的任何流量，實現 50 倍的放大率。

CloudFlare 的「Anycast」網路乃專為阻擋大規模第 3 層/第 4 層攻擊而設計。在 Anycast 網路上，我們散布於世界各地的 175 個資料中心每一個都能夠宣告同一個 IP 位址，而且所收到的要求將會依負載被分配給最近的設施。在平時，這樣的機制能夠自動將您網站的訪客導向我們網路上最近的資料中心，以便達到最佳效能。遇到攻擊事件時，Anycast 則能將攻擊流量有效分散稀釋到我們整個網路上的資料中心。因為無論 CloudFlare 客戶是誰，每個資料中心都是宣告同一個 IP 位址，所以流量無法以任何特定位置為目標。攻擊性質頓時從多對一轉變成多對多，而 Anycast 網路上沒有任何一個位置能夠做為單一故障點。

第 7 層攻擊

有一種新型攻擊是以 OSI 模型中的第 7 層 (「應用程式」層) 為目標。這類攻擊的原理是運用 Web 應用程式中會造成瓶頸的特定特性。例如，俗稱的「慢讀」攻擊會同時在多條連線上緩慢傳送封包。由於 Apache 會為每條連線各開一個新執行緒，而連線只要有流量正在其上傳送就不會關閉，所以攻擊者很快就能將執行緒集區中的執行緒耗盡來使網頁伺服器癱瘓。

Cloudflare 備有防護來抵擋許多這類攻擊；依照現實經驗，我們的 DDoS 防護通常能將 HTTP 攻擊流量減少 90%。就大多數攻擊而言，這樣就足以保護我們大多數的客戶免於斷網的命運。不過，萬一剩下 10% 的流量成功穿越了傳統防護系統，這對於資源有限或是面對超大規模攻擊的客戶而言，仍是難以招架。有鑑於此，Cloudflare 提供了一項 DDoS 攻擊設定，稱為「I'm Under Attack」(IUAM) (我遭到了攻擊) 模式。

IUAM 是當您的網站受到攻擊時，您可以為網站設定的安全性等級。開啟 IUAM 後，Cloudflare 就會多加一層防護來阻止惡意 HTTP 流量傳到您的伺服器。除了後台會多執行一些檢查，您網站的訪客還會看到插頁網頁 5 秒鐘，直到檢查完成為止。您可以將它想成是一個用來測試訪客不是機器人的頁面，只不過測試會自動完成，而且訪客永遠不需要填入 CAPTCHA 驗證碼。

訪客在經自動化測試確認是正當使用者後，就能自由瀏覽您的網站。為了進行測試，以及記錄正確通過測試的結果，JavaScript 和 Cookie 是非用不可。在 IUAM 模式下，您可以完整自訂要讓訪客看到的頁面，以便反映您的品牌。I'm Under Attack 模式並不會封鎖搜尋引擎編目程式或現有的 Cloudflare 白名單。

SMURF 攻擊

在最早出現的放大攻擊當中，其中一種是 SMURF 攻擊。在 SMURF 攻擊中，攻擊者會傳送 ICMP 要求 (亦即 Ping 要求) 到網路廣播位址 (即 XXX255)，該位址是宣告於路由器 (設定來轉送 ICMP 給路由器後面所有的裝置) 上。接著攻擊者便會將 ICMP 要求的來源變造為目標受害者的 IP 位址。由於 ICMP 並不包含交握程序，目的地無從確認來源 IP 是否正當。路由器收到要求後，就會將要求傳送給路由器後面的所有裝置，而這每一個裝置都會回應 Ping 要求。攻擊者能夠將攻擊放大的倍數為路由器後面的裝置數目 (亦即，如果您的路由器後面有 5 台裝置，攻擊者就能夠將攻擊放大 5 倍，請參閱下圖)。

Smurf 攻擊在很大程度上是過去的事情了。大多數的網路業者都已將路由器設為禁止傳送 ICMP 要求到網路的廣播位址。

DDoS 防護專線

謝謝