Đồ án: Nghiên cứu và ứng dụng ModSecurity để bảo vệ Web Server

Bảo vệ web server toàn diện với ModSecurity. Hướng dẫn A-Z chi tiết cách cài đặt, cấu hình và áp dụng các biện pháp an ninh chống tấn công mạng.

• Người hướng dẫn: TS. Lưu Thanh Trà
• Chuyên ngành: An Ninh Mạng
• Đề tài: Nghiên cứu ứng dụng Mod Security để bảo vệ web server
• Loại tài liệu: Đồ án nghiên cứu ứng dụng
• Năm xuất bản: 2013

Tóm tắt

I. Khám Phá ModSecurity Giải Pháp Tối Ưu Bảo Vệ Web Server

Trong bối cảnh an ninh mạng ngày càng phức tạp, việc bảo vệ máy chủ web không chỉ dừng lại ở các biện pháp tường lửa truyền thống. Đồ án này tập trung nghiên cứu ModSecurity, một giải pháp tường lửa ứng dụng web (WAF) mã nguồn mở, mạnh mẽ và linh hoạt. ModSecurity hoạt động như một module tích hợp trực tiếp vào các web server phổ biến như Apache và Nginx, cho phép can thiệp và phân tích lưu lượng HTTP ở tầng ứng dụng. Điều này mang lại khả năng phòng chống các cuộc tấn công tinh vi mà tường lửa mạng thông thường không thể phát hiện. Mục đích chính của nghiên cứu là triển khai một hệ thống bảo mật web server hoàn chỉnh, sử dụng ModSecurity kết hợp với OWASP Core Rule Set (OWASP CRS) – một bộ quy tắc được cộng đồng an ninh mạng toàn cầu công nhận. Sự kết hợp này tạo ra một lá chắn vững chắc, giúp phát hiện và ngăn chặn hiệu quả các mối đe dọa từ OWASP Top 10, bao gồm tấn công SQL Injection và tấn công XSS (Cross-Site Scripting). Đồ án không chỉ trình bày lý thuyết mà còn đi sâu vào các bước cài đặt ModSecurity và cấu hình ModSecurity chi tiết, cung cấp một cái nhìn thực tiễn cho các quản trị viên hệ thống và chuyên gia bảo mật. Đây là một tài liệu tham khảo giá trị cho các khóa luận tốt nghiệp an toàn thông tin hoặc báo cáo thực tập bảo mật, mang đến kiến thức nền tảng và ứng dụng thực tế về một trong những công cụ WAF hàng đầu hiện nay.

1.1. Hiểu đúng về tường lửa ứng dụng web WAF là gì

Một tường lửa ứng dụng web (WAF) là một lớp bảo vệ chuyên dụng cho các ứng dụng web. Khác với tường lửa mạng truyền thống chỉ kiểm tra lưu lượng ở tầng mạng và tầng giao vận (IP, port), WAF hoạt động ở tầng 7 (tầng ứng dụng) của mô hình OSI. Nó có khả năng giám sát, lọc và chặn lưu lượng HTTP/HTTPS đến và đi từ một ứng dụng web. Chức năng chính của WAF là bảo vệ ứng dụng khỏi các lỗ hổng web phổ biến như SQL Injection, Cross-Site Scripting (XSS), và Cross-Site Request Forgery (CSRF). Theo tài liệu nghiên cứu, các firewall truyền thống không đủ mạnh để bảo vệ web server trước các kỹ thuật tấn công hiện đại. ModSecurity chính là một WAF, cho phép can thiệp trực tiếp vào mức độ ứng dụng, phân tích sâu nội dung của các yêu cầu và phản hồi HTTP để xác định các hành vi độc hại. Đây là một thành phần cốt lõi trong chiến lược an ninh mạng toàn diện.

1.2. Giới thiệu ModSecurity và bộ quy tắc OWASP Core Rule Set

ModSecurity là một module mã nguồn mở, hoạt động như một hệ thống phát hiện và ngăn chặn xâm nhập (IDPS) cho ứng dụng web. Nó được phát triển để tích hợp với các web server hàng đầu như Apache, Nginx và IIS. Sức mạnh thực sự của ModSecurity được phát huy khi kết hợp với OWASP ModSecurity Core Rule Set (OWASP CRS). Đây là một tập hợp các quy tắc phát hiện tấn công chung được phát triển bởi dự án OWASP. CRS cung cấp khả năng bảo vệ chống lại nhiều loại tấn công, bao gồm các mối đe dọa trong danh sách OWASP Top 10. Bộ quy tắc ModSecurity này được cập nhật liên tục bởi cộng đồng chuyên gia bảo mật, đảm bảo khả năng đối phó với các kỹ thuật tấn công mới nhất. Việc triển khai CRS giúp đơn giản hóa quá trình cấu hình, cho phép các quản trị viên nhanh chóng thiết lập một hệ thống phòng chống tấn công web hiệu quả mà không cần phải tự viết từng quy tắc.

