Hướng dẫn chống DDoS bypass CloudFlare bằng CSF Firewall hiệu quả

Các dịch vụ tấn công DDoS thuê mướn (DDoS for Hire) ngày càng phổ biến, cho phép bất kỳ ai cũng có thể triển khai tấn công DDoS với chi phí thấp mà không cần kiến thức kỹ thuật chuyên sâu. Ngược lại, phòng thủ DDoS ngày càng trở nên phức tạp hơn nhiều, CloudFlare được xem là giải pháp phổ biến, nhưng không phải lúc nào cũng hiệu quả do các công cụ tấn công hiện nay có thể bypass hệ thống này. Bài viết sau mình sẽ hướng dẫn chi tiết cách chống DDoS bypass CloudFlare bằng CSF Firewall giúp bảo vệ website của bạn một cách hiệu quả.

Điểm chính cần nắm

• Hiểu được cơ chế hoạt động của CloudFlare.
• Nắm được 3 phương thức bypass CloudFlare được sử dụng phổ biến hiện nay gồm: Random URL, Random Query String, HTTP POST method,…
• Biết cách Rate Limit cho server nằm sau CloudFlare giúp kiểm soát tần số truy cập của mỗi IP vào server.
• Được hướng dẫn cách cấu hình NGINX ghi log IP thật của User khi nằm sau CloudFlare.
• Nắm rõ cách NGINX chống DDoS bằng cách giới hạn tần số truy cập.
• Hướng dẫn theo dõi các IP vi phạm.
• Hiểu rõ cách cài đặt CSF Firewall và cấu hình chống DDoS bypass CloudFlare.
• Biết cách cấu hình CSF kết nối API với CloudFlare.
• Được hướng dẫn kiểm tra chống DDoS bypass CloudFlare bằng CSF.
• Biết đến Vietnix là đơn vị cung cấp giải pháp Firewall Anti DDoS độc quyền tại Việt Nam với nhiều ưu điểm như: Chống DDoS cả tầng ứng dụng, mạng, cơ sở hạ tầng, công nghệ thiết kế dựa trên các cuộc tấn công tại Việt Nam, có thể xử lý lưu lượng tấn công DDoS quy mô lớn, uptime cao, hỗ trợ kỹ thuật 24/7 với đội ngũ chuyên nghiệp,…

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ệ.

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ụ: 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.

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 và 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.

Random Query String

Đây là phương thức thường được sử dụng nhiều nhất mang lại hiệu quả cao. Theo đó, 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, bạn có thể kết hợp thêm random URL và random Query String.

Ngoài ra còn có 1 số phương thức khác như:

• 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 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à mình đã đú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. 

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í.

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.

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. Bạn 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";
...
}

Sau đó bạn kiểm tra lại config NGINX:

nginx -t

Tiếp tục nhập lệnh sau để 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, bạn 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à bạn đã 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ụ như sau:

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, bạn cần thực hiện 2 bước: khai báo limit_req_zone và khai báo limit_req.

• ocation 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, bạn đã config NGINX nhận được real IP của client, bạn 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 quantrilinux.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 quantrilinux.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: quantrilinux.vn, request: "GET / HTTP/1.1", host: "quantrilinux.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

CSF có nhiều tính năng hữu ích, sẽ được trình bày chi tiết trong loạt bài viết sắp tới. Bài viết này sẽ chỉ tập trung vào việc điều chỉnh các thông số quan trọng được liệt kê bên dưới.

Đầu tiên bạn hãy 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

Bạn đăng nhập vào CloudFlare, sau đó 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:info@vietnix.vn:CFAPIKEY:123456789abcdefghijklmnopqr

Trong đó:

• USER:vietnix – Đặt tên sao cho dễ nhớ là được.
• CFACCOUNT:info@vietnix.vn – 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

Bạn hãy 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

Bạn 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://quantrilinux.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: quantrilinux.vn, request: "GET / HTTP/1.1", host: "quantrilinux.vn"

Bạn kiểm tra xem CSF đã parse được file error_log và block IP vi phạm hay chưa.

[root@quantrilinux.vn 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.

Những cấu hình được trình bày trong bài viế chỉ mang tính chất gợi ý, bạn có thể tùy chỉnh location và rate sao cho phù hợp nhất với từng website cụ thể. Đây mới là những bước đầu tiên trong việc tích hợp CloudFlare và CSF. Trong phần mình sẽ tiếp tục đào sâu vào các kỹ thuật nâng cao, giúp tối ưu hóa khả năng chống DDoS cho Backend.

• 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.

Vietnix – Cung cấp giải pháp Firewall Anti DDoS độc quyền

Vietnix là đơn vị nổi bật với giải pháp Firewall Anti DDoS độc quyền trên thị trường Việt Nam, giúp doanh nghiệp phòng thủ vững chắc trước những cuộc tấn công DDoS. Với hơn 12 năm hoạt động, sở hữu cơ sở hạ tầng hiện đại và công nghệ hàng đầu, dịch vụ Firewall Anti DDoS của Vietnix nổi bật với các ưu điểm như sau:

• Công nghệ thiết kế dựa trên các cuộc tấn công tại Việt Nam.
• Có thể xử lý lưu lượng tấn công DDoS quy mô lớn.
• Chống DDoS cả tầng ứng dụng, mạng, cơ sở hạ tầng.
• Không làm giảm hiệu suất hệ thống, uptime cao.
• Hỗ trợ kỹ thuật 24/7 với đội ngũ chuyên nghiệp, giàu kinh nghiệm.

Thông tin liên hệ:

• Hotline: 18001093
• Email: sales@vietnix.com.vn
• Địa chỉ: 265 Hồng Lạc, Phường 10, Quận Tân Bình, Thành Phố Hồ Chí Minh.
• Website: https://vietnix.vn/

Hy vọng bài viết này đã cung cấp cho bạn những kiến thức hữu ích về cách chống DDoS bypass CloudFlare bằng CSF Firewall. Việc kết hợp CloudFlare và CSF sẽ tạo nên một lớp bảo vệ vững chắc, giúp website của bạn hoạt động ổn định và an toàn trước các cuộc tấn công DDoS. Hãy áp dụng ngay những hướng dẫn này để bảo vệ website của bạn.