CÓ HƯỚNG DẪN DEMO CỤ THỂ CÁC BƯỚC Đề tài được thực hiện nhằm mục đích tìm hiểu về nghiên cứu công nghệ WAF và triển khai bảo vệ hệ thống website với WAF mã nguồn mở cụ thể là ModSecurity. Chương 1: Tổng quan về WAF11.1. Giới thiệu chung về WAF11.1.1. Khái niệm WAF11.1.2. Phân loại WAF11.1.3. So sánh WAF với NetworkFirewall và IDSIPS31.1.4. Hoạt động của tường lửa ứng dụng web41.1.5. Lợi ích và tầm quan trọng của WAF51.2. Kiến trúc WAF61.2.1. Vị trí đặt WAF61.2.2. Mô hình bảo mật71.2.3. Mô hình hoạt động71.3. Các phiên bản WAF mã nguồn mở phổ biến81.3.1. ModSecurity81.3.2. WebKnight81.3.3. Shadow Daemon91.3.4. NAXSI91.3.5. F5 Advance91.4. Kết luận Chương 110Chương 2: Giới thiệu về ModSecurity WAF102.1. Tổng quan về ModSecurity102.2. Chức năng của ModSecurity112.3. Cấu trúc rule trong ModSecurity12
Tổng quan về WAF
Giới thiệu chung về WAF
WAF, hay tường lửa ứng dụng web, là công cụ bảo vệ các ứng dụng web bằng cách lọc và theo dõi lưu lượng giữa web server và Internet WAF hoạt động dựa trên các quy tắc được gọi là chính sách, nhằm bảo vệ ứng dụng khỏi các lỗ hổng bằng cách loại bỏ lưu lượng truy cập độc hại.
Triển khai WAF trước ứng dụng web tạo ra một lớp bảo vệ giữa ứng dụng và Internet WAF hoạt động như một proxy ngược, bảo vệ máy chủ khỏi việc bị lộ thông tin bằng cách cho phép máy khách truy cập qua WAF trước khi đến máy chủ.
WAF (Web Application Firewall) là một công cụ bảo mật quan trọng giúp bảo vệ ứng dụng web khỏi các mối đe dọa Có nhiều loại WAF khác nhau, được phân loại dựa trên mô hình tường lửa có thể định cấu hình, tùy thuộc vào loại hoạt động bảo mật mà người dùng yêu cầu.
Cấu hình WAF này bảo vệ các trang web và ứng dụng trực tuyến khỏi các cuộc tấn công bằng cách lọc dữ liệu thông qua danh sách các mối đe dọa đã biết, được gọi là Blocklist Bạn có thể tạo Blocklist một cách tự động hoặc thủ công.
Khi tường lửa phát hiện các gói dữ liệu khớp với các mối đe dọa trong danh sách chặn, nó sẽ ngay lập tức ngăn chặn chúng.
Blocklist có khả năng phát hiện và chặn các mối đe dọa ngụy trang dưới dạng yêu cầu hợp lệ trong lưu lượng mạng Nó giúp ngăn chặn hiệu quả các mối đe dọa đã biết, bao gồm cả các cuộc tấn công DDoS.
Một trong những thiếu sót chính của nó là không hiệu quả trong việc đối phó với các mối đe dọa mới, đặc biệt là các cuộc tấn công zero-day, mà các tổ chức đang phải đối mặt.
Tường lửa WAF giám sát việc truyền dữ liệu thông qua cấu hình bảo mật, được lập trình để chỉ cho phép lưu lượng mạng đã được phê duyệt trước.
Việc kích hoạt Allowlist cho trang web và ứng dụng web của bạn có thể gây ra sự cố, vì danh sách này thường ngăn chặn các yêu cầu an toàn không gây hại cho hệ thống Điều này xảy ra do thiết kế của Allowlist, chặn tất cả lưu lượng truy cập mạng vào ứng dụng web, chỉ cho phép những người đã được phê duyệt trong danh sách cho phép.
Tường lửa ứng dụng web (WAF) kết hợp cả danh sách cho phép (Allowlist) và danh sách chặn (Blocklist) để tạo ra cấu hình bảo mật hiệu quả Theo mô hình triển khai, WAF có ba phương thức chính được xây dựng và sử dụng trực tuyến, mỗi phương thức phục vụ cho các trường hợp khác nhau.
Network-Based (Nền tảng mạng lưới):
Network-Based được triển khai cục bộ trên mạng, với đặc điểm nổi bật là yêu cầu bảo trì và không gian lưu trữ Mục tiêu chính của nó là giảm thiểu độ trễ, và đây là một WAF dựa trên phần cứng.
Cloud-Based (Nền tảng đám mây):
Cloud-Based hoạt động trên nền tảng đám mây với quy trình cài đặt đơn giản, thường chỉ cần thay đổi DNS Giải pháp này không chỉ dễ dàng cài đặt mà còn mang lại nhiều lợi ích, bao gồm sự tiện lợi khi không cần lưu trữ hay bảo trì tại chỗ Đây là lựa chọn WAF tiết kiệm nhất.
Phương pháp này thường là dịch vụ đăng ký, trong đó các doanh nghiệp chuyển giao bảo mật WAF của họ cho một công ty khác nhằm tối ưu hóa quy trình và giải quyết các khó khăn tiềm ẩn.
Host-Based (Nền tảng máy chủ):
WAF loại thứ ba thường được các công ty sử dụng là WAF dựa trên máy chủ (Host-Based), mang lại khả năng tùy chỉnh cao hơn Tuy nhiên, phương pháp này yêu cầu phải chạy trên các máy chủ cục bộ và cần bảo trì tại chỗ, dẫn đến chi phí cao.
Cloud-Based là giải pháp được khách hàng ưa chuộng nhờ vào tính đơn giản và tiện lợi, giúp giải phóng họ khỏi chi phí lưu trữ và bảo trì.
1.1.3 So sánh WAF với NetworkFirewall và IDS/IPS
Kiến trúc WAF
Các thiết bị WAF cứng thường được lắp đặt giữa tường lửa mạng và máy chủ ứng dụng web, đảm bảo rằng tất cả lưu lượng truy cập đến ứng dụng web đều phải đi qua WAF Tuy nhiên, có những trường hợp ngoại lệ khi WAF chỉ được sử dụng để giám sát các cổng mở trên máy chủ web Bên cạnh đó, các chương trình WAF cũng có thể được cài đặt trực tiếp trên máy chủ web, thực hiện các chức năng tương tự như thiết bị WAF để theo dõi lưu lượng vào và ra khỏi ứng dụng web.
Hình 1.5: Vị trí đặt WAF 1.2.2 Mô hình bảo mật
Một WAF hoạt động dựa theo 2 mô hình bảo mật: Positive và Negative.
Mô hình Positive chỉ cho phép các lưu lượng hợp lệ đã được định nghĩa sẵn, trong khi mô hình Negative cho phép tất cả lưu lượng và chỉ chặn những lưu lượng mà WAF xác định là nguy hại Một số WAF cung cấp cả hai mô hình, nhưng thường chỉ có một trong hai Mô hình Positive yêu cầu nhiều cấu hình và tùy chỉnh, trong khi mô hình Negative chủ yếu dựa vào khả năng học hỏi và phân tích hành vi của lưu lượng mạng.
1.2.3 Mô hình hoạt động
WAF có thể hoạt động ở các mô hình riêng biệt, dưới đây là một số mô hình tham khảo:
Reverse Proxy là chức năng phổ biến trong triển khai WAF, nơi WAF giám sát toàn bộ lưu lượng truy cập đến ứng dụng web Thay vì cho phép các địa chỉ IP bên ngoài gửi yêu cầu trực tiếp đến máy chủ web, WAF hoạt động như một trung gian, chuyển tiếp các yêu cầu từ trình duyệt đến máy chủ và trả lại kết quả cho các địa chỉ IP đó Tuy nhiên, mô hình này có nhược điểm là gây ra độ trễ trong kết nối giữa trình duyệt và ứng dụng web.
Proxy trong suốt (Transparent Proxy) hoạt động như một WAF giữa tường lửa mạng và máy chủ web, tương tự như mô hình Reverse Proxy nhưng không làm trung gian kết nối Mô hình này không yêu cầu thay đổi hạ tầng mạng, tuy nhiên, có thể không cung cấp đầy đủ các dịch vụ như mô hình Reverse Proxy.
Layer 2 Bridge: Trong mô hình này, WAF hoạt động như một thiết bị Switch ở lớp 2, nằm giữa tường lửa mạng và máy chủ web Mô hình này mang lại hiệu suất cao cho mạng và không làm thay đổi cấu trúc mạng đáng kể, nhưng lại không cung cấp các dịch vụ cao cấp như các mô hình WAF khác.
Phần mềm Host/Server Based được cài trực tiếp lên máy chủ web, không cung cấp các tính năng tương tự như WAF network base Mặc dù mô hình này có thể khắc phục một số điểm yếu của các thiết bị WAF cứng, nhưng nó cũng làm tăng mức độ tải cho máy chủ web.
Các phiên bản WAF mã nguồn mở phổ biến
ModSecurity là một module mở rộng cho các web server như Apache, Nginx và IIS, hoạt động như một firewall tại lớp ứng dụng web Nó đứng trước Web Server để kiểm soát truy cập, đảm bảo an toàn cho thông tin đi vào và ra khỏi Web Server, ngăn chặn các mối đe dọa và rò rỉ thông tin nhạy cảm từ Web Server đến Client.
ModSecurity có mục đích tăng cường bảo mật cho các ứng dụng web, bảo vệ chúng khỏi các tấn công đã biết và chưa biết ModSecurity giúp hạn chế các vấn đề bảo mật hiệu quả.
Là 1 sản phẩm dành cho các máy chủ web IIS sử dụng bộ lọc ISAPI bảo vệ máy chủ web của bạn bằng cách chặn các yêu cầu xấu Nó giúp ngăn chặn 1 số vấn đề sau:
Là một bộ công cụ thiết yếu để phát hiện, ghi lại và ngăn chặn các cuộc tấn công vào ứng dụng web, hỗ trợ các ngôn ngữ lập trình như PHP, Perl và Python, nó có khả năng phát hiện nhiều vấn đề bảo mật quan trọng.
NAXSI, viết tắt của Nginx Anti XSS and SQL Injection, là một module tường lửa ứng dụng web (WAF) mã nguồn mở, có hiệu năng cao cho Nginx Nó chủ yếu hoạt động bằng cách phân tích và tìm kiếm các ký tự đặc biệt hoặc không mong muốn trong các yêu cầu HTTP GET và POST.
Cách tính năng WAF F5 Advanced như:
-Bảo vệ ứng dụng nâng cao:kết hợp máy học thông minh để tìm ra các mối đe dọa tinh vi.
-Chống tấn công Botnet: Bảo vệ ứng dụng khỏi các cuộc tấn công tự động bởi bot và các công cụ độc hại khác.
Chống bot SDK cho ứng dụng di động cung cấp giải pháp bảo vệ hiệu quả thông qua việc sử dụng danh sách cho phép, phân tích hành vi người dùng, xác thực cookie an toàn và nâng cao tính năng bảo mật của ứng dụng.
-Mã hóa dữ liệu trong trình duyệt.
Chống tấn công DDoS có chủ đích sử dụng phân tích hành vi và máy học thông minh để phát hiện và giảm thiểu hiệu quả các cuộc tấn công DDoS Layer 7, đảm bảo độ chính xác cao trong quá trình bảo vệ hệ thống.
-Bảo mật giao thức API: Triển khai các công cụ bảo mật API REST/JSON, XML và GWT.
Kết luận Chương 1
WAF (Web Application Firewall) là giải pháp tối ưu và hiệu quả nhất để bảo vệ an toàn cho người quản trị và người dùng, đồng thời giảm thiểu các rủi ro về bảo mật.
Tường lửa bảo vệ ứng dụng Web (WAF) giúp ngăn chặn và giảm thiểu các cuộc tấn công lỗ hổng ở lớp ứng dụng như SQL injection, cross-site scripting, botnet và DDoS attacks, mà các tường lửa thông thường không thể xử lý Hệ thống cũng cung cấp cảnh báo về các cuộc tấn công và đề xuất giải pháp để ngăn chặn các lỗ hổng đã được phát hiện.
Giới thiệu về ModSecurity WAF
Tổng quan về ModSecurity
Mod Security, do Ivan Ristic phát triển, là một module tường lửa tích hợp với các Web Application Server như Apache, IIS và Nginx Nó hoạt động như một firewall trước Web Server, kiểm soát truy cập vào và ra khỏi Web Server Mod Security đảm bảo rằng tất cả thông tin từ bên ngoài vào và từ bên trong ra đều được kiểm soát chặt chẽ, nhằm ngăn chặn các mối đe dọa có thể gây hại cho Web Server và ngăn chặn việc rò rỉ thông tin nhạy cảm từ Web Server đến Client.
ModSecurity nhằm tăng cường bảo mật cho ứng dụng web, bảo vệ khỏi các tấn công đã biết và chưa biết Để đối phó với sự gia tăng các phương pháp tấn công, ModSecurity đã cập nhật các quy tắc và cung cấp nhiều biện pháp phòng chống trong mã nguồn Một số tính năng của ModSecurity có thể được sử dụng như một tường lửa ứng dụng web.
Phân tích luồng HTTP theo tiêu chí nhất định thường gặp khó khăn trong việc so trùng mẫu mong muốn Mỗi hệ thống web có nhu cầu khác nhau, dẫn đến việc phân tích ứng dụng cũng khác biệt Mod_security, kết hợp với OWASP, đã phát triển các tập rule mẫu (Core Rule Set) để tạo tính linh động cho các mô hình web khác nhau, hỗ trợ người quản trị trong việc phân tích theo nhu cầu thực tế của hệ thống.
Mod Security chỉ thực hiện các tác vụ khi người quản trị viên chỉ định công việc cụ thể, điều này rất quan trọng trong ứng dụng phân tích nguy cơ như ModSecurity Tất cả các cảnh báo sẽ được xử lý thông qua cơ chế phân tích, và quyết định tương tác với hệ thống sẽ do người quản trị thực hiện.
ModSecurity hoạt động với chương trình web server (ví dụ: Apache) sẽ thực hiện các tác vụ như sau:
ModSecurity phân tích dữ liệu lưu chuyển trong hệ thống và chuyển đổi chúng thành cấu trúc dữ liệu đã được định nghĩa Cấu trúc này sau đó được sử dụng trong cơ chế so trùng mẫu để kiểm tra và đánh giá nguy cơ dựa trên tập rule.
Chức năng buffer trong ModSecurity rất quan trọng, vì tất cả các request gửi đến ứng dụng web phải qua ModSecurity trước khi được xử lý Tương tự, các response cũng được phân tích trước khi gửi về client Cơ chế này giúp ngăn chặn các cuộc tấn công thời gian thực, với dữ liệu như request body và response data được lưu trữ trong RAM để phân tích.
ModSecurity cung cấp khả năng ghi nhật ký các gói tin HTTP, bao gồm tiêu đề yêu cầu, nội dung yêu cầu, tiêu đề phản hồi và nội dung phản hồi Điều này giúp người quản trị phân tích các nguy cơ mà hệ thống đang đối mặt, từ đó đưa ra quyết định kiểm soát hiệu quả.
Các tập mẫu trong ModSecurity rất quan trọng cho việc phát hiện và ngăn chặn các cuộc tấn công ModSecurity, cùng với dự án OWASP, đã phát triển bộ quy tắc OWASP ModSecurity CRS nhằm phân tích và bảo vệ hệ thống web khỏi các mối đe dọa.
Nhằm mục đích bảo vệ các ứng dụng web phổ biến, CRS phân loại nội dung các rule dựa trên các phương pháp tấn công:
-HTTP Protection: phát hiện các nguy cơ dựa trên giao thức HTTP như Method (GET HEAD POST …), phiên bản HTTP (1.0, 1.1)
-Real-time Blacklist Lookups: lọc các dãy IP nguy hiểm dựa vào một bên thứ ba.
-Web-based Malware Detection: xác định các mã độc trong nội dung trang web bằng cách sử dụng Google Safe Browsign API.
-HTTP Denial of Service Protections: chống lại dạng tấn công từ chối dịch vụ như HTTP Flooding và Slow HTTP DoS.
To protect against common web attacks, it is essential to identify prevalent threats targeting web applications Automation detection plays a crucial role in recognizing bots, crawlers, scanners, and other information-gathering activities.
-Integration with AV Scanning for File Uploads: phát hiện các mã độc, webshell, 0days thông qua các chức năng upload tập tin.
-Tracking Sensitive Data: theo dõi các hoạt động và chặn lộ thông tin thẻ tín dụng (trong trường hợp website có hoạt động thương mại điện tử).
-Trojan Protection: phát hiện các mẫu trojan.
-Identification of Application Defects: cảnh báo các lỗi trong quản lý cấy hình ứng dụng webserver.
-Error Detection and Hiding: gửi các mã thông báo lỗi giả về phía người dùng.
2.3 Cấu trúc rules trong ModSecurity
Tất cả hoạt động trong ModSecurity chủ yếu liên quan đến hai phần chính: cấu hình và các tập luật Cấu hình xác định cách thức xử lý dữ liệu, trong khi các tập luật quyết định hành vi thực hiện với dữ liệu đã được xử lý.
Một ví dụ về rule: SecRule ARGS "" log,deny,status:404
Cấu trúc chuẩn của một rule trong ModSecurity bao gồm 3 phần chính:
SecRule VARIABLES OPERATOR ACTIONS 2.3.1 VARIABLE
Các biến xác định vị trí dữ liệu mà ModSecurity sẽ tìm kiếm mẫu Trong ví dụ này, tham số ARGS được sử dụng để chỉ định việc tìm kiếm mẫu trong tất cả các tham số của yêu cầu.
Các tham số thường thấy của VARIABLES:
REMOTE_ADDR: Địa chỉ IP của client.
REMOTE_HOST: Hostname của client (nếu tồn tại)
REMOTE_USER: Authenticated username (nếu tồn tại)
REMOTE_IDENT: Remote Username (lấy từ inetd, ít dùng)
REQUEST_METHOD: Request Method (GET, HEAD, POST )
SCRIPT_FILENAME: Đường dẫn đầy đủ của script được thực thi.
PATH_INFO: Phần mở rộng của URI phía sau tên của một script.
Ví dụ: /archive.php/5 thì PATH_INFO là /5
QUERY_STRING: URI phía sau dấu ?.
Ví dụ /index.php?i=1 thì QUERY_STRING là i=1.
AUTH_TYPE: Basic hoặc Digest Authentication.
DOCUMENT_ROOT: Đường dẫn đến documentroot.
SERVER_ADMIN: Email của Server Administrator.
SERVER_NAME: Hostname của Server.
SERVER_ADDR: Địa chỉ IP của Server.
SERVER_PROTOCOL: Protocol, (ví dụ HTTP/1.1).
TIME_YEAR: Năm hiện tại (2014).
TIME_MON: Tháng hiện tại (12).
TIME_WDAY: Thứ tự ngày trong tuần (ví dụ 4 - Thursday).
TIME : Thời điểm hiện tại được viết theo cấu trúc: YmdHMS.
THE_REQUEST: Dòng đầu tiên của request vd: GET / HTTP/1.1.
FILENAME: Tên file được yêu cầu đến.
Một variables có thể bao gồm 1 hay nhiều phần dữ liệu Khi variable có nhiều hơn 1 giá trị thì ta gọi nó là collection.
Ví dụ: với variable ARGS ta có 2 thông số p, và q.
Có thể dùng 1 hay nhiều variables
SecRule ARGS|REQUEST_HEADERS:User-Agent dirty
ModSecurity sử dụng các operator để xác định cách thức tìm kiếm mẫu, cho phép áp dụng các biểu thức chính quy nhằm tạo ra cơ chế phân tích linh hoạt cho các quy tắc.
Sử dụng @ để chỉ ra đây là một operation
Sử dụng !@ để chỉ ra một operation negation
Toán tử @rx (regular expression) là một toán tử mặc định, được sử dụng khi không có một toán tử nào khác được chỉ định.
Actions in ModSecurity specify the response when a pattern match occurs For instance, the action defined as log, deny, status:404 indicates that when the pattern is detected in a packet, it will log the event, deny the packet, and return a 404 (Not Found) status code.
When a request violates a specific rule, ModSecurity executes an action If no action is specified in the rule, the default action will be applied There are three types of actions available.
Primary actions sẽ quyết định cho phép request tiếp tục hay không Mỗi rule chỉ có một primary action Có 4 primary actions:
-Deny: Request sẽ bị ngắt, ModSecurity sẽ trả về HTTP status code 500 hoặc là status code của bạn thiết lập trong chỉ thị status.
-Pass: Cho phép request tiếp tục được xử lý ở các rules tiếp theo.
Cho phép truy cập ngay lập tức và bỏ qua các phases khác (trừ phases logging) Để chỉ cho qua phase hiện tại, cần chỉ rõ allow:phase Việc này vẫn sẽ bị kiểm tra bởi các luật tại các phases sau Chỉ cho phép truy cập tới các request phases: allow:request, cho phép bỏ qua phase 1, 2 nhưng vẫn kiểm tra ở phase 3 trở đi.
-Redirect: Redirect một request đến một url nào đó.
Secondary actions sẽ bổ sung cho Primary actions, một rule có thể có nhiều Secondary actions
-Status : n: khi một Request vi phạm một rule nào đó thì ModSecurity có thể trả về các HTTP status code n thay vì status code 500 mặc định.
-exec: thực thi một lệnh nào đó nếu một request vi phạm.
-log: ghi log những request vi phạm rule.
-pause : n: ModSecurity sẽ đợi một thời gian n ms rồi mới trả về kết quả.
Chain: kết nối 2 hay nhiều rules lại với nhau.
Skipnext : n: ModSecurity sẽ bỏ qua n rules theo sau nó.
Khi một rule không chỉ rõ action thì rule đó sẽ dùng default action được thiết lập trong SecDefaultAction.
Ví dụ: SecDefaultAction "phase:2,deny,log,status:403"
2.4 Quy trình xử lý trong ModSecurity
Cấu trúc rule trong ModSecurity
-Tracking Sensitive Data: theo dõi các hoạt động và chặn lộ thông tin thẻ tín dụng (trong trường hợp website có hoạt động thương mại điện tử).
-Trojan Protection: phát hiện các mẫu trojan.
-Identification of Application Defects: cảnh báo các lỗi trong quản lý cấy hình ứng dụng webserver.
-Error Detection and Hiding: gửi các mã thông báo lỗi giả về phía người dùng.
2.3 Cấu trúc rules trong ModSecurity
Tất cả hoạt động trong ModSecurity chủ yếu liên quan đến hai phần chính: cấu hình và các tập luật Cấu hình xác định cách thức xử lý dữ liệu, trong khi các tập luật quyết định hành vi thực hiện với dữ liệu đã được xử lý.
Một ví dụ về rule: SecRule ARGS "" log,deny,status:404
Cấu trúc chuẩn của một rule trong ModSecurity bao gồm 3 phần chính:
SecRule VARIABLES OPERATOR ACTIONS 2.3.1 VARIABLE
Các biến xác định vị trí dữ liệu mà ModSecurity sẽ tìm kiếm mẫu Trong ví dụ này, tham số ARGS được sử dụng để chỉ định việc tìm kiếm mẫu trong tất cả các tham số của yêu cầu.
Các tham số thường thấy của VARIABLES:
REMOTE_ADDR: Địa chỉ IP của client.
REMOTE_HOST: Hostname của client (nếu tồn tại)
REMOTE_USER: Authenticated username (nếu tồn tại)
REMOTE_IDENT: Remote Username (lấy từ inetd, ít dùng)
REQUEST_METHOD: Request Method (GET, HEAD, POST )
SCRIPT_FILENAME: Đường dẫn đầy đủ của script được thực thi.
PATH_INFO: Phần mở rộng của URI phía sau tên của một script.
Ví dụ: /archive.php/5 thì PATH_INFO là /5
QUERY_STRING: URI phía sau dấu ?.
Ví dụ /index.php?i=1 thì QUERY_STRING là i=1.
AUTH_TYPE: Basic hoặc Digest Authentication.
DOCUMENT_ROOT: Đường dẫn đến documentroot.
SERVER_ADMIN: Email của Server Administrator.
SERVER_NAME: Hostname của Server.
SERVER_ADDR: Địa chỉ IP của Server.
SERVER_PROTOCOL: Protocol, (ví dụ HTTP/1.1).
TIME_YEAR: Năm hiện tại (2014).
TIME_MON: Tháng hiện tại (12).
TIME_WDAY: Thứ tự ngày trong tuần (ví dụ 4 - Thursday).
TIME : Thời điểm hiện tại được viết theo cấu trúc: YmdHMS.
THE_REQUEST: Dòng đầu tiên của request vd: GET / HTTP/1.1.
FILENAME: Tên file được yêu cầu đến.
Một variables có thể bao gồm 1 hay nhiều phần dữ liệu Khi variable có nhiều hơn 1 giá trị thì ta gọi nó là collection.
Ví dụ: với variable ARGS ta có 2 thông số p, và q.
Có thể dùng 1 hay nhiều variables
SecRule ARGS|REQUEST_HEADERS:User-Agent dirty
Operator trong ModSecurity xác định phương thức tìm kiếm mẫu, sử dụng biểu thức chính quy để tạo ra cơ chế phân tích linh hoạt cho các quy tắc.
Sử dụng @ để chỉ ra đây là một operation
Sử dụng !@ để chỉ ra một operation negation
Toán tử @rx (regular expression) là một toán tử mặc định, được sử dụng khi không có một toán tử nào khác được chỉ định.
Actions in ModSecurity specify the response to a matched pattern For instance, the action "log, deny, status:404" indicates that when the pattern is detected in a packet, it will log the event, deny the packet, and return a 404 (Not Found) status code.
When a request violates a specific rule, ModSecurity executes an action If no action is specified in the rule, the default action will be applied There are three types of actions available.
Primary actions sẽ quyết định cho phép request tiếp tục hay không Mỗi rule chỉ có một primary action Có 4 primary actions:
-Deny: Request sẽ bị ngắt, ModSecurity sẽ trả về HTTP status code 500 hoặc là status code của bạn thiết lập trong chỉ thị status.
-Pass: Cho phép request tiếp tục được xử lý ở các rules tiếp theo.
Cho phép truy cập ngay lập tức và bỏ qua các phases khác (trừ phase logging) Để chỉ cho qua phase hiện tại, cần chỉ rõ allow:phase Việc này vẫn sẽ bị kiểm tra bởi các luật tại các phases sau Chỉ cho phép truy cập tới các request phases: allow:request, cho phép bỏ qua phase 1, 2 nhưng vẫn kiểm tra ở phase 3 trở đi.
-Redirect: Redirect một request đến một url nào đó.
Secondary actions sẽ bổ sung cho Primary actions, một rule có thể có nhiều Secondary actions
-Status : n: khi một Request vi phạm một rule nào đó thì ModSecurity có thể trả về các HTTP status code n thay vì status code 500 mặc định.
-exec: thực thi một lệnh nào đó nếu một request vi phạm.
-log: ghi log những request vi phạm rule.
-pause : n: ModSecurity sẽ đợi một thời gian n ms rồi mới trả về kết quả.
Chain: kết nối 2 hay nhiều rules lại với nhau.
Skipnext : n: ModSecurity sẽ bỏ qua n rules theo sau nó.
Khi một rule không chỉ rõ action thì rule đó sẽ dùng default action được thiết lập trong SecDefaultAction.
Ví dụ: SecDefaultAction "phase:2,deny,log,status:403"
2.4 Quy trình xử lý trong ModSecurity
Trong ModSecurity, mỗi phiên phân tích trải qua 5 bước, và tại mỗi bước, ModSecurity thực hiện các quy tắc tương ứng để phát hiện và ngăn chặn các khai thác.
Hình 2.3: Quy trình xử lí của ModSecurity
Bước đầu tiên trong quá trình phân tích gói tin là Request Header, cho phép người viết rule tương tác với các request trước khi xử lý phần HTTP body Phân tích Request Header rất quan trọng để phát hiện các khai thác dựa vào HTTP method và URL, như SQL Injection, Reflect XSS, và Local File Include.
Bước 2 là quá trình kiểm tra chính khi client gửi request đến server, đặc biệt hiệu quả khi người dùng sử dụng phương thức POST hoặc PUT để upload tập tin Kiểm tra này đảm bảo dữ liệu được đưa lên server an toàn, ngăn chặn tình trạng upload mã độc và các dạng tấn công như Stored XSS hay Ajax Injection.
Các yêu cầu đã được xử lý tại server sẽ được gửi lại cho ModSecurity để kiểm tra trạng thái trong phần header của phản hồi Trước khi đọc phần body của phản hồi, ModSecurity sẽ dựa vào tập quy tắc để xác định xem có cần kiểm tra nội dung dữ liệu trong phần body hay không.
Ví dụ: mã trạng thái trả về là 404 (Not found) thì lúc này sẽ không cần kiểm tra nội dung gói tin trả về.
Sau khi ModSecurity hoàn tất kiểm tra tiêu đề phản hồi, nội dung trong phần thân sẽ được so sánh với các mẫu trong tập lệnh Phương pháp này rất hiệu quả trong việc phát hiện và ngăn chặn xâm nhập, đặc biệt khi các bước đầu tiên không phát hiện được tấn công.
Trong khai thác SQL injection, việc sử dụng công nghệ evasion có thể khiến cho việc phát hiện yêu cầu trở nên khó khăn Khi khai thác thành công, ModSecurity sẽ phân tích kết quả trong gói tin trả về để xác định xem câu truy vấn có thành công hay không.
Việc ghi log sẽ ghi nhận các cảnh báo cũng như quy trình làm việc của ModSecurity.
ModSecurity is a web application firewall (WAF) developed by Ivan Ristic for the Apache Web Server Similar to traditional firewalls, it filters incoming and outgoing data traffic to determine whether to block traffic that it suspects to be harmful based on predefined rules.
Nó còn có nhiều tính năng vượt trội khác như: HTTP transaction logging và content injection…
Các luật trong ModSecurity được tạo và chỉnh sửa bằng định dạng văn bản đơn giản, giúp việc viết rules trở nên dễ dàng hơn Khi đã quen thuộc với cú pháp, người dùng có thể nhanh chóng viết các rules để chặn các exploit mới hoặc ngăn ngừa lỗ hổng bảo mật.
ModSecurity hoạt động như một lớp bảo vệ giữa yêu cầu HTTP và máy chủ web httpd Khi phát hiện một cuộc tấn công, nó sẽ ghi lại thông tin chi tiết vào file log hoặc gửi email thông báo cho quản trị viên về sự cố bảo mật đang diễn ra trên hệ thống.
Kết luận Chương 2
ModSecurity is a web application firewall (WAF) developed by Ivan Ristic for the Apache Web Server Similar to traditional firewalls, it filters incoming and outgoing data traffic to determine whether to block traffic that it suspects to be harmful based on predefined rules.
Nó còn có nhiều tính năng vượt trội khác như: HTTP transaction logging và content injection…
Luật được tạo và chỉnh sửa bằng định dạng văn bản đơn giản, giúp việc viết rules trở nên dễ dàng hơn Khi đã quen với cú pháp của ModSecurity, người dùng có thể nhanh chóng viết các rules để chặn các exploit mới hoặc ngăn ngừa lỗ hổng bảo mật.
ModSecurity hoạt động như một lớp bảo vệ giữa yêu cầu HTTP và máy chủ web httpd Khi phát hiện một cuộc tấn công, nó sẽ ghi lại thông tin chi tiết vào file log hoặc gửi email thông báo cho quản trị viên về sự cố bảo mật đang diễn ra trên hệ thống.
ModSecurity cung cấp khả năng bảo vệ server của bạn bằng cách thiết lập các luật để đối phó với nhiều loại tấn công khác nhau Nhờ đó, ModSecurity trở thành một lớp bảo vệ bổ sung, giúp bạn tăng cường an ninh mà không cần phải thực hiện các bản vá.
ModSecurity giúp bạn theo dõi lưu lượng web một cách hiệu quả, đóng vai trò quan trọng trong bảo mật Khi có khả năng quan sát lưu lượng HTTP, bạn có thể phân tích, ghi lại và phản ứng kịp thời với các sự kiện trong thời gian thực Đặc biệt, tất cả những điều này có thể thực hiện mà không làm ảnh hưởng đến các ứng dụng web Hơn nữa, ModSecurity có thể áp dụng cho bất kỳ ứng dụng nào, ngay cả khi bạn không có quyền truy cập vào mã nguồn.
Chương kế tiếp sẽ triển khai ModSecurity hoạt động trên ApacheWebserver để chúng ta hiểu rõ hơn cách thức hoạt động và kết quả mà nó đem lại.
Triển khai WAF với ModSecurity
Mô hình thực nghiệm
Hình 3.1: Mô hình thực nghiệm
Các bước thực hiện
3.2.1 Cài đặt ModSecurity Để cài đặt và định cấu hình ModSecurity, cần có máy chủ Linux và đảm bảo web server Apache đã hoạt động tốt.
Cài đặt ModSecurity bằng câu lệnh thực hiện trên terminal: sudo apt install libapache2-mod-security2 -y
Ngoài ra, bạn cũng có thể cài đặt ModSecurity theo cách thủ công bằng cách sao chép kho lưu trữ ModSecurity Github.
Hình 3.2: Cài đặt ModSecurity 3.2.2 Cấu hình ModSecurity
ModSecurity là một tường lửa yêu cầu các quy tắc để hoạt động hiệu quả Trong phần này, chúng ta sẽ triển khai Bộ quy tắc cốt lõi của OWASP (OWASP-CRS) Đầu tiên, cần chuẩn bị tệp cấu hình cho ModSecurity.
Xóa phần mở rộng recommended khỏi tên tệp cấu hình ModSecurity bằng lệnh sau: sudo cp /etc/ModSecurity/ModSecurity.conf-recommended
Mở file /etc/ModSecurity/ModSecurity.conf và thay đổi giá trị cho SecRuleEngine thành On:
# Enable ModSecurity, attaching it to every transaction Use detection
# only to start with, because that minimises the chances of post- installation
Hình 3.3: nano /etc/ModSecurity/ModSecurity.conf
Khởi động lại Apache để áp dụng các thay đổi: sudo systemctl restart apache2
Bộ quy tắc cốt lõi ModSecurity OWASP (CRS) là một bộ quy tắc phát hiện tấn công chung, được thiết kế để bảo vệ các ứng dụng web khỏi nhiều loại tấn công, bao gồm cả Top Ten OWASP, với tối thiểu các cảnh báo sai CRS cung cấp sự bảo vệ hiệu quả chống lại các cuộc tấn công phổ biến như SQL injection, Cross Site Scripting (XSS) và Local File Inclusion Để thiết lập OWASP-CRS, bạn cần thực hiện theo các bước hướng dẫn cụ thể.
Trước tiên, xóa bộ quy tắc mặc định của ModSecurity bằng cách chạy lệnh sau: sudo rm -rf /usr/share/ModSecurity-crs
Sao chép kho lưu trữ OWASP-CRS GitHub vào thư mục
/usr/share/ModSecurity-crs: sudo git clone https://github.com/coreruleset/coreruleset
/usr/share/ModSecurity-crs Đổi tên file crs-setup.conf.example thành crs-setup.conf sudo mv /usr/share/ModSecurity-crs/crs-setup.conf.example
To rename the default exclusion rule file for ModSecurity, use the command: `sudo mv /usr/share/ModSecurity-crs/rules/REQUEST-900-EXCLUSION-RULES-BEFORE-CRS.conf.example`.
/usr/share/ModSecurity-crs/rules/REQUEST-900-EXCLUSION-RULES-
BEFORE-CRS.conf Để bắt đầu sử dụng ModSecurity, kích hoạt trong tệp cấu hình Apache bằng cách thực hiện theo các bước sau:
Chỉnh sửa tệp /etc/apache2/mods-available/security2.conf , thêm vào nội dung sau trên để bao gồm các tệp OWASP-CRS mà đã tải xuống:
Include /usr/share/ModSecurity-crs/crs-setup.conf
Include /usr/share/ModSecurity-crs/rules/*.conf
Hình 3.4: nano /etc/apache2/mod-available/security2.conf
Trong /etc/apache2/sites-enabled/000-default.conf tệp VirtualHost, thêm các nội dung sau bao gồm chỉ thị SecRuleEngine đặt thành On:
ErrorLog ${APACHE_LOG_DIR}/error.log
CustomLog ${APACHE_LOG_DIR}/access.log combined
Hình 3.5: nano /etc/apache2/sites-enabled/000-default.conf
Chỉ thị SecRuleEngine để ở chế độ DetectionOnly nghĩa là chỉ phát hiện tấn công và cảnh báo trong file error.log
Sau đó khởi động lại dịch vụ Apache2 để áp dụng cấu hình đã thay đổi sudo systemctl restart apache2
Chúng ta đã hoàn tất việc cài đặt ModSecurity và cấu hình với bộ quy tắc OWASP-CRS Sau khi các dịch vụ được thiết lập xong, chúng ta sẽ tiến hành thử nghiệm kết quả trên DVWA.
3.2.3 Cài đặt DVWA: Đầu tiên, khởi chạy Terminal và điều hướng đến thư mục /var/www/html
Tiếp theo, sao chép kho lưu trữ DVWA GitHub trong thư mục /html:
$ sudo git clone https://github.com/ethicalhack3r/DVWA
Hình 2: Clone DVWA Github
Sau khi sao chép thành công kho lưu trữ, xác nhận DVWA đã được sao chép thành công, chạy lệnh:
Hình 3.7: Download DVWA thành công
Để gán quyền Read, Write và Execute (777) cho thư mục DVWA, hãy sử dụng lệnh sau: \$\texttt{sudo chmod -R 777 DVWA}\$ Sau đó, bạn cần điều hướng đến thư mục để thiết lập và cấu hình DVWA.
/DVWA/config để xem nội dung thư mục cấu hình ta sẽ thấy được file cấu hình mặc định của DVWA là config.inc.php.dist
Tạo một bản sao của tệp này với tên config.inc.php sử dụng để định cấu hình DVWA. sudo cp config.inc.php.dist config.inc.php
Mở tệp vừa sao chép để thực hiện cấu hình cần thiết: sudo nano config.inc.php Đổi các thông tin như hình dưới đây:
Hình 3.8: Cấu hình DVWA
Kali Linux được cài đặt sẵn với hệ thống quản lý cơ sở dữ liệu MariaDB Để bắt đầu, hãy khởi động dịch vụ mysql bằng lệnh `sudo systemctl start mysql` Tiếp theo, đăng nhập vào cơ sở dữ liệu với quyền root và tạo người dùng mới dựa trên thông tin trong tệp config.inc.php tại /DVWA Cuối cùng, thực hiện các lệnh cần thiết và thoát sau khi hoàn tất.
MariaDB [(none)]> create user 'userDVWA'@'127.0.0.1' identified by
MariaDB [(none)]> grant all privileges on dvwa.* to
Khởi chạy lại dịch vụ Apache2 và Mysql. sudo systemctl start apache2 sudo systemctl start mysql
Sau khi cài đặt và cấu hình xong, bạn có thể truy cập DVWA qua trình duyệt web tại địa chỉ http://127.0.0.1/DVWA/setup.php Hãy nhấn vào nút "Create / Reset Database" để bắt đầu quá trình đăng nhập.
Hình 3.9: http://127.0.0.1/DVWA/setup.php
Sử dụng thông tin đăng nhập mặc định bên dưới để đăng nhập: Username: admin
Hình 3.10: http://127.0.0.1/DVWA/login.php
Hình 3.11: Giao diện DVWA khi đăng nhập thành công
Chọn mức Low ở mục DVWA Security để cài đặt mức độ thực hành tấn công.
3.2.4 Triển khai ModSecurity trên DVWA
Với vai trò một Attacker tại máy Client sử dụng phương thức XSS và SQL Injection tấn công website:
Kịch bản 1: Ngăn chặn tấn công SQL injection
Hình 3.12: Giao diện SQL injection ban đầu
Trước khi bật ModSecurity, tiêm câu truy vấn ' or 'x'='x vào, tấn công thành công vào cơ sở dữ liệu.
Hình 3.13: Tấn công SQL thành công
Sau khi mở ModSecurity, trực tiếp chặn truy cập:
Hình 3.14: Trang web sau khi bật ModSecurity(SQL)
Hình 3.15: Log ghi lại sau khi thực hiện tấn công SQL
Kịch bản 2: Ngăn chặn tấn công Cross Site Scripting (XSS)
Hình 3.16: Giao diện trang thực hiện tấn công XSS
Chèn mã script vào: alert(‘votramy’)
Hình 3.17: Tấn công XSS thành công
Sau khi mở ModSecurity với SecRuleEngine ở chế độ On, trực tiếp chặn truy cập:
Hình 3.18: Trang web sau khi bật ModSecurity (XSS)
Hình 3.19: Log ghi lại sau khi thực hiện tấn công XSS
Kết luận chương 3
Chương trình triển khai bảo vệ website bằng WAF ModSecurity đã thành công, cho phép người dùng nhận thấy rõ hoạt động và lợi ích của nó Với kiến thức về ModSecurity, người dùng có thể tự viết các quy tắc để tăng cường bảo vệ cho trang web của mình.