Cloudflare 101

1. DDoS 101

Về DDoS dù mục đích cuối cùng là làm cho dịch vụ của bạn không thể cung cấp tới người dùng nhưng nó có thể được chia thành 3 nhóm:

Application Layer Attacks: mục tiêu là khiến ứng dụng phải xử lý một lượng lớn các request có vẻ hợp lệ, làm cạn kiệt tài nguyên của ứng dụng, khiến ứng dụng không thể phục vụ các user hợp lệ khác. Ví dụ trong ứng dụng TMĐT, một API đọc database trả về một danh sách chi tiết của các sản phẩm thuộc một nhóm ngành. Attacker có thể viết một tools để crawl hết dữ liệu của từng ngành hàng, khiến server không đủ tài nguyên để phục vụ. Việc cản lọc request thuộc nhóm này không dễ vì nó sẽ khá giống với request của user thông thường và có thể cản lọc nhầm những user hợp lệ.
Protocol Attacks: tương tự application layer attack nhưng nhắm vào layer 3 và layer 4 trong mô hình OSI. Ví dụ điển hình là SYN Flood, lợi dụng việc bắt-tay-3-bước trong giao thức TCP, attacker sẽ gửi một một gói SYN để thiết lập kết nối TCP, server sẽ trả về một gói SYN-ACK và chờ đợi một gói ACK để kết thúc quá trình bắt tay. Nhưng sau đó attacker sẽ không bao giờ trả về ACK, khiến server phải tiêu tốn tài nguyên cho việc chờ đợi phản hồi.
Volumetric Attacks: Hai loại trên đều nhắm tới việc bắt ứng dụng, hệ điều hành phải tiêu tốn tài nguyên xử lý. Riêng volumetric attack nhắm tới băng thông của hệ thống victim. Ví dụ khách hàng chỉ có khả năng thuê một đường truyền có băng thông 100Mbps, attacker sẽ tìm cách flood một lượng lớn traffic lớn hơn 100Mbps, khiến con đường tới server của victim bị nghẽn (tương tự đường 2 làn, nhưng có tới 10 làn xe cùng vào một lúc sẽ gây ngẽn và những xe cần đi thật sẽ không thể di chuyển). Ví dụ Memcrashed, lợi dụng các memcached server mở UDP port ra ngoài public, attacker gửi một gói tin với source_ip được giả mạo thành source_ip của victim tới các server memcached zoombie này. Một request gửi đi chỉ với 15 bytes nhưng memcached trả về 134KB dữ liệu, và khuếch đại lên thì Cloudflare ghi nhận peak tới 260Gbps UDP traffic, đủ là nghẽn network của bất cứ hệ thống nào.

Để chống lại một cuộc tấn công DDoS thì tùy vào loại attack. Tuy nhiên đứng ở góc độ làm sản phẩm thì luôn cố gắng phục vụ tất cả các request kể cả bất hợp lệ thay vì block request vì nếu block nhầm user hợp lệ cũng coi như từ chối phục vụ dịch vụ cho khách hàng -> giúp kẻ tấn công đạt được mục đích là ứng dụng của chúng ta không thể cung cấp dịch vụ tới khách hàng. Tất nhiên ta cũng phải đánh đổi giữa việc bảo vệ phần lớn user hay cản lọc nhầm các user hợp lệ để đưa ra quyết định đúng đắn.

Một số phương pháp được đề xuất để giảm thiểu hoặc cản lọc DDoS attack như sau:

Black Hole Routing: tương tự như &> /dev/null đẩy toàn bộ traffic cả hợp lệ lẫn không hợp lệ vào hố đen. Nói cho vui, chứ méo ai lại làm như vầy, chẳng khác gì anh Quảng nổ rút dây điện, tắt server.
Rate limit request: giới hạn số lượng request mà server chấp nhận xử lý trong một khung thời gian. Hữu ích khi chống crawler hoặc brute-force login.
WAF (Web Application Firewall): bảo vệ server, ứng dụng bởi các lỗ hổng thông thường như SQL injection, XSS…
Anycast Network Diffusion: một giải thích khá là dễ hiểu từ anh lebinh, bạn có thể đọc thêm nó ở đây https://discuss.grokking.org/t/dung-trang-tinh-d-ngan-ch-n-ddos/271/5.