II. Thách Thức An Ninh Mạng Các Lỗ Hổng Web Server Phổ Biến

Các ứng dụng web hiện đại phải đối mặt với vô số mối đe dọa bảo mật. Việc không hiểu rõ các lỗ hổng web phổ biến có thể dẫn đến những hậu quả nghiêm trọng như mất mát dữ liệu, gián đoạn dịch vụ và tổn hại uy tín. Tài liệu OWASP Top Ten là một tiêu chuẩn được công nhận rộng rãi, liệt kê 10 rủi ro bảo mật nghiêm trọng nhất đối với các ứng dụng web. Trong đó, các cuộc tấn công như tấn công SQL Injection và tấn công XSS (Cross-Site Scripting) luôn chiếm vị trí hàng đầu. Tấn công SQL Injection cho phép kẻ tấn công thao túng các truy vấn cơ sở dữ liệu của ứng dụng, có thể dẫn đến truy cập trái phép, sửa đổi hoặc xóa dữ liệu. Trong khi đó, XSS cho phép chèn các mã kịch bản độc hại vào các trang web được người dùng khác xem, dẫn đến việc đánh cắp phiên làm việc hoặc thông tin cá nhân. Ngoài ra, các cuộc tấn công DoS/DDoS (Từ chối dịch vụ) cũng là một mối lo ngại lớn, có khả năng làm tê liệt hoàn toàn một web server bằng cách làm cạn kiệt tài nguyên hệ thống. Đồ án này nhấn mạnh rằng việc chỉ dựa vào các biện pháp bảo mật ở tầng mạng là không đủ để đối phó với những thách thức này, từ đó khẳng định vai trò thiết yếu của một tường lửa ứng dụng web như ModSecurity.

2.1. Phân tích tấn công SQL Injection và XSS theo OWASP Top 10

Theo tiêu chuẩn OWASP Top 10, Injection (A1) và Cross-Site Scripting (XSS) (A2) là hai trong số những lỗ hổng nguy hiểm và phổ biến nhất. Tấn công SQL Injection xảy ra khi dữ liệu do người dùng cung cấp không được xác thực đúng cách và được chèn trực tiếp vào một câu lệnh SQL. Kẻ tấn công có thể lợi dụng điều này để vượt qua cơ chế xác thực, đọc, sửa đổi hoặc xóa dữ liệu nhạy cảm. Tấn công XSS xuất hiện khi một ứng dụng web cho phép người dùng nhập dữ liệu mà không qua kiểm duyệt, sau đó hiển thị dữ liệu đó cho người dùng khác. Kẻ tấn công có thể chèn các mã kịch bản (ví dụ: JavaScript) để đánh cắp cookie phiên, thay đổi giao diện trang web (deface), hoặc chuyển hướng người dùng đến các trang độc hại. Cả hai loại tấn công này đều khai thác sự tin tưởng của ứng dụng vào dữ liệu đầu vào, nhấn mạnh sự cần thiết của việc lọc và xác thực mọi dữ liệu trước khi xử lý.

2.2. Nguy cơ từ tấn công DoS DDoS và Path Traversal

Bên cạnh Injection và XSS, tấn công DoS/DDoS (Từ chối dịch vụ/Từ chối dịch vụ phân tán) là một mối đe dọa nghiêm trọng đến tính sẵn sàng của web server. Các cuộc tấn công này làm quá tải máy chủ bằng cách gửi một lượng lớn yêu cầu, khiến máy chủ không thể xử lý các yêu cầu hợp lệ từ người dùng. Một lỗ hổng khác là Path Traversal, cho phép kẻ tấn công truy cập các tệp và thư mục được lưu trữ bên ngoài thư mục gốc của web. Bằng cách thao tác các biến với chuỗi ../, kẻ tấn công có thể đọc các tệp cấu hình nhạy cảm, mã nguồn hoặc các dữ liệu quan trọng khác trên hệ thống. Việc phòng chống tấn công web đòi hỏi một giải pháp có khả năng phân tích hành vi và nội dung yêu cầu, chứ không chỉ dựa vào địa chỉ IP hay cổng dịch vụ.

