cattrang_qb12
Búa Gỗ
Bài viết do blog.vietnix.vn các bạn có thể đọc chi tiết tại nguồn . Thấy diễn đàn Vn-Zoom từng bị DDoS nhiều lần với thời gian dài, nên copy về đây để anh em BQT cũng như các bạn Vn-Zoom tham khảo thêm.
Với sự phát triển của các dịch vụ tấn công DDoS (DDoS for Hire) như hiện nay, chỉ với một chi phí nhỏ, bất kỳ ai cũng có thể triển khai một cuộc tấn công DDoS để triệt hạ mục tiêu với các phương thức tấn công được weaponized mà không cần hiểu biết nhiều về kỹ thuật.
Tấn công thì đơn giản nhưng việc chống tấn công DDoS thì hết sức phức tạp, đỏi hỏi rất nhiều kiến thức và kinh nghiệm. Phần lớn khi bị tấn công đều được khuyên đưa website chạy qua CloudFlare để chặn DDoS. Tuy nhiên, không phải trường hợp nào đưa qua CloudFlare cũng hiệu quả, và các công cụ tấn công DDoS hiện nay đều được tích hợp phương thức để bypass CloudFlare. Trong loạt bài viết này, Vietnix sẽ chia sẻ về:
CloudFlare là một Reverse Proxy đứng giữa người dùng (User) và Server chạy website của bạn (được gọi là Backend hoặc Origin Server), hoạt động ở Layer 7 (Application Layer). Các request của User sẽ được web server của CloudFlare tiếp nhận, phân tích và xử lý. Nếu CloudFlare cho rằng request đó là hợp lệ thì CloudFlare sẽ kết nối về Backend để lấy data và trả kết quả (response) về cho người dùng. Do đó:
IP nhận được phía Backend là IP của CloudFlare
Xem thêm: CloudFlare là gì & Cách hoạt động của CloudFlare
Mặc định, CloudFlare không cache HTML mà chỉ cache các static content, trừ khi chúng ta setup Page Rule để “Cache Everything”. Nếu chưa setup page rule, các request DDoS do botnet gửi lên sẽ được CloudFlare đẩy toàn bộ về Backend.
Cache Everything kết hợp các thông số như: zone_id, scheme, hostname, request_uri làm cache_key.
Ví dụ: có ta có URL “https://vietnix.vn/?fbclid=IwAR0nKKu3“, giá trị tương ứng của các biến sẽ như sau:
=> cache key = md5sum($zone_id:$scheme://$hostname$request_uri) = md5sum(123abc:https://vietnix.vn/?fbclid=IwAR0nKKu3) = 258580a80ba7e32b9c46dad524877118
CloudFlare sử dụng Nginx làm nền tảng để phát triển web server của họ, do đó, ta có thể xem cơ chế xử lý cache của CloudFlare tương tự như Nginx. cache_key sẽ được hash (md5sum) thành một string dùng để phân biệt các cache entry với nhau. Nếu 2 request có cùng 1 kết quả hash thì sẽ được phục vụ từ cùng 1 file cache. Trường hợp file cache chưa tồn tại (cache MISS) thì CloudFlare sẽ request về Backend để lấy data.
Xem thêm: Cơ chế hoạt động & Hướng dẫn cấu hình NGINX cache
Mục tiêu DDoS bypass CloudFlare là đẩy càng nhiều request về Backend càng tốt để làm quá tải nó. Bằng cách làm cho kết quả hash giữa các request khác nhau sẽ gây ra tình trạng cache MISS và các request sẽ được đẩy hết về backend.
Nhìn lại cấu trúc cache key mặc định của CloudFlare, các tham số như zone_id, hostname là cố định, scheme thì chỉ có 2 lựa chọn http hoặc https, biến còn lại request_uri bao gồm URI + Query String, cả 2 tham số này đều dễ dàng bị thay đổi bởi User. Bằng việc Random URI hoặc Query String, hệ thống cache của CloudFlare sẽ bị bypass. CloudFlare cho phép chúng ta custom cache key (sử dụng $uri làm key, bỏ qua $query_string) nhưng tính năng này chỉ available cho các khách hàng sử dụng gói Enterprise (giá 200$/tháng).
DDoS bypass CloudFlare – Random URL
DDoS bypass CloudFlare – Random Query String
DDoS bypass CloudFlare – POST method
Tuy nhiên, điều quan trọng nhất, để tạo được request, các botnet phải thành công trong quá trình thiết lập kết nối ở tầng Network (qua được quá trình bắt tay 3 bước), và chỉ có những client thực sự – có real IP – không phải spoofed IP mới qua được bước này (mình sẽ có 1 bài chi tiết nói về vấn đề này, nó quan trọng vì sẽ quyết định cách tiếp cận chống DDoS của chúng ta). Vậy nên, số lượng IP của botnet là hữu hạn, hướng tiếp cận của chúng ta là xác định các IP của botnet đưa chúng vào Firewall. Khi DDoS bypass CloudFlare, muốn đánh sập backend, các botnet cần tạo ra tần số đủ lớn, vượt qua khỏi khả năng chịu tải của backend:
Đây là cơ sở quan trọng nhất để chúng ta xác định đâu là botnet và đâu là người dùng hợp lệ: rate limit
Một mindset cực kỳ quan trọng mà Hưng đã đúc kết qua gần 10 năm chống lại hàng ngàn cuộc tấn công DDoS mà các bạn khi mới tiếp cận thường mắc phải: Chúng ta không cần chặn 100% botnet, mục tiêu cuối cùng là giữ server hoạt động ổn định và phục vụ người dùng hợp lệ một cách bình thường. Do đó, không cần phải siết quá chặt để dẫn đến chặn nhầm người dùng thật, ảnh hưởng đến trải nghiệm. Nếu để lọt một vài botnet có tần số thấp và truy cập của chúng không đủ sức gây ảnh hưởng đến server thì không nhất thiết phải tìm cách chặn, hãy kệ chúng!
Rate limit giúp kiểm soát tần số truy cập của mỗi IP vào server, nếu tần số truy cập lớn hơn quy định thì truy cập đó sẽ bị từ chối và bị ghi log lại. Do web server sẽ tính toán tần số truy cập dựa trên IP nên yêu cầu web server phải nhận biết được IP thật của người dùng.
Quan trọng: đọc kỹ bài viết này để nắm rõ cơ chế hoạt động của Nginx Rate Limiting, chuẩn bị sẵn sàng cho phần cấu hình backend ở Phần 2 của bài viết: Cơ chế hoạt động & Hướng dẫn cấu hình NGINX rate limit
Với trường hợp web server nằm sau CloudFlare, các kết nối backend nhận thấy đều mang source IP của CloudFlare nên không thể áp dụng rate limit lên các IP này. Vị trí tuyệt vời để triển khai rate limit trong mô hình này tất nhiên là CloudFlare, và tin buồn là tính năng này không miễn phí (of course
)
Nhưng đừng lo, nếu backend sử dụng Nginx ta sẽ tự triển khai tính năng này. module http_realip sẽ thay thế IP của CloudFlare ở web server (biến $remote_addr) thành IP của client và giúp các module khác hoạt động dựa trên biến $remote_addr (module allow/deny ip, log …) sẽ hoạt động chính xác như thể server đang kết nối trực tiếp với client, bao gồm module rate_limit.
Lưu ý: module trên chỉ có tác dụng đối với logic của Nginx, đối với các ứng dụng khác hoặc ở tầng network thì kết nối vẫn mang source IP của CloudFlare. Vậy làm thế nào để kết hợp CSF – một network Firewall hoạt động ở Layer 3, 4 với CloudFlare để chống tấn công DDoS? Đáp án sẽ có ở phần 2 của bài viết.
Phần 1 chủ yếu tập trung về lý thuyết và hướng tiếp cận để chống DDoS bypass CloudFlare. Phần 2 của bài viết mình sẽ hướng dẫn chi tiết cách cấu hình ở backend. Phần 3 sẽ là những kỹ thuật nâng cao, tool tự động hóa và các cấu hình tối ưu cần thực hiện trên CloudFlare.
phần 1 của bài Hướng dẫn chống DDoS bypass CloudFlare bằng CSF Firewall, mình đã giải thích rõ về:
Cloudflare là 1 Reverse Proxy hoạt động ở Layer 7 và CloudFlare thay mặt client để kết nối đến backend server lấy data. Do đó:
Chúng ta sẽ cấu hình NGINX sử dụng module http_realip để thay thế giá trị của header “CF-Connecting-IP” vào giá trị của biến $remote_addr. Qua đó, giúp các module hoạt động dựa giá trị của biến $remote_addr (ví dụ module log, rate limit) hoạt động dựa trên giá trị IP thực của người dùng.
Xem thêm: Hướng dẫn cài đặt module real ip cho NGINX
Để NGINX nhận diện IP thực của người dùng, thêm danh sách ipv4 và ipv6 của CloudFlare vào phần set_real_ip_from. Tạo file /etc/nginx/conf/cloudflare.conf với nội dung như sau:
set_real_ip_from 103.21.244.0/22;
set_real_ip_from 103.22.200.0/22;
set_real_ip_from 103.31.4.0/22;
set_real_ip_from 104.16.0.0/12;
set_real_ip_from 108.162.192.0/18;
set_real_ip_from 131.0.72.0/22;
set_real_ip_from 141.101.64.0/18;
set_real_ip_from 162.158.0.0/15;
set_real_ip_from 172.64.0.0/13;
set_real_ip_from 173.245.48.0/20;
set_real_ip_from 188.114.96.0/20;
set_real_ip_from 190.93.240.0/20;
set_real_ip_from 197.234.240.0/22;
set_real_ip_from 198.41.128.0/17;
set_real_ip_from 2400:cb00::/32;
set_real_ip_from 2606:4700::/32;
set_real_ip_from 2803:f800::/32;
set_real_ip_from 2405:b500::/32;
set_real_ip_from 2405:8100::/32;
set_real_ip_from 2c0f:f248::/32;
set_real_ip_from 2a06:98c0::/29;
real_ip_header CF-Connecting-IP;
include file “cloudflare.conf” vào nginx.conf ở context http:
http {
...
include "/etc/nginx/conf/cloudflare.conf";
...
}
Kiểm tra lại config NGINX:
nginx -t
Restart nginx
systemctl restart nginx
Log mặc định của NGINX sử dụng format combined, được định nghĩa như sau:
log_format combined '$remote_addr - $remote_user [$time_local] '
'"$request" $status $body_bytes_sent '
'"$http_referer" "$http_user_agent"';
Format này sử biến $remote_addr làm IP của client. Sau khi config sử dụng module Real IP, hãy tiến hành kiểm tra access log xem đã ghi log được IP thật của người dùng hay chưa:
112.197.118.134 - - [21/Mar/2021:13:17:57 +0700] "GET / HTTP/1.1" 200 10179 "https://www.google.com/" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:86.0) Gecko/20100101 Firefox/86.0"
Whois IP để xem IP trên thuộc nhà mạng nào, nếu không phải của CloudFlare là thành công:
Thông tin cho thấy log ghi nhận IP của User Việt Nam
NGINX đã nhận biết được IP thực của người dùng thay vì IP của CloudFlare. Các module khác như allow, deny IP, rate limiting đã có thể sử dụng.
Khi load một URL, ngoài việc load nội dung (content) của URL, browser còn phải load các static content khác để có thể render thành một web page hoàn chỉnh như: image, javascript, css, font, icon … Điều này có nghĩa khi load một URL, client không chỉ tạo một request đến server mà là nhiều request. Do đó, để giới hạn tần số hiệu quả, ta cần tối ưu như sau:
Ví dụ:
server {
...
location ~* \.(swf|ogg|ogv|svg|svgz|eot|otf|woff|mp4|ttf|css|rss|atom|js|jpg|jpeg|gif|png|ico|tgz|gz|rar|bz2|tar|mid|midi|wav|bmp|rtf|woff|woff2|mo|zip|txt)$ {
expires max;
}
location = / {
proxy_pass https://127.0.0.1:8080;
}
location / {
proxy_pass https://127.0.0.1:8080;
}
}
Để cấu hình rate limit, cần thực hiện 2 bước: khai báo limit_req_zone và khai báo limit_req.
Chi tiết về thuật toán, cách cấu hình, ý nghĩa các tham số tham khảo tại: Hướng dẫn cấu hình giới hạn tần số truy cập với NGINX
Ở bước 1, ta đã config NGINX nhận được real IP của client, ta có thể dùng biến $binary_remote_addr để làm key.
Giới hạn tần số truy cập như sau:
File virtual host blog.vietnix.vn.conf sẽ có nội dung:
limit_req_zone $binary_remote_addr zone=location_index:10m rate=3r/s; # khai báo zone cho page index
limit_req_zone $binary_remote_addr zone=location_catchall:10m rate=5r/s; # khai báo zone choh catch all location
server {
...
server_name blog.vietnix.vn;
index index.php;
access_log /var/log/nginx/access_log combined;
error_log /var/log/nginx/error_log error;
root /var/www/vietnix.vn/
location ~* \.(swf|ogg|ogv|svg|svgz|eot|otf|woff|mp4|ttf|css|rss|atom|js|jpg|jpeg|gif|png|ico|tgz|gz|rar|bz2|tar|mid|midi|wav|bmp|rtf|woff|woff2|mo|zip|txt)$ {
expires max;
}
location = / {
limit_req zone=location_index burst=3 nodelay;
proxy_pass https://127.0.0.1:8080;
}
location / {
limit_req zone=location_catchall burst=10 delay=7;
proxy_pass https://127.0.0.1:8080;
}
}
Tác dụng:
Các IP truy cập quá tần số quy định sẽ bị ghi log vào file error_log với nội dung như sau:
2021/03/29 15:53:24 [error] 8564#0: *24818 limiting requests, excess: 4.544 by zone "location_index", client: 3.140.197.140, server: blog.vietnix.vn, request: "GET / HTTP/1.1", host: "blog.vietnix.vn"
Trong đó:
Để tránh request của các IP này không truy cập được về backend nữa, ta cần tiến hành block IP của chúng trên CloudFlare. Để tất cả IP tấn công tự động bằng cách theo dõi file error log và tự động add chúng vào Firewall trên CloudFlare, ta sử dụng CSF Firewall
Hướng dẫn cài đặt CSF tham khảo tại đây: Hướng dẫn cài đặt CSF
CSF có khá nhiều tính năng hay, mình sẽ làm 1 series bài chi tiết về CSF sau. Trong phạm vi bài viết này, các bạn chỉ cần quan tâm điều chỉnh các thông số được liệt kê bên dưới.
Mở file cấu hình /etc/csf/csf.conf và điều chỉnh thành giá trị như sau:
# Enable Firewall
TESTING = 1
# Khai báo các TCP Port cho phép client kết nối đến Server
TCP_IN = "22,80,443"
# Khai báo các TCP port cho phép server kết nối ra ngoài
TCP_OUT = "1:65535"
# Khai báo các UDP port cho phép client kết nối đến server
UDP_IN = ""
# Khai bác các UDP port cho phép server kết nối ra ngoài
UDP_OUT = "1:65535"
# Nâng giới hạn Deny IP
DENY_IP_LIMIT = "500"
# Nâng giới hạn số lượng IP bị Temporary Deny
DENY_TEMP_IP_LIMIT = "1000"
# Khai báo sử dụng ipset
LF_IPSET = "1"
# Enable tính năng CloudFlare
CF_ENABLE = "1"
# Khi add IP lên CloudFlare, add vào Block List
CF_BLOCK = "block"
# Thời gian add tạm là 3600s
CF_TEMP = "3600"
# Thay bằng đường dẫn chứa error_log của domain của bạn
CUSTOM1_LOG = "/var/log/nginx/error_log"
Cấu hình CSF theo dõi log tấn công và tự động đẩy IP tấn công lên CloudFlare
Thêm dòng sau vào file /etc/csf/regex.custom.pm, nằm trước dòng “return 0“. CSF sẽ dựa theo regex này để parse file log, lấy ra các IP vượt quá limit bị ghi log:
if (($globlogs{CUSTOM1_LOG}{$lgfile}) and ($line =~ /^\d{4}\/\d{2}\/\d{2} \d{2}:\d{2}:\d{2} \[.+\] .+?: \S+ limiting requests, excess: \S+ by zone \"[^"]+", client: (\S+), server: .*/)) {
return ("DDoS Attack Detected", $1, "ratelimit", "2", "", "1800", "1")
}
Trong đó:
Đăng nhập vào CloudFlare, chọn domain cần cấu hình và chọn phần “Get API Token“
Lấy Token: API Tokens > Global API Key > View
Copy Token và edit file /etc/csf/csf.cloudflare, chèn thêm dòng sau vào:
DOMAIN:any:USER:vietnix:CFACCOUNT:[email protected]:CFAPIKEY:123456789abcdefghijklmnopqr
Trong đó,
Restart csf & lfd để config có hiệu lực
csf -r
systemctl restart lfd
Kiểm tra xem CSF đẩy được IP lên CloudFlare hay chưa:
# Add IP 99.99.99.99 lên FW CF
csf --cloudflare add block 99.99.99.99 vietnix
# Liệt kê danh sách IP trên FW CF
csf --cloudflare list all vietnix
Chạy lệnh sau (hoặc dùng các tool benchmark/DDoS) để gửi 20 request lên server và kiểm tra kết quả:
for i in $(seq 1 20) ; do curl https://blog.vietnix.vn/ ; done
Thay domain bằng domain của bạn.
Theo dõi output hoặc access_log trên server. Nếu cấu hình đúng thì các request vượt quá limit sẽ nhận được status code 503.
Theo dõi error_log, IP vi phạm sẽ được log lại
2021/03/30 23:03:47 [error] 20800#20800: *1754 limiting requests, excess: 3.318 by zone "location_index", client: 171.252.190.190, server: blog.vietnix.vn, request: "GET / HTTP/1.1", host: "blog.vietnix.vn"
Kiểm tra xem CSF đã parse được file error_log và block IP vi phạm hay chưa
[[email protected] nginx]# csf -t
A/D IP address Port Dir Time To Live Comment
DENY 171.252.190.190 * inout 29m 42s lfd - (ratelimit) DDoS Attack Detected 171.252.190.190 (VN/Vietnam/-): 2 in the last 3600 secs
Kiểm tra Firewall trên CloudFlare xem đã có danh sách IP do CSF đẩy lên chưa:
Các IP tấn công DDoS được add vào Block list trên CloudFlare
Đến đây là hoàn tất, các IP khi có tần số truy cập cao sẽ được phát hiện và giới hạn truy cập bằng NGINX. IP vi phạm được ghi vào error_log, file này được monitor bởi LFD của CSF và định kỳ lấy các IP vi phạm thỏa điều kiện (vi phạm từ 2 lần trở lên) đẩy lên Firewall trên CloudFlare.
Việc IP được đưa vào Firewall ở CloudFlare sẽ ngăn traffic tấn công đổ về backend, giúp giải tải cho server. Số lượng botnet luôn là con số hữu hạn. Chỉ cần chờ 1 thời gian, Firewall CloudFlare sẽ có đủ list IP của botnet!
Các cấu hình trên chỉ mang tính chất tham khảo. Tùy theo mỗi website mà bạn cần điều chỉnh cấu hình cho phù hợp: các location & rate tương ứng.
Các cấu hình hiện tại chưa tối ưu và đang là mô hình sơ khai nhất để kết hợp CloudFlare và CSF. Phần 3 mình sẽ đi tiếp các nội dung giúp hoàn hiện và giúp Backend chống DDoS tốt hơn:
Nguồn
https://blog.vietnix.vn/chong-ddos-bypass-cloudflare-bang-csf-p2.html
Với sự phát triển của các dịch vụ tấn công DDoS (DDoS for Hire) như hiện nay, chỉ với một chi phí nhỏ, bất kỳ ai cũng có thể triển khai một cuộc tấn công DDoS để triệt hạ mục tiêu với các phương thức tấn công được weaponized mà không cần hiểu biết nhiều về kỹ thuật.
Tấn công thì đơn giản nhưng việc chống tấn công DDoS thì hết sức phức tạp, đỏi hỏi rất nhiều kiến thức và kinh nghiệm. Phần lớn khi bị tấn công đều được khuyên đưa website chạy qua CloudFlare để chặn DDoS. Tuy nhiên, không phải trường hợp nào đưa qua CloudFlare cũng hiệu quả, và các công cụ tấn công DDoS hiện nay đều được tích hợp phương thức để bypass CloudFlare. Trong loạt bài viết này, Vietnix sẽ chia sẻ về:
- Cách thức hoạt động của CloudFlare
- Vì sao CloudFlare bị bypass?
- Hướng dẫn chống DDoS bypass CloudFlare bằng CSF Firewall
Cơ chế hoạt động của CloudFlare
CloudFlare là một Reverse Proxy đứng giữa người dùng (User) và Server chạy website của bạn (được gọi là Backend hoặc Origin Server), hoạt động ở Layer 7 (Application Layer). Các request của User sẽ được web server của CloudFlare tiếp nhận, phân tích và xử lý. Nếu CloudFlare cho rằng request đó là hợp lệ thì CloudFlare sẽ kết nối về Backend để lấy data và trả kết quả (response) về cho người dùng. Do đó:
- Chỉ các HTTP request hợp lệ mới được đẩy về backend, nghĩa là User (hoặc botnet) phải tạo được HTTP request (hoàn thành được 3 Way Handshake, tạo được ESTABLISHED socket) gửi đến CloudFlare.
- Do CloudFlare là đối tượng thực hiện kết nối với Backend để lấy data nên ở phía Backend, source IP của các kết nối là IP của CloudFlare chứ không phải IP của User (hoặc botnet). Vậy nên, các network firewall hoạt động ở Layer 3 & Layer 4 (ví dụ iptables) ở phía backend không có tác dụng trong quá trình chống DDoS nếu server của bạn nằm sau CloudFlare.
- Nếu bạn đang bị tấn công DDoS ở tầng Network (UDP Flood, SYN Flood …) trực tiếp vào IP của Backend thì việc chuyển domain qua CloudFlare không giải quyết được vấn đề, trừ khi bạn đổi IP mới cho Backend và giữ bí mật được IP này.
- Các tấn công DDoS ở tầng Network vào IP của CloudFlare hiển nhiên sẽ không ảnh hưởng đến Backend vì chúng chưa lên đến tầng Application và chưa tạo được HTTP request hợp lệ.
Xem thêm: CloudFlare là gì & Cách hoạt động của CloudFlare
Cách DDoS bypass CloudFlare
Mặc định, CloudFlare không cache HTML mà chỉ cache các static content, trừ khi chúng ta setup Page Rule để “Cache Everything”. Nếu chưa setup page rule, các request DDoS do botnet gửi lên sẽ được CloudFlare đẩy toàn bộ về Backend.
Cache Everything kết hợp các thông số như: zone_id, scheme, hostname, request_uri làm cache_key.
Ví dụ: có ta có URL “https://vietnix.vn/?fbclid=IwAR0nKKu3“, giá trị tương ứng của các biến sẽ như sau:
- $scheme – https
- $hostname – vietnix.vn
- $uri – /
- $is_args – ?
- $args – fbclid=IwAR0nKKu3
- $request_uri – /?fbclid=IwAR0nKKu3
- zone_id là 1 giá do CloudFlare định danh cho mỗi domain, giá trị này được lấy trên CloudFlare (thông qua web hoặc API).
=> cache key = md5sum($zone_id:$scheme://$hostname$request_uri) = md5sum(123abc:https://vietnix.vn/?fbclid=IwAR0nKKu3) = 258580a80ba7e32b9c46dad524877118
CloudFlare sử dụng Nginx làm nền tảng để phát triển web server của họ, do đó, ta có thể xem cơ chế xử lý cache của CloudFlare tương tự như Nginx. cache_key sẽ được hash (md5sum) thành một string dùng để phân biệt các cache entry với nhau. Nếu 2 request có cùng 1 kết quả hash thì sẽ được phục vụ từ cùng 1 file cache. Trường hợp file cache chưa tồn tại (cache MISS) thì CloudFlare sẽ request về Backend để lấy data.
Xem thêm: Cơ chế hoạt động & Hướng dẫn cấu hình NGINX cache
Mục tiêu DDoS bypass CloudFlare là đẩy càng nhiều request về Backend càng tốt để làm quá tải nó. Bằng cách làm cho kết quả hash giữa các request khác nhau sẽ gây ra tình trạng cache MISS và các request sẽ được đẩy hết về backend.
Nhìn lại cấu trúc cache key mặc định của CloudFlare, các tham số như zone_id, hostname là cố định, scheme thì chỉ có 2 lựa chọn http hoặc https, biến còn lại request_uri bao gồm URI + Query String, cả 2 tham số này đều dễ dàng bị thay đổi bởi User. Bằng việc Random URI hoặc Query String, hệ thống cache của CloudFlare sẽ bị bypass. CloudFlare cho phép chúng ta custom cache key (sử dụng $uri làm key, bỏ qua $query_string) nhưng tính năng này chỉ available cho các khách hàng sử dụng gói Enterprise (giá 200$/tháng).
Các phương thức bypass CloudFlare được sử dụng phổ biến hiện nay
- Random URL: các attacker sẽ gửi lượng lớn request với các URL random để bypass cache. Về phía backend, tuy các URL này sẽ không hợp lệ và trả về 404, nhưng để xác định URL không tồn tại, mã nguồn cũng tốn tài nguyên để xử lý, truy vấn database (đặc biệt với các mã nguồn sử dụng route controller như wordpress…). Hơn nữa, nếu giao diện trang 404 của mã nguồn có liên quan đến các thông tin cần truy vấn trong database sẽ nhanh chóng làm máy chủ quá tải.
DDoS bypass CloudFlare – Random URL
- Random Query String: cách thường được dùng nhất do độ hiệu quả cao. Attacker sẽ gửi request đến các URL hợp lệ và kèm theo random Query String. Việc random Query String thường không ảnh hưởng đến kết quả load trang (nhất là trang chủ), nhưng nó giúp bypass hoàn toàn hệ thống cache của CF, kèm theo việc Backend phải xử lý một page hợp lệ.
- HTTP POST method: các POST request sẽ được đẩy về backend hoàn toàn vì mặc định không cache POST method. Có thể kết hợp thêm random URL + random Query String
- Botnet có khả năng solve js challange: cách này phụ thuộc vào tính năng của botnet hoặc công cụ/dịch vụ DDoS nơi attacker sử dụng. Các botnet này có khả năng xử lý JS challenge của CloudFlare, qua đó, CloudFlare xem chúng là những người dùng hợp lệ và cho vào hệ thống.
- DDoS bypass CloudFlare low rate: sử dụng botnet với tần số trên mỗi botnet thấp để bypass WAF và rate limit.
- DDoS bằng cách GET static content có dung lượng lớn kết hợp random query string để bypass cache CF, mục tiêu làm tiêu hao Bandwidth phía Backend Server.
Tuy nhiên, điều quan trọng nhất, để tạo được request, các botnet phải thành công trong quá trình thiết lập kết nối ở tầng Network (qua được quá trình bắt tay 3 bước), và chỉ có những client thực sự – có real IP – không phải spoofed IP mới qua được bước này (mình sẽ có 1 bài chi tiết nói về vấn đề này, nó quan trọng vì sẽ quyết định cách tiếp cận chống DDoS của chúng ta). Vậy nên, số lượng IP của botnet là hữu hạn, hướng tiếp cận của chúng ta là xác định các IP của botnet đưa chúng vào Firewall. Khi DDoS bypass CloudFlare, muốn đánh sập backend, các botnet cần tạo ra tần số đủ lớn, vượt qua khỏi khả năng chịu tải của backend:
- Nếu botnet đủ lớn, để đạt được tần số mong muốn, kẻ tấn công sẽ chỉ cần rate (tần số) request trên mỗi IP botnet thấp.
- Nếu botnet ít, chúng sẽ cần tần số request trên mỗi IP cao.
Đây là cơ sở quan trọng nhất để chúng ta xác định đâu là botnet và đâu là người dùng hợp lệ: rate limit
Một mindset cực kỳ quan trọng mà Hưng đã đúc kết qua gần 10 năm chống lại hàng ngàn cuộc tấn công DDoS mà các bạn khi mới tiếp cận thường mắc phải: Chúng ta không cần chặn 100% botnet, mục tiêu cuối cùng là giữ server hoạt động ổn định và phục vụ người dùng hợp lệ một cách bình thường. Do đó, không cần phải siết quá chặt để dẫn đến chặn nhầm người dùng thật, ảnh hưởng đến trải nghiệm. Nếu để lọt một vài botnet có tần số thấp và truy cập của chúng không đủ sức gây ảnh hưởng đến server thì không nhất thiết phải tìm cách chặn, hãy kệ chúng!
Rate Limit cho server nằm sau CloudFlare
Rate limit giúp kiểm soát tần số truy cập của mỗi IP vào server, nếu tần số truy cập lớn hơn quy định thì truy cập đó sẽ bị từ chối và bị ghi log lại. Do web server sẽ tính toán tần số truy cập dựa trên IP nên yêu cầu web server phải nhận biết được IP thật của người dùng.
Quan trọng: đọc kỹ bài viết này để nắm rõ cơ chế hoạt động của Nginx Rate Limiting, chuẩn bị sẵn sàng cho phần cấu hình backend ở Phần 2 của bài viết: Cơ chế hoạt động & Hướng dẫn cấu hình NGINX rate limit
Với trường hợp web server nằm sau CloudFlare, các kết nối backend nhận thấy đều mang source IP của CloudFlare nên không thể áp dụng rate limit lên các IP này. Vị trí tuyệt vời để triển khai rate limit trong mô hình này tất nhiên là CloudFlare, và tin buồn là tính năng này không miễn phí (of course
)Nhưng đừng lo, nếu backend sử dụng Nginx ta sẽ tự triển khai tính năng này. module http_realip sẽ thay thế IP của CloudFlare ở web server (biến $remote_addr) thành IP của client và giúp các module khác hoạt động dựa trên biến $remote_addr (module allow/deny ip, log …) sẽ hoạt động chính xác như thể server đang kết nối trực tiếp với client, bao gồm module rate_limit.
Lưu ý: module trên chỉ có tác dụng đối với logic của Nginx, đối với các ứng dụng khác hoặc ở tầng network thì kết nối vẫn mang source IP của CloudFlare. Vậy làm thế nào để kết hợp CSF – một network Firewall hoạt động ở Layer 3, 4 với CloudFlare để chống tấn công DDoS? Đáp án sẽ có ở phần 2 của bài viết.
Lời kết
Phần 1 chủ yếu tập trung về lý thuyết và hướng tiếp cận để chống DDoS bypass CloudFlare. Phần 2 của bài viết mình sẽ hướng dẫn chi tiết cách cấu hình ở backend. Phần 3 sẽ là những kỹ thuật nâng cao, tool tự động hóa và các cấu hình tối ưu cần thực hiện trên CloudFlare.
Hướng dẫn chống DDoS bypass CloudFlare bằng CSF Firewall - Phần 2
phần 1 của bài Hướng dẫn chống DDoS bypass CloudFlare bằng CSF Firewall, mình đã giải thích rõ về:
- Mô hình hoạt động của Cloudflare
- Cơ chế cache của CloudFlare, đặc điểm về cache key
- Đặc điểm về source IP nhận được ở phía Backend Server
- Các cách DDoS bypass CloudFlare phổ biến.
- Cấu hình NGINX ghi log IP thực của người dùng khi nằm sau CloudFlare (để lấy được IP botnet, sau đó push lên CF chặn)
- Sử dụng NGINX rate limit để giới hạn tần số truy cập (phát hiện đâu là botnet, đâu là người dùng hợp lệ)
- Kết nối CSF với CloudFlare để chặn các IP botnet (push IP botnet lên CloudFlare, không cho đẩy kết nối về Backend)
Cấu hình NGINX ghi log IP thật của User khi nằm sau CloudFlare
Cloudflare là 1 Reverse Proxy hoạt động ở Layer 7 và CloudFlare thay mặt client để kết nối đến backend server lấy data. Do đó:
- Phía backend, source IP (giá trị của biến $remote_addr trong NGINX) là IP của CloudFlare.
- IP thực của người dùng (Client IP) được CloudFlare chèn vào header HTTP “X-Forwarded-For” hoặc “CF-Connecting-IP“.
Chúng ta sẽ cấu hình NGINX sử dụng module http_realip để thay thế giá trị của header “CF-Connecting-IP” vào giá trị của biến $remote_addr. Qua đó, giúp các module hoạt động dựa giá trị của biến $remote_addr (ví dụ module log, rate limit) hoạt động dựa trên giá trị IP thực của người dùng.
Xem thêm: Hướng dẫn cài đặt module real ip cho NGINX
Để NGINX nhận diện IP thực của người dùng, thêm danh sách ipv4 và ipv6 của CloudFlare vào phần set_real_ip_from. Tạo file /etc/nginx/conf/cloudflare.conf với nội dung như sau:
set_real_ip_from 103.21.244.0/22;
set_real_ip_from 103.22.200.0/22;
set_real_ip_from 103.31.4.0/22;
set_real_ip_from 104.16.0.0/12;
set_real_ip_from 108.162.192.0/18;
set_real_ip_from 131.0.72.0/22;
set_real_ip_from 141.101.64.0/18;
set_real_ip_from 162.158.0.0/15;
set_real_ip_from 172.64.0.0/13;
set_real_ip_from 173.245.48.0/20;
set_real_ip_from 188.114.96.0/20;
set_real_ip_from 190.93.240.0/20;
set_real_ip_from 197.234.240.0/22;
set_real_ip_from 198.41.128.0/17;
set_real_ip_from 2400:cb00::/32;
set_real_ip_from 2606:4700::/32;
set_real_ip_from 2803:f800::/32;
set_real_ip_from 2405:b500::/32;
set_real_ip_from 2405:8100::/32;
set_real_ip_from 2c0f:f248::/32;
set_real_ip_from 2a06:98c0::/29;
real_ip_header CF-Connecting-IP;
include file “cloudflare.conf” vào nginx.conf ở context http:
http {
...
include "/etc/nginx/conf/cloudflare.conf";
...
}
Kiểm tra lại config NGINX:
nginx -t
Restart nginx
systemctl restart nginx
Log mặc định của NGINX sử dụng format combined, được định nghĩa như sau:
log_format combined '$remote_addr - $remote_user [$time_local] '
'"$request" $status $body_bytes_sent '
'"$http_referer" "$http_user_agent"';
Format này sử biến $remote_addr làm IP của client. Sau khi config sử dụng module Real IP, hãy tiến hành kiểm tra access log xem đã ghi log được IP thật của người dùng hay chưa:
112.197.118.134 - - [21/Mar/2021:13:17:57 +0700] "GET / HTTP/1.1" 200 10179 "https://www.google.com/" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:86.0) Gecko/20100101 Firefox/86.0"
Whois IP để xem IP trên thuộc nhà mạng nào, nếu không phải của CloudFlare là thành công:
NGINX đã nhận biết được IP thực của người dùng thay vì IP của CloudFlare. Các module khác như allow, deny IP, rate limiting đã có thể sử dụng.
NGINX chống DDoS bằng cách giới hạn tần số truy cập
Khi load một URL, ngoài việc load nội dung (content) của URL, browser còn phải load các static content khác để có thể render thành một web page hoàn chỉnh như: image, javascript, css, font, icon … Điều này có nghĩa khi load một URL, client không chỉ tạo một request đến server mà là nhiều request. Do đó, để giới hạn tần số hiệu quả, ta cần tối ưu như sau:
- Để location chứa static content như: image, javascript, css, icon … nằm riêng
- Tách location cho trang chủ (trang /) vì đây là location bị đánh phổ biến nhất.
- Tách location cho các URL bị đánh trong trường hợp khẩn cấp để apply limit phù hợp.
Ví dụ:
server {
...
location ~* \.(swf|ogg|ogv|svg|svgz|eot|otf|woff|mp4|ttf|css|rss|atom|js|jpg|jpeg|gif|png|ico|tgz|gz|rar|bz2|tar|mid|midi|wav|bmp|rtf|woff|woff2|mo|zip|txt)$ {
expires max;
}
location = / {
proxy_pass https://127.0.0.1:8080;
}
location / {
proxy_pass https://127.0.0.1:8080;
}
}
Để cấu hình rate limit, cần thực hiện 2 bước: khai báo limit_req_zone và khai báo limit_req.
Chi tiết về thuật toán, cách cấu hình, ý nghĩa các tham số tham khảo tại: Hướng dẫn cấu hình giới hạn tần số truy cập với NGINX
- location static content: thường thì không cần limit hoặc limit ở rate cao nếu bạn muốn. Vì việc phục vụ các request ở khu vực này thường ko tốn quá nhiều resource (ngoại trừ băng thông)
- location = / : location này chỉ phục vụ riêng cho trang index, có thể đặt tần số thấp.
- location / : catch all location, phục vụ các request không match các location trước đó, cần để limit tương đối thoáng.
Ở bước 1, ta đã config NGINX nhận được real IP của client, ta có thể dùng biến $binary_remote_addr để làm key.
Ví dụ
Giới hạn tần số truy cập như sau:
- Không limit với location static
- Limit location = / – mỗi IP không được phép thực hiện quá 3 request mỗi giây.
- location / : limit mỗi IP không được phép thực hiện quá 10 request mỗi giây.
File virtual host blog.vietnix.vn.conf sẽ có nội dung:
limit_req_zone $binary_remote_addr zone=location_index:10m rate=3r/s; # khai báo zone cho page index
limit_req_zone $binary_remote_addr zone=location_catchall:10m rate=5r/s; # khai báo zone choh catch all location
server {
...
server_name blog.vietnix.vn;
index index.php;
access_log /var/log/nginx/access_log combined;
error_log /var/log/nginx/error_log error;
root /var/www/vietnix.vn/
location ~* \.(swf|ogg|ogv|svg|svgz|eot|otf|woff|mp4|ttf|css|rss|atom|js|jpg|jpeg|gif|png|ico|tgz|gz|rar|bz2|tar|mid|midi|wav|bmp|rtf|woff|woff2|mo|zip|txt)$ {
expires max;
}
location = / {
limit_req zone=location_index burst=3 nodelay;
proxy_pass https://127.0.0.1:8080;
}
location / {
limit_req zone=location_catchall burst=10 delay=7;
proxy_pass https://127.0.0.1:8080;
}
}
Tác dụng:
- Giới hạn tần số truy cập vào home page (trang index) là 3 request/s. Việc set “burst=3 nodelay” cho phép 3 request đầu tiên được phục vụ ngay lập tức mà không cần chờ. Đồng thời set hàng đợi tối đa là 3 request, nếu vượt qua số lượng này sẽ bị reject.
- Các truy cập vào static resources (file tĩnh) không bị giới hạn.
- Truy cập vào các khu vực còn lại bị giới hạn tần số 5 request/s với 7 request đầu tiên được phục vụ ngay lập tức (delay = 7), các request sau đó (request 8, 9, 10) bị delay để đảm bảo tần số 5 request/s. Hàng đợi chứa được tối đa 10 request, các request vượt quá số lượng này sẽ bị reject.
Theo dõi các IP vi phạm
Các IP truy cập quá tần số quy định sẽ bị ghi log vào file error_log với nội dung như sau:
2021/03/29 15:53:24 [error] 8564#0: *24818 limiting requests, excess: 4.544 by zone "location_index", client: 3.140.197.140, server: blog.vietnix.vn, request: "GET / HTTP/1.1", host: "blog.vietnix.vn"
Trong đó:
- zone “location_index” – zone name được hai báo ở limit_req_zone
- client: 3.140.197.140 – IP tấn công
- request – URL bị tấn công
- host: domain bị tấn công
Để tránh request của các IP này không truy cập được về backend nữa, ta cần tiến hành block IP của chúng trên CloudFlare. Để tất cả IP tấn công tự động bằng cách theo dõi file error log và tự động add chúng vào Firewall trên CloudFlare, ta sử dụng CSF Firewall
Cài đặt CSF Firewall và cấu hình chống DDoS bypass CloudFlare
Hướng dẫn cài đặt CSF tham khảo tại đây: Hướng dẫn cài đặt CSF
CSF có khá nhiều tính năng hay, mình sẽ làm 1 series bài chi tiết về CSF sau. Trong phạm vi bài viết này, các bạn chỉ cần quan tâm điều chỉnh các thông số được liệt kê bên dưới.
Mở file cấu hình /etc/csf/csf.conf và điều chỉnh thành giá trị như sau:
# Enable Firewall
TESTING = 1
# Khai báo các TCP Port cho phép client kết nối đến Server
TCP_IN = "22,80,443"
# Khai báo các TCP port cho phép server kết nối ra ngoài
TCP_OUT = "1:65535"
# Khai báo các UDP port cho phép client kết nối đến server
UDP_IN = ""
# Khai bác các UDP port cho phép server kết nối ra ngoài
UDP_OUT = "1:65535"
# Nâng giới hạn Deny IP
DENY_IP_LIMIT = "500"
# Nâng giới hạn số lượng IP bị Temporary Deny
DENY_TEMP_IP_LIMIT = "1000"
# Khai báo sử dụng ipset
LF_IPSET = "1"
# Enable tính năng CloudFlare
CF_ENABLE = "1"
# Khi add IP lên CloudFlare, add vào Block List
CF_BLOCK = "block"
# Thời gian add tạm là 3600s
CF_TEMP = "3600"
# Thay bằng đường dẫn chứa error_log của domain của bạn
CUSTOM1_LOG = "/var/log/nginx/error_log"
Cấu hình CSF theo dõi log tấn công và tự động đẩy IP tấn công lên CloudFlare
Thêm dòng sau vào file /etc/csf/regex.custom.pm, nằm trước dòng “return 0“. CSF sẽ dựa theo regex này để parse file log, lấy ra các IP vượt quá limit bị ghi log:
if (($globlogs{CUSTOM1_LOG}{$lgfile}) and ($line =~ /^\d{4}\/\d{2}\/\d{2} \d{2}:\d{2}:\d{2} \[.+\] .+?: \S+ limiting requests, excess: \S+ by zone \"[^"]+", client: (\S+), server: .*/)) {
return ("DDoS Attack Detected", $1, "ratelimit", "2", "", "1800", "1")
}
Trong đó:
- DDoS Attack Detected – Nội dung thông báo
- $1 – sẽ được thay thế bằng IP của botnet
- ratelimit – tên của rule (cần phải đặt unique)
- 2 – số lần vi phạm tối đa cho phép, nếu vi phạm vượt quá số lần quy định (IP xuất hiện ở error log nhiều lần) sẽ bị trigger block IP. Ở đây mình để là 2, quá limit rate 2 lần mới bị block
- 1800 – thời gian block (tính bằng giây)
- 1 – Enable việc đẩy IP vi phạm lên block trên firewall của CloudFlare.
Cấu hình CSF kết nối API với CloudFlare
Đăng nhập vào CloudFlare, chọn domain cần cấu hình và chọn phần “Get API Token“
Lấy Token: API Tokens > Global API Key > View
Copy Token và edit file /etc/csf/csf.cloudflare, chèn thêm dòng sau vào:
DOMAIN:any:USER:vietnix:CFACCOUNT:[email protected]:CFAPIKEY:123456789abcdefghijklmnopqr
Trong đó,
- USER:vietnix – Đặt tên sao cho dễ nhớ là được.
- CFACCOUNT:[email protected] – Thay bằng email login CloudFlare
- CFAPIKEY:123456789[…] – Thay bằng Token lấy ở trước trên.
Restart csf & lfd để config có hiệu lực
csf -r
systemctl restart lfd
Kiểm tra xem CSF đẩy được IP lên CloudFlare hay chưa:
# Add IP 99.99.99.99 lên FW CF
csf --cloudflare add block 99.99.99.99 vietnix
# Liệt kê danh sách IP trên FW CF
csf --cloudflare list all vietnix
Kiểm tra việc chống DDoS bypass CloudFlare bằng CSF
Chạy lệnh sau (hoặc dùng các tool benchmark/DDoS) để gửi 20 request lên server và kiểm tra kết quả:
for i in $(seq 1 20) ; do curl https://blog.vietnix.vn/ ; done
Thay domain bằng domain của bạn.
Theo dõi output hoặc access_log trên server. Nếu cấu hình đúng thì các request vượt quá limit sẽ nhận được status code 503.
Theo dõi error_log, IP vi phạm sẽ được log lại
2021/03/30 23:03:47 [error] 20800#20800: *1754 limiting requests, excess: 3.318 by zone "location_index", client: 171.252.190.190, server: blog.vietnix.vn, request: "GET / HTTP/1.1", host: "blog.vietnix.vn"
Kiểm tra xem CSF đã parse được file error_log và block IP vi phạm hay chưa
[[email protected] nginx]# csf -t
A/D IP address Port Dir Time To Live Comment
DENY 171.252.190.190 * inout 29m 42s lfd - (ratelimit) DDoS Attack Detected 171.252.190.190 (VN/Vietnam/-): 2 in the last 3600 secs
Kiểm tra Firewall trên CloudFlare xem đã có danh sách IP do CSF đẩy lên chưa:
Đến đây là hoàn tất, các IP khi có tần số truy cập cao sẽ được phát hiện và giới hạn truy cập bằng NGINX. IP vi phạm được ghi vào error_log, file này được monitor bởi LFD của CSF và định kỳ lấy các IP vi phạm thỏa điều kiện (vi phạm từ 2 lần trở lên) đẩy lên Firewall trên CloudFlare.
Việc IP được đưa vào Firewall ở CloudFlare sẽ ngăn traffic tấn công đổ về backend, giúp giải tải cho server. Số lượng botnet luôn là con số hữu hạn. Chỉ cần chờ 1 thời gian, Firewall CloudFlare sẽ có đủ list IP của botnet!
Tổng kết phần 2 Chống DDoS bypass CloudFlare bằng CSF
Các cấu hình trên chỉ mang tính chất tham khảo. Tùy theo mỗi website mà bạn cần điều chỉnh cấu hình cho phù hợp: các location & rate tương ứng.
Các cấu hình hiện tại chưa tối ưu và đang là mô hình sơ khai nhất để kết hợp CloudFlare và CSF. Phần 3 mình sẽ đi tiếp các nội dung giúp hoàn hiện và giúp Backend chống DDoS tốt hơn:
- Cấu hình mirco cache cho website chạy WordPress để tăng khả năng chịu tải khi bị tấn công.
- Các cấu hình tối ưu thêm trên CloudFlare, NGINX
- Notify telegram các IP botnet bị chặn
- Script thay thế khi không sử dụng CSF
- Bonus thêm 1 trick chống DDoS trước giờ chỉ lưu truyền nội bộ Vietnix
Nguồn
Hướng dẫn chống DDoS bypass CloudFlare bằng CSF Firewall - Phần 1 - Blog Quản Trị Linux
Với sự phát triển của các dịch vụ tấn công DDoS (DDoS for Hire) như hiện nay, chỉ với một chi phí nhỏ, bất kỳ ai cũng có thể triển khai một cuộc tấn
blog.vietnix.vn
