Những trường hợp tấn công được phát hiện trong log truy cập

 (nishtahir.com)
1 điểm bởi GN⁺ 2024-01-29 | 1 bình luận | Chia sẻ qua WhatsApp
  • Trong log truy cập của một IP công khai được self-host hơn 10 năm, có thể thấy các nỗ lực tấn công mà các dịch vụ lộ ra Internet thường xuyên phải hứng chịu, từ dò tìm thông tin xác thực đến chèn lệnh nhắm vào thiết bị IoT
  • Mẫu phổ biến nhất là dò tìm tệp cấu hình và thư mục bằng cách lục soát các đường dẫn như .env, .aws/credentials, .git/config, backup/, test/; một số yêu cầu còn dùng User-Agent bị gõ sai như Mozlila/5.0
  • Các nỗ lực Shellshock chèn payload dạng hàm Bash vào User-Agent để đọc /etc/passwd, đồng thời liên tục đoán nhiều đường dẫn CGI khác nhau
  • Các cuộc tấn công nhắm vào LuCI và Zyxel cố chèn lệnh vào giao diện web của router và thiết bị nhúng để tải xuống rồi thực thi script từ xa và binary cho nhiều kiến trúc khác nhau
  • Cần giảm tối đa số tài nguyên bị phơi ra Internet công khai, áp dụng xác thực và giới hạn IP cho các công cụ/thư mục cần thiết, đồng thời giữ thiết bị IoT luôn được cập nhật và tách khỏi mạng công khai nếu có thể

Lưu lượng mà các dịch vụ lộ ra Internet công khai phải nhận

  • Trong hơn 10 năm self-host, tác giả tiếp tục trải nghiệm việc tự sở hữu dữ liệu của mình và giảm phụ thuộc vào các nền tảng ngoài nhà cung cấp cloud host
  • Khi để lộ một IP ra Internet công khai, gần như ngay lập tức sẽ có rất nhiều lưu lượng độc hại đổ vào; xem log truy cập có thể giúp lần ra gần đây đã bị tấn công theo cách nào
  • Phân tích này gần với quan sát của một lập trình viên tò mò hơn là một cuộc điều tra pháp chứng của chuyên gia bảo mật
  • Địa chỉ IP của kẻ tấn công và một số lời lẽ xúc phạm mà họ dùng đã được che đi để thận trọng

Dò tìm thông tin xác thực và tệp cấu hình

  • Kiểu tấn công phổ biến nhất là cố tìm thông tin xác thực thông qua duyệt cây thư mục, trong đó xuất hiện đặc biệt nhiều yêu cầu tới tệp .env
    • Ví dụ đường dẫn yêu cầu gồm /laravel/.env, /backend/.env, /api/.env, /.env, //.env
    • .env thường được dùng làm tệp chứa secret của ứng dụng
  • Các tệp liên quan đến AWS và cấu hình kho Git cũng nằm trong diện bị dò tìm
    • Ví dụ gồm /aws.yml, /.env.bak, /info.php, /.aws/credentials, /config/aws.yml, /.git/config
  • Các thư mục thường gặp có thể bị để quên do sơ suất cũng bị yêu cầu lặp đi lặp lại
    • Ví dụ gồm /old/, /new/, /test/, /backup/, /temp/
  • Một số User-Agent có chứa Mozlila/5.0, có vẻ là lỗi gõ sai của Mozilla/5.0
    • Kết quả tìm kiếm trên GitHub cho thấy lỗi này có thể được tạo bởi một công cụ phổ biến rồi bị sao chép và dán lại
  • Cũng có các yêu cầu nhằm tìm công cụ truy cập từ xa hoặc công cụ cấu hình
    • Ví dụ gồm /actuator/gateway/routes, /hudson, /ui/login.action, /?XDEBUG_SESSION_START=phpstorm
  • Chỉ nên phơi ra Internet công khai những gì thực sự cần thiết; nếu buộc phải để lộ công cụ hoặc thư mục, cần có lớp xác thực và nếu có thể thì giới hạn theo IP cụ thể