2. Rate Limit

Cloudflare cung cấp một tính năng cho phép control và block các traffic đáng ngờ. Tính năng này giúp tự động bảo vệ website của bạn khỏi:

DDoS attack.
brute-force login.
….

Câu hỏi đặt ra là tại sao tui phải trả tiền Cloudflare để xài tính năng này? Có giải pháp nào thay thế miễn phí, đơn giản hay không?

Tính năng limit request/minute hoặc block request không có gì mới. Ta có thể giải quyết bằng các giải pháp sau:

Limit request ở tầng application, ví dụ rack-attack.
ngx_http_limit_req_module, block ip, limit request dựa trên ngưỡng và thời gian. Có một nhược điểm của phương pháp này, dẫn tới có thể dễ dàng bypass đó là nếu sau LB có nhiều nginx, mỗi nginx sẽ có một vùng nhớ để lưu các IP block riêng, dẫn tới có thể block trên server này nhưng không block trên server kia. Đó là lý do cần một nơi lưu chung như redis ở cách tiếp cận tiếp theo.
nginx + lua + redis, tương tự như trên, nhưng ta có thể tận dụng expire/ttl của redis để ban/block một IP và sau đó unban IP đó theo expire của một key trong redis. Một ưu điểm khác là ta có thể query dữ liệu trong redis để report. nginx-lua-redis-rate-measuring là một ví dụ về việc share counter trong redis và block bằng nginx, repo này inspired từ Cloudflare’s post How we built rate limiting capable of scaling to millions of domains.
Host-based firewall như iptables/ufw -> block/limit request ở các layer thấp hơn application layer:
- Ưu điểm là block ở các layer thấp như transport layer trở xuống, request sẽ chưa kịp tới application layer, giảm tải cho web server.
- Với limit request, ta sẽ cần load thêm một số module hỗ trợ iptable -> firewall stateful -> bạn có thể đọc thêm một bài rất hay về rate-limit với iptables từ Pusher.
- Nhược điểm là không tự động cập nhật danh sách IP mới bị ban/block/limit. Để giải quyết việc cập nhật tự động có thể build một hệ thống offline để phân tích và update lại vào hệ thống firewall. Ưu điểm của việc build một hệ thống offline là impact tới hệ thống không lớn, quá trình phân tích diễn ra ở một cụm máy tính khác, nhược điểm là bạn phải có traffic và ăn một vài đợt tấn công để có đủ dữ liệu để tính toán.
Network-based firewall: các firewall nằm ngoài host như hardware firewall hoặc security group của AWS (nhưng về lý thuyết nó không được xếp vào network-based firewall). Cũng tương tự host-based firewall là việc cập nhật danh sách IP sẽ khó khăn. Và với security group của AWS thì không thể limit request (chỉ có chặn).

Nhược điểm của tất cả các phương pháp trên là:

Request của attacker đã tới hệ thống của bạn, nếu xài network-base firewall thì request đã vào tới router/hardware-firewall, nếu xài host-based firewall (iptables) thì request đã tới server (OS đã phải handle), nếu bạn limit ở tầng application thì web server (nginx hoặc Apache) đã phải xử lý (tuy nhiên nếu xài nginx như một proxy thì cũng không tốn thêm bao nhiêu resource) và nếu bạn xài một thư viện như rack-attack thì Rails phải handle thêm việc giới hạn request.
Thêm thiết bị, máy tính, software để xử lý vấn đề (sẽ không phù hợp với hệ thống nhỏ).

Vậy nếu xài rate-limit của Cloudflare thì có lợi gì?

