Bài viết gốc mình đã chia sẻ trên fb – ngay sau sự kiện Cookie Arena CTF Season 2 bị DDOS.
Về chi tiết quá trình xử lý và điều tra sau DDOS, các bạn có thể xem trên blog của Cookie Arena. Anh Hazy đã lên một bài khá chi tiết rồi!
Ở bài này mình sẽ chỉ tóm tắt lại:
- Một số kinh nghiệm xử lý DDOS của cá nhân mình
- Những thảo luận hay trong phần comment của bài viết trên fb
- Vài tài liệu DDOS mà mình thấy chất lượng, sát với thực tiễn
Mục lục
Kinh nghiệm xử lý DDOS
Có mấy việc mà các bạn có thể quick fix (nếu có thời gian thì có thể làm thêm một số bước post-investigation, nhưng đợt DDOS Cookie Arena mình chưa làm đc)
1. Phát hiện và khoanh vùng phạm vi tấn công
Đầu tiên cần phát hiện và khoanh vùng phạm vi bị tấn công (thông qua alert, access log,… của WAF hoặc proxy), xem những (sub)domain nào đang bị target (cái này lọc từ access log của proxy hoặc security logs của WAF – cloudflare, …).
- Trên cloudflare thì có thể vào Analytics and Logs > Traffics và Security > Events
- Lọc ra access logs của các site bị target, phân tích pattern chung của các request. Thông thường trong các cuộc tấn công DDoS, traffic thường có một số điểm chung – mục đích là để viết ra Rules ngăn chặn (bước tiếp theo). Ví dụ:
- Header User-Agent của request giống nhau
[Alexibot,AIBOT,v.v.]. - Gửi đến một số endpoint nhất định của ứng dụng (có thể là endpoint thật hoặc endpoint không tồn tại trong ứng dụng của ae).
- Đến từ môt hoặc nhiều quốc gia khác nhau. Nếu bạn dùng WAF ngon thì đa phần thông tin này sẽ được show sẵn ra. Nếu chỉ có NGINX/Apache, bạn có thể dùng môt số tool như
ip2location, các tool này thường hỗ trợ sẵn việc parse access log của Nginx/Apache.
- Header User-Agent của request giống nhau
/Suspected User-Agent:
nginx-ssl early hints2. Viết rule ngăn chặn
Dựa vào pattern của traffic DDOS, bạn sẽ viết ra được các rule ngăn chặn. Ví dụ:
- Cloudflare luôn có sẵn một số Rule phổ biến để ngăn chặn DDOS. Ví dụ, bạn có thể block theo:
- Một số User Agent không hợp lệ thường gặp.
- IP có Request Rate lớn.
- Những Request có pattern khả nghi: body chứa SQLi, v.v.
- Chặn các request có header
User-Agentkhả nghi – kể cả Cloudfare hay các tool xịn xò khác cũng chưa chắc cover được phần này, vì header của request là do client set tuỳ thích → tốt nhất là check lại và add thêm rule vào WAF. - Có thể chặn theo IP Location → cái này làm không khó, nhưng cần phải đánh giá impact, ví dụ end-user ở full Việt Nam thì cho đám traffic từ Nga Ngố bay màu cũng được :>
- Nếu không thể BLOCK được bọn này (do có những tính năng vẫn phải expose ra cho người dùng thật sử dụng) thì nên setup ratelimit.
- Cloudflare hay NGINX đều support rate limit, tuy nhiên setup ratelimit ở NGINX chưa chắc có hiệu quả đâu, vì NGINX vẫn phải handle request và trả về response do đó vẫn chết như thường, tốt nhất là ratelimit ở WAF hoặc ở layer network được là ngon nhất.
- Kiểm tra lại tình trạng hệ thống sau khi đã thực hiện add thêm rule – do traffic pattern có thể sẽ thay đổi ở các đợt tấn công tiếp theo, mấy cái rule bên trên khả năng cao sẽ không cover được hết các case trong lần set đầu tiên.
3. TRAP & Honeypot
Ngoài ra, có thể cài cắm thêm một số rule trên firewall – mục đích là để ‘lừa’ bot send traffic vào, đợi môt thời gian rồi mình túm (block) một lượt cho gọn.
- Có thể expose ra một endpoint, domain trông-có-vẻ nhạy cảm (nhưng là hàng fake, tốt nhất là trỏ hoặc redirect đi chỗ nào đó không liên quan tới hạ tầng của mình)
- Lặp lại bước từ bước đầu để bắt nốt số “gà” còn lại =))
Cơ mà làm honey pot cẩn thận nhá 
, sẩy tay cái là thành ‘mỡ để miệng mòe’ đấy. Honeypot nên được setup càng độc lập (isolated) với các tài nguyên prod khác càng tốt.
Tổng hợp một số bình luận hay
Cho 500 capcha của CF nữa em :)). Ngoài ra set alert khi có ddos trên cf ( mặc fuf từ lúc set a chưa nhận đc cái nào )
a. Vuong
- Đúng là CF gửi DDoS hơi chậm, chắc do CF muốn giảm false-positive alert.
- Captcha là cần thiết, cả ở CF và level app.
- Nếu được thì app nên có cả CaptchaV3 và CaptchaV2.
Với cả nhìn ảnh thì có vẻ là lên CF gói khác gói free. Đây cũng là 1 solution xịn e nhé :)))) ko lên gói xịn, dashboard với report như hạch
a. Vuong
- CF gói Free dashboard tệ, nếu không muốn nói là gần như vô dụng – trong việc chống DDOS.
- Có thể dùng một số tool khác như đẩy log của gateway (Nginx, LB, etc.) lên ElasticSearch rồi setup Kibana Dashboard + Alert dựa trên thông tin trích xuất ra từ log.
A nghĩ cái này phải 90% config tốt ở CF thì sẽ đỡ việc cho mình. Còn lại 10% thì do mình gánh. Thông thường thì có 2 cái, 1 web app ( dạng serve static cơ bản ) và dạng còn lại là API. Serve static thì có thể mượn cache gánh cho 1 ít. Còn API thì dựa vào API Gateway ( nếu dùng ). Rule dạng rate limit ở API gateway cũng ok, do chủ yếu scale hoặc reject ở tầng thằng này vẫn rẻ. Chứ chọc vào API app rồi reject ở đó thì chát
a. Vuong
- Chặn tấn công nên chặn từ ngoài vào: CDN / Gateway / LB → App.
a Vuong: Trước a cũng block chay với User-Agent, take vài sample thấy có vẻ dùng User-Agent từ M->Z, cơ mà cụ nội nó, nó chơi full bảng chữ cái. => bài học a rút ra là vẫn phải dựa vào 1 tool nào đó aggregate sẵn cho rồi còn vào block
Phong: Em cũng thấy đọc logs chay thì chỉ hữu ích bước detect thôi, chứ scope mà đọc logs cũng mệt hơi. Tool aggregate + cảnh báo e thấy có bọn Elastic SIEM dạo này ngon active phết á, mà chưa dùng thử luôn, k biết có false positive nhiều k
a. Vuong > Phong
a. Vuong: Ngoài ra có phần predefined rule của CF nữa, e có thể dùng ko phải cho DDOS mà cho mấy phần security. Bật luôn vì đằng nào cũng có trong gói của e =))
Phong: OWASP e có bật a ạ. Nhưng e lại có một tips nữa ngược lại là:
một số website như blog lập trình, confluence, nhiều khi payload request nó dị dị:
a. Vuong > Phong
Ví dụ viết bài chia sẻ về sql injection, là lúc submit bài cloudflare chặn luôn ợ =))))
- Một số predefined rules của CF rất có ích trong DDOS và protect site nói chung. Tuy nhiên giống như bất kỳ tool nào, CF Rules cũng có false positive.
CF có một cái gotchas nữa là: có một số rule không thể tắt đc, k thể bypass đc,
nhiều khi dính chỉ có workaround (add exclusion cho rule).một só rule bị enable kiểu implicit luôn
trước cả tầng WAF do user define (nhất là mấy phần liên quan đến Bot ợ)
ví dụ SuperBot Fight Mode =))) nhiều khi lỗi móe nó frontend luôn ây, vì nó tự thêm một khoảng trắng vào
Phong
mà k tắt đc…
Một số Series hay về chống DDOS
Thời điểm đó mình có tìm được hai chuỗi series chống DDOS khá chất lượng – mà nguồn Việt Nam luôn nhé!
Seri chống DDOS của a. Hưng @ VietNix. Cả video và bài viết đều rất hữu ích:
Các bạn tự tìm thêm các phần còn lại nhé.
Real case của Cookie Arena:
https://cookiearena.org/case-study/dieu-tra-cuoc-tan-cong-ddos-cuoc-thi-cookie-arena-ctf-season-2
Còn một bài viết chống DDOS (kiểu diary) của một thánh nhân, mà hiện tại mình đang quên mất đọc được ở đâu, sẽ update lại vào đây sau!
Peace ❤️
LOVE YOU ALL!
Vừa lên xong bị bắn lun mò :))