III. Phương Pháp Cài Đặt và Cấu Hình ModSecurity Chi Tiết Nhất

Việc triển khai thành công ModSecurity đòi hỏi một quy trình cài đặt ModSecurity và cấu hình ModSecurity cẩn thận và chính xác. Đồ án này cung cấp một hướng dẫn toàn diện, bắt đầu từ việc chuẩn bị môi trường trên hệ điều hành Linux và cài đặt các thư viện phụ thuộc cần thiết như libxml2 và pcre. Phương pháp cài đặt từ mã nguồn được ưu tiên để đảm bảo sử dụng phiên bản mới nhất và có khả năng tùy biến cao. Sau khi biên dịch và cài đặt thành công, bước tiếp theo là tích hợp module vào web server, ví dụ như Apache, bằng cách thêm chỉ thị LoadModule security2_module. Quá trình cấu hình được chia thành các tệp riêng biệt để dễ quản lý, bao gồm main.conf cho các chỉ thị chính và các tệp cho bộ quy tắc ModSecurity. Các chỉ thị quan trọng như SecRuleEngine, SecRequestBodyAccess, và SecResponseBodyAccess được giải thích rõ ràng để kiểm soát cách ModSecurity xử lý và phân tích các yêu cầu và phản hồi. Việc thiết lập đúng các đường dẫn cho log và dữ liệu tạm thời cũng là một yếu tố quan trọng để đảm bảo hệ thống hoạt động ổn định và hiệu quả, giúp cho việc phân tích log server trở nên dễ dàng hơn khi có sự cố xảy ra.

3.1. Hướng dẫn các bước cài đặt ModSecurity từ mã nguồn

Quy trình cài đặt ModSecurity từ mã nguồn đảm bảo phiên bản được sử dụng là mới nhất. Trước tiên, cần cài đặt các gói phụ thuộc cần thiết trên hệ thống, ví dụ trên CentOS là: yum install httpd-devel pcre-devel libxml2-devel curl-devel. Sau đó, tải về phiên bản ModSecurity mới nhất từ trang chủ. Thực hiện giải nén gói tin và di chuyển vào thư mục mã nguồn. Các lệnh biên dịch tiêu chuẩn bao gồm ./configure, make, và make install. Sau khi cài đặt hoàn tất, cần kích hoạt module trong tệp cấu hình của Apache (httpd.conf) bằng cách thêm dòng LoadModule security2_module modules/mod_security2.so. Cuối cùng, khởi động lại dịch vụ Apache để áp dụng thay đổi. Việc kiểm tra tệp log lỗi của Apache sau khi khởi động lại là cần thiết để đảm bảo module đã được nạp thành công và không có xung đột nào xảy ra.

3.2. Tinh chỉnh cấu hình ModSecurity cơ bản và nâng cao

Việc cấu hình ModSecurity quyết định hiệu quả hoạt động của WAF. Tệp cấu hình chính (modsecurity.conf hoặc main.conf) chứa các chỉ thị quan trọng. SecRuleEngine On là chỉ thị bật cơ chế xử lý quy tắc. SecRequestBodyAccess On cho phép ModSecurity phân tích nội dung của các yêu cầu POST, điều này cực kỳ quan trọng để chống lại các cuộc tấn công gửi dữ liệu qua form. Tương tự, SecResponseBodyAccess On cho phép phân tích nội dung phản hồi từ server, giúp phát hiện rò rỉ thông tin nhạy cảm. Tuy nhiên, việc bật phân tích response body có thể ảnh hưởng đến hiệu năng, do đó cần cân nhắc kỹ lưỡng. Các chỉ thị khác như SecAuditLog và SecDebugLog được dùng để thiết lập vị trí lưu trữ và mức độ chi tiết của nhật ký, hỗ trợ đắc lực cho việc phát hiện xâm nhập và gỡ lỗi.

3.3. Tích hợp bộ quy tắc OWASP CRS để bảo vệ tức thì