Cloudflare sẽ hoạt động như một reverse proxy, mọi request trước khi đi tới origin server của bạn đều sẽ đi qua Cloudflare.
Băng thông của Cloudflare là 30Tbps, gấp 15 lần cuộc tấn công DDoS lớn nhất từng được ghi nhận (chắc là memcrashed), với sổ hộ nghèo, bạn chỉ thuê được băng thông 100Mbps. Cloudflare sẽ hoạt động như BOT (trạm thu phí) giữa quốc lộ và đường làng, giúp bóp nhỏ / cản lọc bớt traffic trước khi tới server của bạn, không làm overload network của bạn (thông thường nếu bạn host server ở DC, khi gặp một cuộc tấn công volumetric attacks, bạn cũng có thể nhờ DC tăng băng thông để chống chọi hoặc nhờ Firewall/Router của DC cản lọc bớt traffic trước khi vào server của bạn, tương tự như Cloudflare).
Dễ cấu hình ngưỡng, URL và có report để xem.
Thông minh, tự động nhận biết các request không hợp lệ, có thể expire sau một khoảng thời gian (tương tự lua+redis), cho phép user tự bypass bằng cách pass challenge hoặc js challenge thay vì block ngay.
Nhược điểm là phải trả tiền cho tính năng này và Cloudflare offer số lượng rule khá thấp (Pro là 10 rule, Business 15 rule và Enterprise rule), nên cần nhiều rule limit thì Cloudflare là một lựa chọn khá đắt đỏ.s

rate-limit

Nếu bạn xài terraform 0.11 thì nó sẽ như sau:

resource "cloudflare_rate_limit" "rl_login" {
  zone = "${var.domain}"

  threshold = 20
  period = 60
  
  match {
    request {
      url_pattern = "${var.domain}/login"
      schemes = ["HTTP", "HTTPS"]
      methods = ["POST"]
    }
    response {
      statuses = [401, 403]
      origin_traffic = true
    }
  }
  
  action {
    mode = "ban"
    timeout = 3600
  }
  disabled = false
  description = "Block IPs exceeding 20 request per minutes (20 in 60) for 1 hour to login pattern."
}

Update cực mạnh:

Với tính năng rate-limit như mô tả ở trên, có vẻ là một giải pháp hoàn hảo khi giới hạn khả năng gửi request của attacker ngay lại level proxy. NHƯNG toy đã lầm khi nhìn thấy billing của Cloudflare.

cf_billing

Theo mô tả về giá của Cloudflare thì “Only Pay for Good Traffic. Not Bad”, nghĩa là với các rule được định nghĩa, thì tiền sẽ chỉ tính trên các request match với rule và không bị chặn bởi Cloudflare. Free cho 10_000 good request đầu tiên và mỗi $0.05 cho 10_000 good request tiếp theo.
Giả sử toy mà biết ông nào xài tính năng này của Cloudflare, đặc biệt các request đơn giản không yêu cầu header/method gì đặc biệt, toy làm một cụm proxy để rotate-ip, send slow request thì tháng đó công ti đó chắc cũng toangggg 😑😑😑.

3. Proxy

3.1 Proxy 101

Để xài được tính năng như rate-limit thì bạn phải cho phép request của user đi qua hệ thống Cloudflare trước khi tới server của bạn, đó chính là Proxy trong Cloudflare.

Proxy có thể được chia làm 2 loại, khác nhau ở vị trí đặt và mục đích sử dụng:

Forward Proxy:

{clientA, clientB, clientC} ——> forward proxy (F) ——> Internet (I) ——> {origin-serverA, origin-serverB}

Với người dùng, dùng forward proxy giúp họ bypass được các giới hạn truy cập website. Nó hơi giống với VPN, forward proxy sẽ thay người dùng gửi request tới website bạn muốn truy cập thay vì kết nối trực tiếp.
Với người quản trị hệ thống, họ có thể đặt một forward proxy trong mạng nội bộ của họ và ép tất cả các client phải đi qua forward proxy này trước khi kết nối ra Internet. Việc này đem lại 2 lợi ích, thứ nhất đó là caching các dữ liệu mà người dùng thường xuyên truy cập và thứ hai là có thể cản lọc, chặn truy cập một số website, ứng dụng (ví dụ chặn không có user trong mạng nội bộ truy cập Facebook.com).
Ẩn danh, tương tự như VPN.