Các nỗ lực Shellshock

  • Nhiều yêu cầu dường như nhắm vào lỗ hổng Shellshock
  • Kiểu tấn công này nhằm thực thi lệnh tùy ý trên máy chủ web chạy script CGI bằng phiên bản Bash dễ bị tổn thương
    • Khi chương trình CGI khởi động, nó thiết lập biến môi trường từ nội dung yêu cầu, và HTTP_USER_AGENT là một trong số đó
    • Nếu có chuỗi như () { :; };, Bash sẽ hiểu đó là một hàm cần được thực thi
  • User-Agent trong log thực tế có chứa các payload như sau
    • () { ignored; }; echo Content-Type: text/html; echo ; /bin/cat /etc/passwd
    • () { ignored; }; là dạng định nghĩa hàm Bash
    • echo Content-Type: text/html; echo ; in ra Content-Type của phản hồi HTTP và một dòng trống
    • /bin/cat /etc/passwd là lệnh nhằm in nội dung /etc/passwd, nơi chứa thông tin tài khoản người dùng
  • Nếu tấn công thành công, nó có thể dẫn tới truy cập thông tin xác thực người dùng và thực thi mã tùy ý trên máy chủ
  • Tương tự như duyệt cây thư mục, kẻ tấn công đoán các đường dẫn phổ biến như /cgi-bin/status, /cgi-bin/stats, /cgi-bin/test, /cgi-bin/status/status.cgi, /test.cgi, /debug.cgi, /cgi-bin/test-cgi

Chèn lệnh nhắm vào LuCI

  • Có một yêu cầu dường như nhắm vào LuCI, giao diện web dành cho router OpenWRT
  • URL tấn công được cấu trúc để chèn lệnh vào trường country, với mục tiêu tải xuống rồi thực thi script shell tenda.sh từ máy chủ từ xa
    • Sau khi URL decode, lệnh có luồng xử lý là chuyển sang /tmp, xóa tệp, dùng wget để tải script về, cấp quyền thực thi rồi chạy nó
  • Script được tải xuống có chứa nội dung nhằm tải tiếp và thực thi các binary khác
    • Có các tên dường như là kiến trúc đích như mips, mpsl, x86_64, arm, arm5, arm6, arm7, i586, i686, powerpc, sh4, m68k, sparc
    • Cách thử binary cho nhiều kiến trúc cho thấy kẻ tấn công muốn mở rộng phạm vi tấn công trong bối cảnh không biết kiến trúc của thiết bị mục tiêu
  • Để điều tra thêm, tác giả tải một binary không tương thích với môi trường của mình và xem bằng Ghidra
    • Ban đầu chỉ có 3 hàm và không nhiều dữ liệu chuỗi
    • Trong một vùng dữ liệu lớn, có thể thấy các chuỗi $Info: This file is packed with the UPX executable packer và UPX 3.94
  • Đây là binary ELF được nén bằng UPX, và nếu header UPX hoặc packed binary chưa bị sửa thì có thể giải bằng upx -d
    • Thực tế sau khi chạy upx -d mips, kích thước tệp tăng từ 34932 lên 93732, và có thể xem được nhiều chuỗi hơn
  • Trong các chuỗi của binary đã giải nén có M-SEARCH * HTTP/1.1, ST: urn:dial-multiscreen-org:service:dial:1, cùng payload XML để nâng cấp thiết bị Huawei
    • Đây có vẻ là lệnh UPnP dùng để tìm thiết bị trên mạng hỗ trợ giao thức DIAL
    • Payload XML dường như được cấu hình để quét các thiết bị Huawei dễ bị chèn lệnh
    • Hành vi này được nhận diện là một phần của botnet Mirai
  • Tệp yeye.mips được tham chiếu không còn khả dụng khi thử tải về
    • Kết quả chạy nmap với máy chủ chỉ cho thấy các cổng mở 22/tcp ssh và 646/tcp filtered ldp

Chèn lệnh nhắm vào Zyxel

  • Một yêu cầu khác chứa lệnh shell ngay trong URL GET, và khi bỏ phần thay thế shell ${IFS} thì nội dung trở nên dễ đọc hơn
    • Lệnh sau khi rút gọn có luồng xử lý là chuyển sang /tmp, xóa các tệp *mips*, tải huhu.mips, cấp quyền thực thi rồi chạy với đối số zyxel.selfrep
  • Cuộc tấn công này dường như nhắm vào exploit zhttpd trên thiết bị Zyxel
  • Binary lần này không ở trạng thái packed, nên có thể xem chuỗi trực tiếp trong Ghidra
    • Các chuỗi gồm M-SEARCH * HTTP/1.1, header ST liên quan tới DIAL, skyljne.arm, skyljne.arm5, skyljne.arm6, skyljne.arm7, skyljne.mips, skyljne.mpsl, skyljne.x86_64, skyljne.sh4
    • Cũng có payload XML nhắm vào thiết bị Huawei để tải huhu.mips và chạy nó dưới tên selfrep.huawei
  • Một chuỗi khác chứa lệnh gửi POST tới /goform/set_LimitClient_cfg
    • Với header Cookie: user=admin, nó cố chèn lệnh vào tham số mac để tải và chạy huhu.mpsl
    • Theo bài viết của Akamai, lỗ hổng này nhắm vào router và có thể bị khai thác trước xác thực do không có kiểm tra xác thực/ủy quyền thích hợp
  • Binary này nhiều khả năng là agent của botnet Mirai
    • Một số nguồn cũng nhắc đến khả năng có liên quan tới Linux Medusa