Sau khi cài đặt và cấu hình cơ bản, bước quan trọng nhất là triển khai OWASP Core Rule Set (CRS). Đây là một bộ quy tắc ModSecurity được xây dựng sẵn để phòng chống tấn công web phổ biến. Quá trình triển khai bao gồm việc tải bộ quy tắc từ GitHub của SpiderLabs, sao chép các tệp quy tắc vào thư mục cấu hình của ModSecurity, và kích hoạt chúng bằng cách sử dụng chỉ thị Include trong tệp cấu hình của Apache. OWASP CRS được chia thành nhiều tệp, mỗi tệp nhắm vào một loại tấn công cụ thể (ví dụ: modsecurity_crs_41_sql_injection_attacks.conf). Việc này giúp quản lý và tùy chỉnh quy tắc dễ dàng hơn. Sau khi tích hợp, hệ thống ngay lập tức có khả năng chặn các yêu cầu độc hại, như được minh họa trong đồ án qua việc kiểm tra tấn công SQL injection trước và sau khi triển khai CRS.

IV. Phân Tích Quy Trình Xử Lý và Cấu Trúc Rule Của ModSecurity

Để sử dụng ModSecurity hiệu quả, việc hiểu rõ quy trình xử lý nội tại và cấu trúc của một quy tắc là điều kiện tiên quyết. ModSecurity phân tích mỗi giao dịch HTTP qua một quy trình 5 pha (phase) tuần tự. Mỗi pha tương ứng với một giai đoạn của giao dịch, từ khi nhận tiêu đề yêu cầu cho đến khi gửi nội dung phản hồi đi. Pha 1 xử lý tiêu đề yêu cầu (Request Headers), pha 2 xử lý nội dung yêu cầu (Request Body), pha 3 xử lý tiêu đề phản hồi (Response Headers), pha 4 xử lý nội dung phản hồi (Response Body), và pha 5 là giai đoạn ghi log (Logging). Cấu trúc này cho phép các quy tắc được áp dụng vào đúng thời điểm, tối ưu hóa hiệu quả phát hiện xâm nhập. Cốt lõi của hệ thống là bộ quy tắc ModSecurity. Mỗi quy tắc (rule) được định nghĩa bằng chỉ thị SecRule và có cấu trúc gồm ba phần chính: VARIABLES, OPERATOR, và ACTIONS. VARIABLES chỉ định phần nào của giao dịch HTTP sẽ được kiểm tra (ví dụ: ARGS cho các tham số, REQUEST_COOKIES cho cookie). OPERATOR xác định cách thức so khớp mẫu (ví dụ: @rx cho biểu thức chính quy). ACTIONS quy định hành động sẽ thực hiện nếu có sự trùng khớp (ví dụ: deny để chặn, log để ghi nhật ký). Việc nắm vững cú pháp này là chìa khóa để tùy chỉnh và xây dựng các quy tắc bảo mật riêng cho ứng dụng web của mình.

4.1. Khám phá 5 pha xử lý giao dịch HTTP của ModSecurity

Quy trình xử lý 5 pha của ModSecurity đảm bảo việc phân tích toàn diện. Pha 1 (Request Headers): Xảy ra ngay sau khi Apache hoặc Nginx nhận được tiêu đề HTTP. Đây là nơi lý tưởng để chặn các cuộc tấn công dựa trên URL hoặc phương thức HTTP. Pha 2 (Request Body): Xử lý nội dung của yêu cầu, chẳng hạn như dữ liệu gửi qua form POST. Pha này rất quan trọng để phát hiện tấn công SQL Injection và XSS được chèn vào các tham số. Pha 3 (Response Headers): Kiểm tra tiêu đề phản hồi trước khi nội dung được gửi đi, hữu ích trong việc phát hiện các vấn đề như HTTP Response Splitting. Pha 4 (Response Body): Phân tích nội dung HTML trả về cho người dùng. Pha này có thể phát hiện rò rỉ thông tin nhạy cảm hoặc các thông báo lỗi chi tiết. Pha 5 (Logging): Là pha cuối cùng, quyết định thông tin nào sẽ được ghi vào audit log, rất cần thiết cho việc phân tích log server.

4.2. Cấu trúc một quy tắc Rule Biến Toán tử và Hành động

Một quy tắc trong ModSecurity được định nghĩa bởi chỉ thị SecRule. Cấu trúc của nó rất logic. VARIABLES là phần đầu tiên, xác định dữ liệu cần kiểm tra, ví dụ REQUEST_URI để kiểm tra URL, hoặc ARGS:username để kiểm tra tham số có tên là 'username'. ModSecurity hỗ trợ hàng chục biến khác nhau. OPERATOR là phần thứ hai, chỉ định cách so khớp. Toán tử @rx (regular expression) là phổ biến nhất, nhưng cũng có các toán tử khác như @contains (chứa chuỗi) hay @eq (bằng) để tối ưu hiệu năng. ACTIONS là phần cuối cùng, định nghĩa những gì sẽ xảy ra khi quy tắc khớp. Hành động có thể là deny (từ chối yêu cầu), log (ghi lại sự kiện), pass (cho qua nhưng vẫn tiếp tục xử lý các quy tắc sau), hoặc redirect (chuyển hướng). Một quy tắc có thể có nhiều hành động, được phân tách bằng dấu phẩy.