Reverse proxy

{clientA, clientB, clientC} ——> Internet (I) ——> reverse proxy (R)——> {origin-serverA, origin-serverB}

Một ví dụ quen thuộc của reverse proxy đó là bạn xài nginx upstream trước các backend server. Lợi điểm của việc dùng reverse proxy đó là:

Load balancing -> chia request từ client tới nhiều backend server với các thuật toán khác nhau. Giúp điều tiết lượng request tới backend server.
Protection from attack -> mọi request từ client sẽ phải đi qua reverse proxy, bạn có thể apply các rule trên reverse proxy để cản lọc request trước khi tới backend server (tương tự như rate-limit/WAF ở trên). Bản chất của proxy là nhận và pass request đi nên các xử lý trên proxy là khá nhẹ nhàng.
Global Server Load Balancing -> tương tự như load balacing nhưng ở cấp độ global, reverse proxy sẽ nhận biết được là backend server nào gần với client và chuyển hướng request của client tới backend server gần nhất để giảm latency, load time.
Caching -> request của client vẫn phải tới infra của site, tuy nhiên việc caching sẽ nằm ở infra của site (khác với caching ở forward proxy nằm ở network của client), mục đích cũng tương tự là giảm response time.
SSL encryption -> đẩy phần encrypt/decrypt ra reverse proxy, kết nối từ reverse proxy tới backend server là HTTP.

Ở đây ta sẽ chỉ nói tới reverse proxy, thứ mà rất quen thuộc khi vận hành một hệ thống website/api. Tuy nhiên điểm khác biệt là bạn thường đặt reverse proxy trong hệ thống mạng của bạn, còn với Cloudflare thì chức năng tương tự, nhưng proxy nằm bên ngoài hệ thống mạng của bạn và với băng thông 30Tbps, Cloudflare đủ sức hứng mọi đợt tấn công trước khi tới origin server của bạn.

ddos-illustrations-2

Ví dụ website của bạn có địa chỉ IP là 1.2.3.4, khi bật tính năng proxy, domain website của bạn sẽ được phân giải IP thành một địa chỉ IP thuộc lớp mạng của Cloudflare như 104.20.148.78, và user/attacker sẽ không biết được địa chỉ origin server của bạn.

3.2 SSL/TLS

Đi kèm với Proxy, Cloudflare cung cấp một giải pháp SSL/TLS miễn phí cho các khách hàng nhỏ giúp tăng cường bảo mật cho website. Traffic từ client tới Cloudflare sẽ luôn luôn được mã hóa, traffic từ Cloudflare tới Origin server thì phụ thuộc vào cấu hình với các tùy chọn như sau:

Flexible SSL
Full SSL
- Strict (cert issued by Certificate Authority).
- Full (cert issued by Cloudflare (Origin CA)).
- Self-signed certificate.

Flexible SSL sẽ mã hóa traffic từ Cloudflare tới end-user, nhưng không mã hóa traffic từ Cloudflare tới origin server của bạn. Ưu điểm là dễ dàng cài đặt HTTPs cho user nhưng không yêu cầu phải cài đặt SSL certificate trên server của bạn. Mặc dù không an toàn như các tùy chọn khác nhưng Flexsible SSL là cách nhanh chóng, dễ dàng để bảo vệ user khỏi các mối nguy hiểm từ public Wifi hoặc ad injection over HTTP. Về traffic từ Cloudflare tới origin server của bạn, đặt niềm tin hoàn toàn vào Cloudflare rằng traffic của bạn sẽ không bị lộ ra bên ngoài (capture traffic khi vừa ra khỏi Cloudflare).

flexible-ssl

Full SSL sẽ mã hóa traffic ở cả 2 đầu là từ Cloudflare tới end-user và từ Cloudflare tới origin server của bạn, có ba tùy chọn khác nhau cho việc cài đặt cerfiticate trên server của bạn là:

Full SSL Strict -> certificate cài đặt trên origin server của bạn được cấp bởi một public Certificate Authority (ví dụ Verisign, Digicert hoặc Comodo).
Full SSL, Origin CA -> certificate cài đặt trên origin server của bạn được cấp bởi Cloudflare.
Full SSL, self-signed certificate -> certificate tự gen.

full-ssl

Với Strict, certificate được cấp bởi CA cần tốn chi phí để mua và gia hạn. Với Origin CA, cert được cấp bởi Cloudflare, miễn phí và có expire time khá lâu, dễ dàng rotate nên Cloudflare recomment xài Origin CA.

3.3 Cloudflarefuck?

Nếu bạn từng vào trang tuyển dụng của Cloudflare, đọc thử một job description, bạn sẽ thấy một câu Cloudflare powers Internet requests for ~10% of the Fortune 1,000 for more than 1 billion unique IP addresses per day.

cloudflare-stats

Vậy câu hỏi là nếu Cloudflare sập thì chuyện gì xảy ra 😳 🔥 🚒, sẽ chỉ có 10% traffic trên toàn thế giới bị ảnh hưởng. Nghe mà đã rụng cmn rời.

Trong tầm khoảng 10 ngày, Cloudflare xảy ra 2 network issues lớn:

Massive route leak: theo post-mortem từ Cloudflare thì lỗi là do Verizon (một nhà mạng rất lớn), ảnh hưởng tới rất nhiều provider lớn như Amazon, Linode and Cloudflare. Sự cố này mất 2 tiếng đồng hồ để giải quyết.
Cloudflare outage caused by bad software deploy: issue này được Cloudflare mô tả là do:
- Deploy một bộ rule cho dịch vụ WAF để tối ưu việc block inline Javascript thường được sử dụng trong các cuộc tấn công.
- Có một rule xài regular expression khiến CPU spike lên 100%.
- Drop 82% traffic của Cloudflare và ảnh hưởng tới rất rất nhiều region trên toàn thế giới.
- Một lượng lớn các công ty lớn bị ảnh hưởng như Coinbase, Authy, Discord, Medium, Zendesk ….
- Đã test ở một môi trường giả định, nhưng không có đủ traffic để đánh giá impact trên production.
- Giải pháp là rollback lại bản deployment, nhưng sự cố này cũng mất 1 tiếng để điều tra và giải quyết.

Ảnh hưởng của 2 sự cố trên là request từ user đi qua Cloudflare không thể tới được origin server (tính năng proxy của Cloudflare). Riêng với issue thứ hai, do hệ thống của chính Cloudflare cũng sập nên người dùng cũng không thể access được dashboard của Cloudflare.

Vậy giải pháp là gì khi gặp tình huống như trên?

Nằm chịu chết, chờ cho tới khi dịch vụ Cloudflare phục hồi.
Nếu xài SSL/TLS Full Strict thì có thể tắt tính năng proxy của Cloudflare đi
- Traffic sẽ đi trực tiếp từ user tới origin server của bạn.
- Các rule về cản lọc bad request trên Cloudflare sẽ không còn tác dụng.
- Sẽ không thể thực hiện nếu bản thân dashboard của Cloudflare cũng chết 😑.
- Liệu hạ tầng DNS của Cloudflare có chết luôn hay không? 😑
- Và bắt buộc bạn ko được xài Flexsible SSL hoặc self-sign cert vì khi bạn tắt proxy, HTTPS trên site của bạn sẽ không đáng tin cậy và dịch vụ của bạn cũng không thể cung cấp.

Vấn đề tiếp theo là liệu TẮT PROXY có phải là giải pháp?

3.4 Find IP origin server

Mục tiêu của việc xài Cloudflare proxy là để ẩn IP của origin server và không cho kẻ tấn công biết được origin server, tránh trường hợp bị attack trực tiếp vào server thay vì đi qua bộ lọc của Cloudflare (hoặc crawler bypass bộ lọc). Thế nên khi Cloudflare gặp sự cố, bạn tắt Proxy đi nghĩa là đã tạo ra một lỗ hổng để attacker tấn công trực tiếp vào hệ thống, lúc này việc có Cloudflare cũng không còn mấy tác dụng.