Ứng phó từ góc độ vận hành

  • Những log đã kiểm tra chỉ là một phần của toàn bộ bức tranh, và mỗi ngày còn có rất nhiều exploit khác được thử
  • Việc giữ thiết bị, đặc biệt là thiết bị IoT, luôn ở trạng thái cập nhật là rất quan trọng
  • Nếu có thể, không nên để thiết bị IoT lộ trực tiếp ra Internet công khai
  • Nếu buộc phải phơi ra ngoài, nên cô lập chúng trong một VLAN riêng khi có thể

Bài viết liên quan

1 bình luận

 
GN⁺ 2024-01-29
Ý kiến trên Hacker News

  • Điều thú vị là có vẻ một số kẻ tấn công đang theo dõi nhật ký Certificate Transparency để tìm các chứng chỉ mới được cấp
    Nếu dựng một máy chủ mới trên IP mới và để đó hơn một tuần thì trong access log chỉ thấy vài lượt dò quét ngẫu nhiên, nhưng khoảng một giờ sau khi nhận chứng chỉ Let’s Encrypt thì đã nhiều lần có hàng trăm yêu cầu như trong bài viết đổ vào
    Kết luận là dịch vụ mới cần được bảo vệ càng sớm càng tốt, lý tưởng nhất là trước khi bị lộ ra Internet

    • Có cảm giác là ngay từ khoảnh khắc công khai đầu tiên cũng nên đặt ít nhất thứ như xác thực cơ bản ở phía trước
      Hoặc có thể dùng CA riêng, rồi dùng chứng chỉ tự ký và mTLS cho đến khi chuyển đổi
      Ví dụ, nếu phần mềm để lộ nguyên màn hình cài đặt ban đầu như tạo tài khoản quản trị, kết nối DB, thì sẽ rủi ro hơn cách chỉ định ngay từ đầu bằng biến môi trường, tệp cấu hình hoặc công cụ quản lý bí mật chuyên dụng
    • Gần đây tôi có xem qua nhật ký Certificate Transparency, và đang thắc mắc có công cụ hay cách nào tiện để truy vấn CT log không
      Ví dụ như tìm domain trong một khoảng thời gian nhất định
      Merkle Town của Cloudflare[0] hữu ích để xem tổng quan, nhưng tôi vẫn chưa tìm ra cách dễ để truy vấn CT log, còn ct-woodpecker[1] thì có vẻ đầy hứa hẹn
      [0] https://ct.cloudflare.com/
      [1] https://github.com/letsencrypt/ct-woodpecker
    • Dùng chứng chỉ wildcard nhiều hơn cũng hữu ích. Chỉ dựa vào CT log sẽ khó biết được subdomain cụ thể để tấn công
    • Nhiều trường hợp đây không hẳn là kẻ tấn công, mà là các dịch vụ như urlscan.io đang theo dõi CT log rồi crawl web để tìm mã độc
    • Tôi tự host nhiều dịch vụ, nhưng đã hoàn toàn từ bỏ việc phơi chúng trực tiếp ra Internet
      VPN bây giờ quá tốt nên tôi thấy yên tâm hơn nhiều, và đặc biệt những thứ như lưu trữ ảnh hay sao lưu thì tôi không hề muốn công khai ra ngoài

  • Khi mới bắt đầu quản lý các site tự host, tôi cũng xem access log, và một thời gian còn dùng hệ thống phát hiện xâm nhập để thu thập dữ liệu và hiển thị các nỗ lực tấn công đi vào
    Cuối cùng tôi ngừng cả việc chủ động xem log lẫn trả tiền cho hệ thống phát hiện xâm nhập vì đó là việc tốn thời gian và gây xao nhãng
    Rất dễ tìm được các tài liệu tóm tắt tốt về những lỗ hổng và kiểu tấn công phổ biến, nên chỉ cần lấy đó làm tiêu chuẩn quản trị máy chủ. Với mỗi công nghệ web server phổ biến đều có rất nhiều hướng dẫn best practice, và chỉ cần thực hiện 100% những điều đó thôi cũng đã đi trước gần như mọi kẻ tấn công rồi
    Sau đó, cách dùng thời gian và tài nguyên hiệu quả nhất là ưu tiên chu kỳ vá lỗi nhanh nhất có thể. Phần lớn các cuộc tấn công nhắm vào lỗ hổng đã được công khai
    Log đặc biệt hữu ích khi chẩn đoán sau khi sự cố đã xảy ra. Phần mềm phân tích log đã giúp tôi 2~3 lần trong việc lưu trữ và tìm kiếm để xác định nguyên nhân gốc của các cuộc tấn công thành công, và lần nào nguyên nhân cũng là lỗ hổng đã biết nhưng vá quá muộn

    • Nếu tất cả các trường hợp đều là lỗ hổng đã biết nhưng vá muộn, thì cách chỉ dựa vào vá lỗi sớm muộn cũng sẽ thất bại. Có thể là lỗ hổng zero-day hoặc kẻ tấn công nhanh hơn
      Giải pháp là phòng thủ nhiều lớp, và khi tự host dịch vụ cá nhân thì phần lớn đều khá dễ áp dụng
      Đặt firewall ở phía trước hoặc giấu sau VPN/Tailscale, rồi giấu trong subfolder như /mawer/phpmyadmin/ thay vì /phpmyadmin/ mà các đợt tấn công tự động thường nhắm tới thì 99,9% sẽ không tìm thấy. Đây là bảo mật nhờ che giấu nên không được chỉ dựa vào nó, nhưng như một lớp bổ sung thì rất hữu ích
      Cần sandbox ứng dụng và cô lập máy chủ để dù bị xâm nhập cũng khó di chuyển sang nơi khác, đồng thời phải ghi log để có thể xác nhận có bị tấn công hay không và tấn công có thành công hay không
      Điểm mấu chốt là không được chỉ dựa vào một biện pháp phòng thủ duy nhất, dù là vá lỗi hay firewall. Cuối cùng thì một thứ nào đó cũng sẽ thất bại
    • Tôi tò mò về ý ưu tiên chu kỳ vá lỗi nhanh nhất. Khi quyết định thời điểm vá, bạn có dùng công cụ nào không, hay chỉ theo mốc thời gian?
      Hiện tại tôi cố cập nhật package mỗi quý[0], nhưng sẽ rất tốt nếu có công cụ báo các lỗ hổng đã biết để có thể phản ứng ngay
      [0] Ở đây “cố” nghĩa là nếu có thay đổi phá vỡ tương thích khiến khó áp dụng lên bản mới nhất, hoặc là bản phát hành X.0.0 mà tôi chưa tin tưởng, thì tôi không thể nâng cấp ngay

  • Vì tác giả nói mình không phải chuyên gia bảo mật nên xin chỉnh một chi tiết nhỏ: ví dụ ở đầu là dò tìm thông tin xác thực/cấu hình, chứ không phải directory traversal
    Theo tôi hiểu thì directory traversal là cách nói cho kỹ thuật dùng khi kẻ tấn công “thoát” khỏi web root hoặc lừa máy chủ phục vụ tệp nằm ngoài thư mục hợp lệ

    • Nếu là kiểu chèn thêm tệp vốn không nên được host thì về mặt kỹ thuật có thể là cả hai. Ví dụ như "/../../passwd/etc"

  • Ít nhất theo kinh nghiệm của tôi, điểm mấu chốt là một phần đáng kể các cuộc tấn công kiểu này đến từ các tác nhân nhà nước thù địch
    Có thể gây tranh cãi, nhưng chặn toàn bộ dải IP của những quốc gia có vấn đề mà bạn không có giao dịch gì với họ có thể hữu ích. Tôi từng chặn được 100% các lượt dò quét vào một dịch vụ mới bằng cách này

    • Vấn đề chính không phải vậy, mà là nhiều người không muốn chặn cả người dùng hợp pháp ở khu vực đó
    • Giá mà các tác nhân cấp quốc gia hoàn toàn không có cách mua máy chủ ở nước khác rồi phát động tấn công từ đó
    • Hơn 15 năm trước, khi xem log máy chủ của các doanh nghiệp địa phương nhỏ mà chúng tôi host, tôi đã đi đến kết luận rằng có thể chặn toàn bộ địa chỉ IP APNIC
    • Tôi nghĩ chặn theo khu vực rốt cuộc chỉ chặn lưu lượng hợp pháp và khiến kẻ tấn công có động cơ thì chuyển sang dùng proxy mà thôi
    • Làm vậy thì phải chặn cả Mỹ và Hà Lan
      Phần lớn các lượt dò quét vào máy chủ của tôi đến từ Mỹ, và xếp thứ hai khá xa là Hà Lan. Có lẽ phần lớn đến từ AWS và các datacenter khác

  • Tôi làm trong lĩnh vực bảo mật ứng dụng/sản phẩm và đã quản lý WAF cho các công ty trị giá hàng chục tỷ đô trong nhiều năm
    Chỉ cần chuyển DNS sang Cloudflare và đặt vài quy tắc WAF cho trang. Ví dụ, nếu điểm bot dưới 2 thì áp dụng managed challenge, hoặc xử lý khi điểm tấn công ở một ngưỡng nhất định. Có lẽ chi phí cũng gần như không đáng kể và sẽ giải quyết được khá nhiều vấn đề
    Tuy vậy, nhất định phải thử nghiệm trước khi đưa sang production. Có một domain để test riêng cũng rất tốt. WAF không phải giải pháp vạn năng mà gần giống một biện pháp tình thế; nếu bản thân ứng dụng không được gia cố để chịu được tấn công, thì dù dùng WAF hay bot protection cao cấp đến đâu cũng không cứu nổi

    • Ghi lại cho những ai chưa quen: https://blog.cloudflare.com/waf-for-everyone/
      Có vẻ Free Managed Ruleset được triển khai mặc định, và Cloudflare duy trì change log ở đây: https://developers.cloudflare.com/waf/change-log
    • Ở góc độ tự host, tôi dùng WAF của CloudFlare cùng quy tắc mutual TLS để chỉ cho những bên gọi hợp lệ mà tôi biết đi qua
      Nó hoạt động rất tốt. Vì người truy cập chỉ là người nhà nên việc cấu hình cũng dễ, và mỗi người được cấp chứng chỉ riêng để có thể thu hồi khi cần
    • Dạo này tôi chủ yếu chỉ quản lý ứng dụng nội bộ nên bề mặt tấn công nhỏ hơn nhiều so với dịch vụ công khai
      Có vẻ bạn hiểu khá rõ mảng này nên tôi muốn hỏi là bạn đã từng quản lý giải pháp dùng chung Azure infrastructure với Cloudflare chưa, và nếu có thì ngoài những thứ phổ biến kiểu OWASP ra, có điểm nào mọi người hay bỏ sót không
    • Khá hợp với một site WordPress tiêu chuẩn, và có thể gắn thêm plugin GuardGiant và Sucuri như một lớp bổ sung
    • Nghĩ rằng đặt WAF trước ứng dụng là xong thì cũng chẳng khác gì tô son cho lợn
      Nếu công ty nào đó vì lý do nào đó buộc phải vận hành thứ không ở trạng thái cập nhật mới nhất thì có thể cần, nhưng rốt cuộc nó chỉ là biện pháp tạm thời

  • Tôi đang tự host một HTTP/S server 400 dòng do chính mình thiết kế được khoảng 1 năm, và lượng traffic tấn công đi vào 3 cổng mở (22, 80, 443) nhiều đến mức đáng ngạc nhiên
    Nhưng tôi chưa dành thời gian phân tích xem kẻ tấn công thực sự định làm gì, nên bài này đã lấp được khá nhiều chỗ trống
    Có lẽ cũng nên phân tích những thứ kỳ lạ xuất hiện trong /var/log/auth.log theo cách tương tự
    Toàn bộ code đều là mã nguồn mở và cũng không có trạng thái phía server, nên việc kẻ tấn công nhắm vào tôi nghe khá lạ. Thứ tốt nhất chúng có thể lấy được cùng lắm là quyền root trên một VPS 5 đô/tháng và khả năng chỉnh sửa tạm thời một domain chẳng có ai ghé

    • Toàn bộ đây là bot tự động. Không có ai thực sự bận tâm đến bạn cả
      Chỉ cần mở 3 cổng nổi tiếng nhất là sẽ có kết nối đổ vào, chúng không biết bạn đang chạy gì và cũng không quan tâm
    • Nếu truy cập được VPN của bạn, đó sẽ là điểm xuất phát tốt để tấn công các máy khác và thêm một lớp che giấu dấu vết
      Chúng cũng có thể host malware hoặc chạy cryptominer
    • Có thể đáng để cân nhắc chỉ cho phép IP của chính bạn vào cổng 22 và chặn phần còn lại
      ISP của tôi thực tế gần như không đổi IP, và nếu có đổi thì tôi có thể đăng nhập vào bảng quản trị host web để cập nhật quy tắc

  • Tôi luôn chạy fail2ban trên mọi server, và còn thêm custom jail để bắt các kiểu tấn công phù hợp với loại chức năng site đang phơi ra
    Tuy vậy, đã lâu rồi tôi chưa kiểm tra xem các giá trị mặc định khác của fail2ban còn đủ để chặn những cuộc tấn công phổ biến hay không. Phải bookmark liên kết này để xem sau mới được

    • Nếu hệ thống đang lộ ra lỗ hổng dễ bị nhắm tới như vậy thì fail2ban sẽ không cứu được bạn

  • Tôi cũng xem access log của các dịch vụ tự host, và có một chi tiết đáng chú ý bị thiếu trong phân tích này
    Phần lớn các request độc hại là do người bình thường chạy các security scanner có thể kiếm dễ dàng trên GitHub và những nơi tương tự. Hầu hết là các đòn tấn công không tinh vi, kiểu các instance của những project đó cứ đập vào server mà thậm chí không xem phản hồi hay quan tâm liệu chúng có bị rate limit hay không
    Một số cuộc tấn công không nhắm trực tiếp vào IP mà theo dõi domain và subdomain, rồi lặp lại cùng một đợt scan theo chu kỳ từ cùng dải IP
    Ở chỗ làm cũ của tôi, từng có các đợt quét lặp đi lặp lại từ một IP tĩnh duy nhất ở Thổ Nhĩ Kỳ, đến mức cả team bắt đầu gọi đó là “người Thổ”, và khi thấy các mẫu request lạ thì bước đầu tiên trong quy trình ứng phó sự cố là kiểm tra xem người đó có đang đụng vào dịch vụ của chúng tôi hay không

  • Nếu bạn đang xem các log kiểu này trên AWS, thì làm ơn hãy đặt AWS WAF trước VPC
    Nó không đắt và khá hữu ích để giảm rất nhiều phiền toái trong những tình huống như thế này. Dù không chặn được mọi thứ đi đến dịch vụ, nó vẫn có thể giúp rất nhiều

    • Gợi ý hay, nhưng cần cẩn thận với bộ quy tắc mặc định. Chúng tôi bật AWS WAF vì yêu cầu tuân thủ SOC 2
      Một vài quy tắc hoạt động quá tay đã âm thầm làm hỏng một phần ứng dụng
      Có một quy tắc request body chặn nếu phần thân request chứa "localhost", và cũng có quy tắc chặn request không có header User-Agent. Trước đây chúng tôi không yêu cầu User-Agent cho API request, nên nó đã làm hỏng toàn bộ API của một số người dùng cho đến khi chúng tôi tìm ra nguyên nhân
    • Các cuộc tấn công trong bài sẽ không phải vấn đề với bất kỳ ứng dụng web hiện đại nào. Vì vậy tôi không hiểu tại sao phải thêm WAF
    • Dùng bộ quy tắc mặc định của AWS WAF không hề dễ đến vậy. Trong ứng dụng của chúng tôi, rất nhiều request và IP hợp lệ đã bị chặn
      Bạn cần biết cái gì đang bị chặn và xác minh trước, nếu không thì trong một số trường hợp bạn sẽ mất khách hàng
    • Thực tế thì WAF thường gây hại nhiều hơn lợi
      Nó dễ bị vượt qua nhưng lại tạo ảo giác là đã có bảo mật, chi phí hiệu năng cũng lớn, và còn có khả năng đáng kể chặn nhầm traffic hợp lệ: https://www.macchaffee.com/blog/2023/wafs/
    • WAF có xu hướng chặn rất rộng, đôi khi lý do cũng không rõ ràng
      Ví dụ, các nhà nghiên cứu ở trường đại học của chúng tôi nghiên cứu dữ liệu Twitter, và chỉ vì đi theo liên kết từ một mẫu tweet ngẫu nhiên nhỏ mà IP của trường đã bị hầu hết WAF chặn

  • Đôi khi tôi nghĩ rằng sẽ khá thú vị nếu dựng một máy chủ Express phản hồi đúng kiểu cho một trong những cuộc tấn công này để làm ai đó tốn thời gian
    Nhưng làm vậy thì thời gian của tôi cũng bị lãng phí