V. Ứng Dụng Thực Tiễn Phân Tích Rule Chống Lại Tấn Công Web

Lý thuyết sẽ trở nên vô nghĩa nếu không có ứng dụng thực tiễn. Phần này của đồ án tập trung phân tích các rule ứng dụng thực tế, minh họa cách ModSecurity và OWASP CRS hoạt động để ngăn chặn các cuộc tấn công cụ thể. Các trường hợp được phân tích sâu, từ việc chống lại các kỹ thuật tinh vi như HTTP Response Splitting đến các mối đe dọa quen thuộc như Path Traversal. Ví dụ, để chống lại HTTP Response Splitting, các quy tắc được thiết kế để tìm kiếm các ký tự xuống dòng (%0a, %0d) trong các tham số đầu vào, vốn là dấu hiệu của việc cố gắng chèn thêm tiêu đề HTTP giả mạo. Đối với Path Traversal, các quy tắc sẽ tìm kiếm các chuỗi như ../ hoặc ..\ trong URL và các tham số, đây là kỹ thuật phổ biến để truy cập các tệp tin ngoài thư mục web gốc. Một ví dụ điển hình khác là việc phát hiện các Session cookie không hợp lệ để chống lại Session Fixation. Bằng cách theo dõi và xác thực các cookie được tạo ra, bộ quy tắc ModSecurity có thể xác định khi nào một cookie giả mạo được gửi lên, từ đó ngăn chặn việc chiếm quyền phiên làm việc. Những phân tích này cho thấy tính linh hoạt và sức mạnh của ngôn ngữ quy tắc, biến ModSecurity thành một hệ thống phát hiện và ngăn chặn xâm nhập (IDPS) hiệu quả.

5.1. Case study Phòng chống tấn công HTTP Response Splitting

Tấn công HTTP Response Splitting là một kỹ thuật khai thác bằng cách chèn các ký tự CR (Carriage Return) và LF (Line Feed) vào dữ liệu đầu vào, khiến server trả về hai phản hồi HTTP riêng biệt thay vì một. Điều này có thể dẫn đến XSS, cache poisoning, hoặc chiếm quyền người dùng. Bộ quy tắc ModSecurity trong OWASP CRS (ví dụ, rule id '950910', '950911') được thiết kế để giải quyết vấn đề này. Các quy tắc này sử dụng toán tử @rx để quét tất cả các biến đầu vào (ARGS, REQUEST_COOKIES,...) nhằm tìm kiếm sự kết hợp giữa ký tự xuống dòng ([\n\r]) và các từ khóa của tiêu đề HTTP như content-type, set-cookie, hoặc location. Khi phát hiện một mẫu trùng khớp, hành động block sẽ được kích hoạt, ngay lập tức chặn yêu cầu độc hại và ghi lại sự kiện để phân tích log server.

5.2. Case study Ngăn chặn khai thác lỗ hổng Path Traversal

Lỗ hổng Path Traversal cho phép kẻ tấn công đọc các tệp tin nhạy cảm trên máy chủ. Kỹ thuật tấn công thường bao gồm việc chèn chuỗi ../ vào các tham số để điều hướng hệ thống tệp. Các quy tắc trong OWASP CRS nhắm vào việc phòng chống tấn công web này bằng cách tìm kiếm các mẫu đặc trưng của Path Traversal. Các quy tắc sẽ kiểm tra các biến như REQUEST_URI và ARGS để phát hiện sự hiện diện của các chuỗi như ../, ..\, và các biến thể mã hóa của chúng (%2e%2e%2f). Ngoài ra, các quy tắc còn có thể tìm kiếm các tên tệp hệ thống phổ biến như /etc/passwd. Khi một yêu cầu chứa các mẫu này, ModSecurity sẽ từ chối và cảnh báo về một nỗ lực truy cập trái phép, bảo vệ tính toàn vẹn và bảo mật của dữ liệu trên server.

5.3. Case study Phát hiện Session Cookie không hợp lệ Session Fixation