Đứng ở góc độ attacker, nếu site đã xài Cloudflare proxy thì có cách nào để biết được IP của orgin server hay không?

Việc xác định một site có sử dụng dịch vụ Cloudflare cũng khá dễ dàng, ta có thể:

> curl -I https://medium.com
HTTP/2 200
date: Fri, 12 Jul 2019 05:55:11 GMT
content-type: text/html; charset=utf-8
set-cookie: __cfduid=dd3119117ce323927a453c7b298401b0e1562910911; expires=Sat, 11-Jul-20 05:55:11 GMT; path=/; domain=.medium.com; HttpOnly
content-security-policy: default-src 'self'; connect-src https://localhost https://*.instapaper.com https://*.stripe.com https://glyph.medium.com https://*.paypal.com https://getpocket.com https://medium.com https://*.medium.com https://*.medium.com https://medium.com https://*.medium.com https://*.algolia.net https://cdn-static-1.medium.com https://dnqgz544uhbo8.cloudfront.net https://cdn-videos-1.medium.com https://cdn-audio-1.medium.com https://*.lightstep.com https://*.branch.io https://app.zencoder.com 'self'; font-src data: https://*.amazonaws.com https://*.medium.com https://glyph.medium.com https://medium.com https://*.gstatic.com https://dnqgz544uhbo8.cloudfront.net https://use.typekit.net https://cdn-static-1.medium.com 'self'; frame-src chromenull: https: webviewprogressproxy: medium: 'self'; img-src blob: data: https: 'self'; media-src https://*.cdn.vine.co https://d1fcbxp97j4nb2.cloudfront.net https://d262ilb51hltx0.cloudfront.net https://*.medium.com https://gomiro.medium.com https://miro.medium.com https://pbs.twimg.com 'self' blob:; object-src 'self'; script-src 'unsafe-eval' 'unsafe-inline' about: https: 'self'; style-src 'unsafe-inline' data: https: 'self'; report-uri https://csp.medium.com
x-frame-options: sameorigin
x-content-type-options: nosniff
x-xss-protection: 1; mode=block
x-ua-compatible: IE=edge, Chrome=1
x-powered-by: Medium
x-obvious-tid: 1562910911357:c3d601539378
x-obvious-info: 38086-f2efc7b,f2efc7bd3f5
link: <https://medium.com/humans.txt>; rel="humans"
cache-control: no-cache, no-store, max-age=0, must-revalidate
expires: Thu, 09 Sep 1999 09:09:09 GMT
pragma: no-cache
tk: T
strict-transport-security: max-age=15552000; includeSubDomains; preload
set-cookie: uid=lo_L3g8wBpz5tvb; Expires=Sat, 11-Jul-20 05:55:11 GMT; Domain=.medium.com; Path=/; Secure; HttpOnly
set-cookie: sid=1:5/Xr4XX2PjlG2TtQTn1ERsmMMjpOJ71eZvf4NMZMLbseEW3NrI5Yb2WFRlOsXXe8; path=/; expires=Sat, 11 Jul 2020 05:55:11 GMT; domain=.medium.com; secure; httponly
set-cookie: __cfruid=0b37c1d5c8324ea472c0072a4c6f285ffc596078-1562910911; path=/; domain=.medium.com; HttpOnly
expect-ct: max-age=604800, report-uri="https://report-uri.cloudflare.com/cdn-cgi/beacon/expect-ct"
server: cloudflare
cf-ray: 4f50c44b398ad1e7-HKG

Một số header dùng để xác định như cf-ray, __cfduid hoặc check IP phân giải có thuộc lớp mạng của Cloudflare hay không:

> dig +short medium.com
104.16.121.127
104.16.124.127
104.16.122.127
104.16.120.127
104.16.123.127

3.4.1 SSL certificate

Mỗi Domain Validation SSL certificate mà bạn mua sẽ valid với một domain name. Ý tưởng là bạn cần scan toàn bộ internet để tìm một địa chỉ IP nào đó trên cổng 443 có SSL certificate match với domain-name mà bạn đang tìm kiếm.

Censys là một dịch vụ cho phép query các dữ liệu kiểu như vậy. Miễn phí 10 query cho un-login user và 200 query/tháng cho free user.

Ví dụ với site https://viblo.asia, domain của họ phân giải thành địa chỉ của Cloudflare

> dig +short viblo.asia
104.27.188.151
104.27.189.151

Tuy nhiên khi query trên Censys (443.https.tls.certificate.parsed.names: viblo.asia OR 443.https.tls.certificate.parsed.subject.common_name: viblo.asia) thì kết quả là:

censys_viblo

Trông có vẻ họ có 3 server phía sau Cloudflare và host trên Linode, ngoài ra họ cũng mở cổng 22 và 8080 trên các node.

Một ví dụ khác là Medium, bạn có thể xem kết quả search từ Censys từ file medium.txt. Một điểm thú vị ở đây là mình nhìn thấy có 17 node EC2 từ dịch vụ AWS public ra ngoài Internet, không rõ mục đích của họ khi thiết kế Infra như vậy là có dụng ý gì, mình đoán là họ đang xài Global Load Balancing của Cloudflare thay vì ALB của AWS, nhưng khó hiểu là các EC2 này đều nằm ở 1 AS và cùng một region là Ashburn, Virginia 🤔.

> grep '.amazonaws' medium.txt
 52.1.147.205 (ec2-52-1-147-205.compute-1.amazonaws.com)
 52.6.3.192 (ec2-52-6-3-192.compute-1.amazonaws.com)
 54.167.232.247 (ec2-54-167-232-247.compute-1.amazonaws.com)
 52.4.175.111 (ec2-52-4-175-111.compute-1.amazonaws.com)
 3.94.121.79 (ec2-3-94-121-79.compute-1.amazonaws.com)
 52.5.181.79 (ec2-52-5-181-79.compute-1.amazonaws.com)
 52.1.173.203 (ec2-52-1-173-203.compute-1.amazonaws.com)
 52.4.145.119 (ec2-52-4-145-119.compute-1.amazonaws.com)
 52.6.46.142 (ec2-52-6-46-142.compute-1.amazonaws.com)
 52.0.16.118 (ec2-52-0-16-118.compute-1.amazonaws.com)
 52.4.225.124 (ec2-52-4-225-124.compute-1.amazonaws.com)
 52.6.25.83 (ec2-52-6-25-83.compute-1.amazonaws.com)
 52.206.109.232 (ec2-52-206-109-232.compute-1.amazonaws.com)
 54.208.127.235 (ec2-54-208-127-235.compute-1.amazonaws.com)
 52.4.38.70 (ec2-52-4-38-70.compute-1.amazonaws.com)
 34.204.47.92 (ec2-34-204-47-92.compute-1.amazonaws.com)
 52.1.119.170 (ec2-52-1-119-170.compute-1.amazonaws.com)

Nói chung có thể search nhiều thứ với Censys, ngoài domain-name validate với certificate, ta cũng có thể search fingerprint của SSL certificate.

3.4.2 DNS records

Sau một vài đợt chống chọi với các cuộc tấn công, bạn quá mệt mỏi và quyết định chuyển sang xài Cloudflare. Vấn đề là history về DNS records của bạn vẫn còn lưu đâu đó trên Internet và SecurityTrails là dịch vụ cho phép query history của DNS record.

security_trails_medium

Ngoài thông tin về history DNS record, còn có các thông tin khác như:

Subdomain -> có thể sẽ có những subdomain không đi qua Cloudflare nhưng chung origin server.
Các history của các record khác như MX (mail), NS (máy chủ DNS)

3.4.3 HTTP header hoặc Content

Ví dụ search với title của Medium bằng Censys.

443.https.get.title: "Medium – a place to read and write big ideas and important stories"

Hoặc các content unique trên website như Google Analytics tracking code:

googleAnalyticsTrackingCode":"UA-24232453-2"