Session Fixation là một cuộc tấn công mà kẻ tấn công ấn định một Session ID cụ thể cho người dùng, sau đó chờ người dùng đăng nhập và chiếm quyền phiên đó. Để chống lại điều này, ModSecurity có thể được cấu hình để theo dõi và xác thực các phiên làm việc. Quy tắc '981062' trong OWASP CRS là một ví dụ điển hình. Khi server tạo một cookie phiên mới (ví dụ PHPSESSID), quy tắc này sẽ ghi lại các thông tin liên quan như địa chỉ IP, User-Agent của người dùng và lưu trữ chúng trong một bộ sưu tập (collection) của ModSecurity. Sau đó, quy tắc '981054' sẽ kiểm tra mỗi yêu cầu đến. Nếu Session ID được gửi từ client không khớp với các thông tin đã lưu, hoặc nếu nó hoàn toàn không tồn tại trong bộ sưu tập, ModSecurity sẽ coi đó là một cookie không hợp lệ và chặn yêu cầu, ngăn chặn hiệu quả các nỗ lực chiếm quyền phiên.

Trích đoạn nội dung tài liệu

DRAFT1 [e-mail] MỤC LỤC I. PHIẾU GIAO ĐỀTÀI. GIỚI THIỆU MOD_SECURITY. 8 CẤU TRÚC RULE TRONG ModSecurity.8 QUY TRÌNH XỬ LÝ TRONG ModSecurity.10 KHUYẾN CÁO KHI TRIỂN KHAI THỰC TẾ.

TỐNG QUAN VỀ TIÊU CHUẨN OWASP TOP TEN. CÀI ĐẶT MODSECURITY. 15 Cấu hình thư mục.15 Các tập tin cấu hình. 15 Các chỉ thị trong tập tin cấu hình.16 Quản lý Request Body.

17 Quản lý Response Body.19 Default Rule Match Policy. OWASP MODSECURITY CORE RULE SET. 20 Triển khai OWASP ModSecurity CRS.21 Kiểm tra kết quả. TỔNG QUAN VỀ RULE.29 String–matching operators.

RULE LANGUAGE TUTORIAL. 33 Hướng dẫn sử dụng biến (variable). 33 Hướng dẫn sử dụng liên kết rule (chain). 34 Hướng dẫn sử dụng toán tử phủ định.

35 3 Hướng dẫn về action. 36 Using Transformation Functions.37 Changing Rule Flow. PHÂN TÍCH CÁC RULE ỨNG DỤNG THỰC TẾ.40 Trường hợp 1: Chống tấn công Replay attack thông qua cơ chế đánh token ngẫu nhiên.40 Trường hợp 2: Phát hiện các Session cookie không hợp lệ.43 Trường hợp 3: Phòng chống phương pháp khai thác HTTP Reponse Spliting.48 Trường hợp 4: Phòng chống phương pháp khai thác Path-Traversal.50 Trường hợp 5: Phát hiện nguy cơ lộ thông tin thẻ tín dụng.52 Trường hợp 6: Phát hiện hành vi đăng nhập bruteforce.61 DANH MỤC LỖ HỔNG BẢO MẬT OWASP 2010.61 DANH MỤC CÔNG CỤ HỖ TRỢ KIỂM TRA BẢO MẬT ỨNG DỤNG WEB.64 DANH MỤC THAM KHẢO KHAI THÁC LỖ HỔNG BẢO MẬT ỨNG DỤNG WEB. TÀI LIỆU THAM KHẢO.

PHIẾU GIAO ĐỀTÀI Tên đề án: Nghiên cứu ứng dụng Mod Security để bảo vệ web server Người hướng dẫn: Lưu Thanh Trà Thời gian thực hiện: 14 tuần Số lượng SV 2 I. Mục đích Các firewall truyền thống không đủ mạnh để để bảo vệ các web server. ModSecurity cho phép bảo vệ web server (một/nhiều) thông qua cơ chế can thiệp trực tiếp ở mức độ ứng dụng. Đồ án này nhằm nghiên cứu và ứng dụng ModSecurity để bảo vệ hệ thống web bất kỳ.

Yêu cầu đối với sinh viên thực hiện  Sinh viên có kiến thức cơ bản về Linux, web  Sinh viên có kiến thức về security, html, lập trình web III. yêu cầu  Sinh viên nắm rõ hoạt động của hệ điều hành Linux  Sinh viên nắm rõ web, html, http, PhP. Sản phẩm  Hệ thống Mod Security triển khai hoàn chỉnh để bảo vệ hệ thống web V. Tài liệu tham khảo Các giáo trình do giảng viên đề nghị, Internet Ngày 28 tháng 02 năm 2013 Ký tên TS.