Công cụ như https://www.shodan.io cho phép search các thông tin như vậy tuy nhiên nó yêu cầu bạn phải trả phí để truy cập các dữ liệu trên.

4. Prevention

Câu hỏi bây giờ là làm thế nào để ẩn danh IP origin server bởi các công cụ tìm kiếm hoặc historical DNS record? Và cách cấu hình Cloudflare để chống lại các tấn công vào origin server là như thế nào?

Log real client-ip của user khi đi qua Cloudflare.
Remove tất cả các DNS record không còn sử dụng (tránh để lộ origin server cũ).
Chạy email trên các server hoặc dịch vụ riêng (gsuite, sendgrid).
Sau khi chuyển sang Cloudflare, nên đổi tất cả các IP server cũ.
Whitelist các request từ hệ thống Cloudflare (IPv4 và IPv6) và các IP từ hệ thống của bạn (nếu có nhu cầu testing), phần còn lại nên block.

Có thể block ở tầng firewall như security group hoặc transport layer (iptables) hoặc block ở nginx của site, ví dụ với iptables.

sudo iptables -I INPUT 1 -i lo -j ACCEPT
sudo iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

sudo iptables -A INPUT -p tcp -s 103.21.244.0/22 --dport 443 -j ACCEPT
sudo iptables -A INPUT -p tcp -s 103.22.200.0/22 --dport 443 -j ACCEPT
sudo iptables -A INPUT -p tcp -s 103.31.4.0/22 --dport 443 -j ACCEPT
sudo iptables -A INPUT -p tcp -s 104.16.0.0/12 --dport 443 -j ACCEPT
sudo iptables -A INPUT -p tcp -s 108.162.192.0/18 --dport 443 -j ACCEPT
sudo iptables -A INPUT -p tcp -s 131.0.72.0/22 --dport 443 -j ACCEPT
sudo iptables -A INPUT -p tcp -s 141.101.64.0/18 --dport 443 -j ACCEPT
sudo iptables -A INPUT -p tcp -s 162.158.0.0/15 --dport 443 -j ACCEPT
sudo iptables -A INPUT -p tcp -s 172.64.0.0/13 --dport 443 -j ACCEPT
sudo iptables -A INPUT -p tcp -s 173.245.48.0/20 --dport 443 -j ACCEPT
sudo iptables -A INPUT -p tcp -s 188.114.96.0/20 --dport 443 -j ACCEPT
sudo iptables -A INPUT -p tcp -s 190.93.240.0/20 --dport 443 -j ACCEPT
sudo iptables -A INPUT -p tcp -s 197.234.240.0/22 --dport 443 -j ACCEPT
sudo iptables -A INPUT -p tcp -s 198.41.128.0/17 --dport 443 -j ACCEPT
sudo iptables -A INPUT -p tcp -s 199.27.128.0/21 --dport 443 -j ACCEPT

sudo iptables -A INPUT -p tcp --dport 22 -j ACCEPT
sudo iptables -A INPUT -j REJECT

Với nginx có thể block như sau:

map $remote_addr $bad_ip {
  default 1;
  cloudflare_ip_v4 0;
  cloudflare_ip_v6 0;
}

server {
  if ($bad_ip) {
    return 499;
  }
}

Ngoài các giải pháp trên, Cloudflare cung cấp một dịch vụ gọi là Argo tunnel, hiểu một cách đơn giản thì argo-tunnel sẽ tạo một encrypted-tunnel giữa origin server tới Cloudflare data-center gần nhất (kèm theo smart routing), mọi kết nối từ client được Cloudflare pass qua origin server sẽ đi qua tunnel này, tất cả các request còn lại sẽ bị block.

5. End

Yeah, quá nhiều câu hỏi, quá nhiều chữ rồi, vậy nếu lỡ Cloudflare tạch proxy thì phải làm sao? Thật ra toy cũng đíu biết ae ạ 🖕🏽🖕🏽🖕🏽, lên Twitter xem dân tình chửi nhau và nằm chờ Cloudflare sống dậy thôi.

notlikethis