Lưu Thanh Trà 5 II. NHẬP ĐỀ Ngày nay, ứng dụng web trong doanh nghiệp và cơ quan chính phủ phải đối mặt với hai thách thức lớn là: giảm thiểu nguy cơ bảo mật và bảo đảm quy trình trong công nghiệp và/hoặc những quy định chính phủ. May mắn thay khi tồn tại một giải pháp an toàn thông tin sẵn sàng hỗ trợ các tổ chức CNTT đạt được cả hai tiêu chí trên tại cùng một thời điểm. OWASP cho phép các chuyên gia an ninh CNTT giảm thiểu được các cuộc tấn công bằng các chủ động và liên tục củng cố các cấu hình cấu hình an ninh của OS, ứng dụng web và Web Application Firewall.

Đồng thời, các dự án thuộc chuẩn OWASP cho phép các kiểm soát viên giám sát việc tuân thủ các chính sách bắt buộc trong tổ chức, doanh nghiệp. ModSecurity là một sản phẩm thuộc dự án OWASP, cho phép người dùng cấu hình, tùy chỉnh các phương thức phát hiện tấn công vào web server. Phiên bản ModSecurity hiện tại đã hỗ trợ Apache, Nginx và IIS. Cùng với dự án ModSecurity Core Rule Set thì việc triển khai hệ thống WAF càng dễ dàng hơn cho nhân viên hệ thống cũng như các chuyên viên bảo mật.

GIỚI THIỆU MOD_SECURITY Mod_Security là một module mở rộng cho các chương trình web server như Apache, Nginx, IIS và hoạt động như một firewall tại lớp ứng dụng web. Cùng với sự gia tăng về phương pháp tấn công web thì mod_security cũng đã cập nhật những rule và đưa ra nhiều cách phòng chống trong mã nguồn của chương trình. Một số tính chất mà mod_security có thể dùng làm Web Application Firewall: Tính linh động (Flexibility) Việc phân tích luồng HTTP theo một tiêu chí nhất định trong thực tế thường gặp vấn đề là làm sao để có thể so trùng mẫu mà bạn muốn. Ngoài ra, do nhu cầu của từng hệ thống web là khác nhau dẫn đến việc phân tích trên từng loại ứng dụng cũng khác nhau.

Mod_security đã kết hợp với OWASP phát triển các tập rule mẫu (Core Rule Set) nhằm tạo ra tính linh động cho từng mô hình web khác nhau, hỗ trợ người quản trị phân tích theo nhu cầu thực tế của hệ thống đang quản trị. Tính thụ động (Passivity) ModSecurity sẽ không thực thi các tác vụ nếu như người quản trị viên không chỉ định công việc cụ thể cho chương trình, việc này là khá quan trọng trong một ứng dụng có nhiệm vụ phân tích nguy cơ như ModSecurity. Mọi cảnh báo sẽ được thực hiện 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. CHỨC NĂNG 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: Parsing ModSecurity sẽ phân tách các dữ liệu luân chuyển qua hệ thống thành cấu trúc dữ liệu mà ModSecurity định nghĩa sẵn.

Cấu trúc này sẽ được chuyển qua cơ chế so trùng mẫu trong tập rule để phân tích nguy cơ. Buffering Chức năng buffer (đệm) đóng vai trò khá quan trọng trong cơ chế hoạt động của ModSec. Việc này có ý nghĩa khi các request gởi đến ứng dụng web thì phải thông qua ModSecurity trước khi đến ứng dụng xử lý và những response cũng sẽ được phân tích trước khi trả về phía client. Cơ chế này là cách duy nhất để có thể ngăn chặn các cuộc tấn công thời gian thực, các dữ liệu mà ModSecurity nhận được và phân tích sẽ được lưu trữ trong RAM (bao gồm request body và response data) Logging ModSecurity hỗ trợ ghi nhật ký các gói tin HTTP: request headers, request body, response header, response body nhằm hỗ trợ người quản trị phân tích nguy cơ mà hệ thống đang gặp phải để có thể ra quyết định kiểm soát.

7 Rule Engine Các tập mẫu trong ModSecurity đóng vai trò quan trọng trong việc phát hiện các dạng tấn công và thực hiện phòng chống. ModSecurity cùng phát triển với dự án OWASP phát triển các mẫu để phân tích và phòng chống các tấn công hệ thống web (Tham khảo https://www.php/Category:OWASP_ModSecurity_Core_Rule_Set_Project) Các phân nhóm mà CRS hỗ trợ:  HTTP Protection  Real-time Blacklist Lookups  Web-based Malware Detection  HTTP Denial of Service Protections  Common Web Attacks Protection  Automation Detection  Integration with AV Scanning for File Uploads  Tracking Sensitive Data  Trojan Protection  Identification of Application Defects  Error Detection and Hiding CẤU TRÚC RULE TRONG ModSecurity Tất cả các hoạt động trong ModSecurity hầu hết sẽ liên quan đến hai phần chính là: cấu hình (configuration) và các tập luật (rule). Phần cấu hình chỉ định cách thức xử lý dữ liệu, trong khi các rule sẽ quyết định thực hiện các hành vi (action) với dữ liệu đã được xử lý. Một ví dụ về rule: SecRule ARGS "<script>" 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 VARIABLES: xác định vị trí dữ liệu mà ModSecurity sẽ tìm kiếm mẫu.

Trong ví dụ trên, tham số ARGS nhằm chỉ định tìm kiếm mẫu trong tất cả các tham số trong request. OPERATOR: chỉ định cách mà ModSecurity sẽ tìm kiếm mẫu. Các operator được dùng theo dạng Regular expression nhằm tạo nên cơ chế phân tích linh động cho các rule. ACTIONS: chỉ định hành động mà ModSecurity sẽ thực hiện khi có một mẫu được so trùng.

Trong ví dụ trên, phần action được viết log,deny,status:404 có nghĩa là: khi trùng mẫu <script> trong gói tin thì thực hiện ghi log, deny gói tin bằng cách sử dụng mã trạng thái 404 (Not found). QUY TRÌNH XỬ LÝ TRONG ModSecurity Trong ModSecurity mỗi phiên phân tích sẽ thực hiện lần lượt qua 5 bước (pha), tại mỗi bước ModSecurity sẽ thực thi các rule tương ứng nhằm phát hiện và phòng chống các khai thác. 8 Hình 1: Quy trình xử lý của ModSecurity (nguồn www.org) Request Header (1) Đây là bước đầu tiên trong quá trình thực hiện phân tích gói tin. Mục đích của bước này nhằm cho phép người viết rule tương tác với các request trước khi thực hiện các yêu cầu trong phần HTTP body.

Phần này khá quan trọng để phân tích các khai thác dựa vào HTTP method cũng như dựa vào URL như SQL Injection, Reflect XSS, Local file include … Request body (2) Bước 2 là quá trình kiểm tra chính trong quá trình client gởi request đến server, phần này sẽ có hiệu quả khi người dùng cố sử dụng phương thức POST hoặc PUT để upload tập tin lên phía server. Việc kiểm tra này bảo đảm dữ liệu đưa lên server là an toàn, tránh tình trạng upload mã độc hoặc các dạng tấn công nhưng Stored XSS, Ajax Injection … Response headers (3) Những request đã được xử lý tại server sẽ được trả về cho ModSecurity kiểm tra trạng thái trong phần respone header. Trước khi phần respone body được đọc thì ModSecurity sẽ dựa vào tập rule để xác định 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ề.

9 Response body (4) Sau khi ModSecurity đã hoàn thành việc kiểm tra tại respone header thì nội dung trong phần body sẽ được kiểm tra so trùng với mẫu trong tập lệnh. Việc này là khá hiệu quả để phát hiện và phòng chống xâm nhập trong trường hợp bước 1 và 2 không phát hiện được tấn công. Ví dụ: trong khai thác SQL injection, nếu hacker cố gắng sử dụng một số công nghệ evasion thì việc phát hiện khi request là 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ề để phát hiện nếu như câu truy vấn thành công.

Logging (5) 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. KHUYẾN CÁO KHI TRIỂN KHAI THỰC TẾ Nhằm bảo đảm tính tính linh động trong việc phát hiện cũng như bảo vệ theo thời gian thực, ModSecurity cần sử dụng một lượng tài nguyên CPU và RAM để bảo đảm hoạt động đúng mục đích khi triển khai. Việc sử dụng tài nguyên phụ thuộc nhiều vào phần cấu hình và cách triển khai trên từng hệ thống khác nhau. Dưới dây là một số điểm chính cần chú ý: ModSecurity sẽ phân tích các cú pháp mà apache sẽ thực hiện, vì thế hệ thống của bạn sẽ có thể tăng tiêu thụ tài nguyên CPU để thực hiện tác vụ.

Việc phân tích linh động trong một số trường hợp sẽ cần một lượng tài nguyên khá lớn để phân tích.