nghiên cứu và ứng dụng modsecurity để bảo vệ hệ thống web bất kỳ

nghiên cứu và ứng dụng modsecurity để bảo vệ hệ thống web bất kỳ

MỤC LỤC

I PHIẾU GIAO ĐỀTÀI 5

II NHẬP ĐỀ 6

IV GIỚI THIỆU MOD_SECURITY 7

CHỨC NĂNG 7

Parsing 7

Buffering 7

Logging 7

Rule Engine 8

CẤU TRÚC RULE TRONG ModSecurity 8

QUY TRÌNH XỬ LÝ TRONG ModSecurity 8

Request Header (1) 9

Request body (2) 9

Response headers (3) 9

Response body (4) 10

Logging (5) 10

KHUYẾN CÁO KHI TRIỂN KHAI THỰC TẾ 10

V TỐNG QUAN VỀ TIÊU CHUẨN OWASP TOP TEN 11

VI CÀI ĐẶT MODSECURITY 12

VII CẤU HÌNH 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 18

Filesystem Locations 18

File Uploads 19

Debug Log 19

Audit Log 19

Default Rule Match Policy 20

Verifying Installation 20

VIII OWASP MODSECURITY CORE RULE SET 20

Giới thiệu 20

Triển khai OWASP ModSecurity CRS 21

Kiểm tra kết quả 22

IX TỔNG QUAN VỀ RULE 23

Giới thiệu 23

Variables 24

Request variables 25

Server variables 26

Response variables 26

Miscellaneouse variables 27

Parsing flags 27

Collections variables 28

Time variables 28

Operators 29

String–matching operators 29

Numerical operators 30

Validation operators 30

Miscellaneous operators 30

Actions 31

Disruptive actions 31

Flow actions 31

Metadata actions 32

Variable actions 32

Logging actions 32

Special actions 33

Miscellaneous Actions 33

X RULE LANGUAGE TUTORIAL 33

Tổng quan 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 34

Variable Counting 35

Hướng dẫn về action 35

Action Defaults 35

Unconditional Rules 36

Using Transformation Functions 36

Blocking 37

Changing Rule Flow 37

Capturing Data 38

Variable Manipulation 39

Metadata 39

XI 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 54

XII PHỤ LỤC 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 67

XIII TÀI LIỆU THAM KHẢO 91

I 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

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ỳ

II II 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

IV 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à

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ệctuâ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.III.

IV 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ếthợ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

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

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.owasp.org/index.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 theodạ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ướcModSecurity 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

Hình 1: Quy trình xử lý của ModSecurity (nguồn www.Modsecurity.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íaserver 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àotậ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óitin trả về

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 Ví dụ: XML, JSON, AJAX …

Việc quản lý dữ liệu upload từ phía client yêu cầu thêm tài nguyên I/O (như HDD), trong một số trường hợp sẽ gây ra tình trạng trùng lặp dữ liệu trên hệ thống

Dữ liệu trong request và resopone được lưu trữ đệm trong RAM để thực hiện các tác vụ chặntheo thời gian thực

Mỗi rule trong phần cấu hình sẽ sử dụng CPU (cho phần operartor) và RAM (dùng để

chuyển đổi dữ liệu đầu vào trước khi qua phiên phân tích)

Việc sử dụng các Regular expression sẽ tốn các tài nguyên nhiều hơn

Các hoạt động I/O sẽ tăng cao cho việc ghi nhật ký trong quá trình hoạt động của

ModSecurity (full transaction loging)

Khi triển khai thực tế ModSecurity, bạn cần chú ý đến những điều trên để có thể xác định được tài nguyên cần thiết để ModSecurity hoạt động ổn định Trong trường hợp bạn không thể thay đổi tài nguyên phần cứng, thì tôi khuyên bạn nên thường xuyên theo dõi trạng thái hoạt động của hệ thống, rút ra những kinh nghiệm nhằm điều chỉnh hoặc giảm bớt chức năng, ruleset phù hợp mà vẫn đảm bảo an toàn cho việc hoạt động Nếu như tổ chức mà bạn đang quản lý sử dụng một số công nghệ ảo hóa thì việc điều chỉnh tài nguyên sẽ thuận tiện hơn để ModSecurity hoạt động

Một cách khác để triển khai ModSecurity trên thực thế là dùng như một reverse proxy, trongtrường hợp này tài nguyên cho ModSecurity sẽ ổn định hơn so với hệ thống tích hợp (CPU, RAM, I/O hoạt động ở trạng thái cao)

V TỐNG QUAN VỀ TIÊU CHUẨN OWASP TOP TEN

OWASP (Open Web Application Security Project) là một dự án phi lợi nhuận, tập trung vào việc cải thiện tính bảo mật của ứng dụng web Thành viên của dự án là các cá nhân, tổ chức, chuyên gia … cùng đóng góp các mã nguồn, công cụ hỗ trợ kiểm tra lỗ hổng ứng dụng web.Năm 2010, cộng đồng OWASP xuất bản “Tài liệu hướng dẫn kiểm tra ứng dụng Web” phiênbản 3 (OWASP Testing Guide v3:

https://www.owasp.org/index.php/OWASP_Testing_Project) Tài liệu liệt kê và phân nhóm các

lỗ hổng bảo mật đã được biết đến trong ứng dụng web Đồng thời nội dung của tài liệu này mô

tả các dự án được cộng đồng phát triển, bao gồm dự án WAF ModSecurity

OWASP phân loại các lỗ hổng thành 10 phân nhóm chính:

A1-Injection Nhóm này bao gồm các lỗ hổng như SQL injection, OS command

injection, LDAP injection…các lỗ hổng trong phân nhóm này cho phép hacker truy cập hoặc chèn các dữ liệu giả vào hệ thống thông qua các câu truy vấn dữ liệu

A2-Cross Site

Scripting (XSS)

XSS xuất hiện khi một ứng dụng web cho phép người dùng nhập các dữ liệu vào mà không thông qua kiểm duyệt nội dung, những dữ liệu này sẽ tương tác trực tiếp với những người dùng khác cùng sử dụng website Nguy cơ tạo ra là hacker có thể chèn các mã kịch bản như HTML, Javascript… nhằm ăn cắp SessionCookie, thay đổi giao diện (deface) hoặc chuyển hướng đến trang có mã độc khác

A3-Broken

Authentication and

Session Management

Phân nhóm này liệt kê các nguy cơ về chức năng xác thực và quản

lý phiên (session management) trong ứng dụng web Thông thường các chức năng này không được triển khai tốt, cho phép hacker vượt qua cơ chế kiểm duyệt người dùng

A4-Insecure Direct

Object References

Nguy cơ trong nhóm A4 thường được gặp trong trường hợp các lập trình viên sử dụng tham chiếu đến một tập tin, thư mục hoặc các truy vấn database trong mã nguồn Nếu các tham chiếu này không được quản lý chặt chẽ, thì việc truy cập dữ liệu trái phép từ bên ngoài

A6-Security

Misconfiguration hình và triển khai hệ thống, ứng dụng webserver (Apache, Nginx, Các yêu cầu về bảo mật ứng dụng web cũng bao gồm việc cấu

Tenginx…), cơ sở dữ liệu (MySQL, Oracle…), hệ điều hành (Linux, Windows…) Tất cả công việc thiết lập môi trường cho ứng dụng web hoạt động cần được lên kế hoạch theo dõi, kiểm tra, cập nhật thường xuyên nhằm giảm thiểu nguy cơ hệ thống bị khai thác

A7-Insecure

Cryptographic Storage

Rất nhiều ứng dụng web không quan tâm đến việc bảo vệ dữ liệu nhạy cảm như thông tin thẻ tín dụng, SSN và các thông tin xác thực Việc hacker thu thập các dữ liệu nhạy cảm không được mã hóa

(encrypt) hoặc băm (hash) sẽ tạo ra mối nguy hiểm lớn cho những website cho phép giao dịch thông qua thương mại điện tử.

A8-Failure to

Restrict URL Access

Hầu hết các ứng dụng thường thực hiện kiểm soát việc truy cập thông qua URL (thông qua cơ chế Rewrite) Việc giới hạn quyền truycập vào các tập tin, thư mục nhạy cảm là cần thiết Trong một số tìnhhuống, việc kiểm soát này không được quản lý đầu đủ tạo nguy cơ xâm nhập trái phép vào ứng dụng (ví dụ: thư viện fckditor thường có thể truy cập trực tiếp không cần xác thực)

A10-Unvalidated

Redirects and Forwards

Các ứng dụng web thường chuyển hướng người dùng đến những trang web hoặc URL khác nhau Hacker có thể lợi dụng cơ chế này

để chuyển hướng người dùng đến những website chứa phần mềm độchại hoặc trang đăng nhập giả

Dự án OWASP ModSecurity Core Rule Set (CRS) sử dụng bản quyền ASLv2 Các tập rule trong CRS được phân loại theo tiêu chuẩn OWASP để có thể bảo vệ máy chủ web theo từng loại tấn công Các rule này hoạt động tốt với phiên bản ModSecurity 2.5 trở lên

Các vấn đề về triển khai ModSecurity CRS và phương pháp kiểm tra lỗ hổng sau khi triển khai, bạn có thể tham khảo tại mục OWASP MODSECURITY CORE RULE SET và PHỤ LỤC

VI CÀI ĐẶT MODSECURITY

Trước khi bạn tiến hành cài đặt ModSecurity cho hệ thống, bạn cần biết những phương thức cài đặt cũng như một số ưu điểm và khuyết điểm cho từng loại:

Dựa vào phiên bản của

hệ điều hành  Tự động cài đặtDễ dàng bảo trì cũ Có thể là phiên bản

Gói cài đặt của bên thứ

bản mới nhất

 Có thể sử dụng phiênbản thử nghiệm

 Có thể tùy biến, sử dụng các bản vá khẩn cấp

 Có thể gặp các vấn

đề khi quản trị viên muốn

sử dụng lại phiên bản cũ trước đó

trong tình huống phát hiệnlỗi bảo mật

Trong phần này, tôi sẽ hướng dẫn biên dịch từ mã nguồn ModSecurity được tải tại trang web www.Modsecurity.org

Trước khi cài đặt ModSecurity trên nền tảng Linux, bạn cần cài đặt một số thư viện hỗ trợ như sau: Apache Portable Runtime (APR), APR-util, bật module mod_unique_id trong Apache, libcurl, libxml2, Lua 5.1 (tùy chọn), PCRE

# yum install openssl openssl-devel pcre pcre-devel libxml2 libxml2-devel curl-devel pcre pcre-devel

Tải phiên bản ModSecurity mới nhất tại trang chính của sản phẩm

Bỏ comment cho unique_id_module

LoadModule unique_id_module modules/mod_unique_id.so

Thêm dòng

LoadModule security2_module modules/mod_security2.so

Sau khi chỉnh tập tin httpd.conf, ta save lại và tiến hành kiểm tra tập tin cấu hình, bảo đảm Apache hoạt động bình thường

Hình 3: Log thông báo trạng thái khởi động của Apache

Apache đã hoạt động bình thường với mod_security

Configuration files: /opt/modsecurity /etc

Audit logs: /opt/modsecurity /var/audit

Persistent data: /opt/modsecurity/var/data

Logs: /opt/modsecurity/var/log

Temporary files: /opt/modsecurity/var/tmp

File uploads: /opt/modsecurity/var/upload

rwxr-x -/opt/modsecurity/var/

rwx -/opt/modsecurity/var/

rules-first.conf Tập lệnh thực hiện đầu tiên

Thực hiện tạo tập tin Modsecurity.conf trong thư mục /etc/httpd/conf.d với nội dung:

SecRequestBodyAccess Controls request body buffering

SecRequestBodyInMemoryLimit Sets the size of the per-request memory bufferSecRequestBodyLimit Sets the maximum request body size

ModSecurity will acceptSecRequestBodyLimitAction Controls what happens once the request body

limit is reachedSecRequestBodyNoFilesLimit Sets the maximum request body size,

excluding uploaded filesSecResponseBodyAccess Controls response body buffering

SecResponseBodyLimit Specifies the response body buffering limit

SecResponseBodyLimitAction Controls what happens once the response body

limit is reachedSecResponseBodyMimeType Specifies a list of response body MIME types

to inspectSecResponseBodyMimeTypesClear Clears the list of response body MIME typesSecRuleEngine Controls the operation of the rule engine

Quản lý Request Body

Request bao gồm hai thành phần: request header mặc định luôn được bật trong ModSecurity

và request body là tùy chọn để theo dõi Trong trường hợp quản trị viên cần theo dõi nội dung request body thì cầu cấu hình như sau:

# Allow ModSecurity to access request bodies If you don't, ModSecurity

# won't be able to see any POST parameters, which opens a large security

# hole for attackers to exploit

#

SecRequestBodyAccess On

Khi chức năng quản lý request body được sử dụng, thì ModSecurity không những sẽ theo dõi nội dung gói tin mà còn sẽ lưu trữ nội dung trong bộ đệm (buffer) để phân tích trong trườnghợp dữ liệu gởi đến server cần nhiều hơn một gói tin HTTP Nhằm tránh tình trạng gây quá tải cho bộ nhớ RAM, quản trị viên cần điều chỉnh tham số giới hạn phù hợp Có ba phần cấu hình chỉ định hoạt động của buffer Hai chỉ thị đầu tiên dùng để giới hạn của các request:

# Maximum request body size we will accept for buffering If you support

# file uploads then the value given on the first line has to be as large

# as the largest file you are willing to accept The second value refers

# to the size of data, with files excluded You want to keep that value as

Chỉ thị thứ ba trong phần này là SecRequestBodyInMemoryLimit, dùng điều khiển hoạt động lưu trữ nội dung của gói tin vào bộ nhớ RAM Tham số trong phần này chỉ có hiệu quả với các gói tin có nhiệm vụ upload tập tin (multipart/form-data)

# Store up to 128 KB of request body data in memory When the multipart

# parser reachers this limit, it will start using your hard disk for

# storage That is slow, but unavoidable

#

SecRequestBodyInMemoryLimit 131072

Những gói tin có kích thước trong khoảng giới hạn tại mục SecRequestBodyInMemoryLimit

sẽ được lưu trữ trong RAM Những gói tin có kích thước lớn hơn sẽ được chuyển vào vùng nhớswap trên ổ cứng để lưu trữ và phân tích

Quản lý Response Body

Tương tự như gói tin request, các gói tin respone cũng bao gồm hai phần là header và body (trong một số trường hợp gói tin respone không tồn tại nội dung trong phần body) Ta cấu hình việc theo dõi nội dung trong repone tại mục SecResponseBodyAccess

# Allow ModSecurity to access response bodies

# You should have this directive enabled in order to identify errors

# and data leakage issues

#

# Do keep in mind that enabling this directive does increases both

# memory consumption and response latency

Trong dữ liệu mà phía server trả về phía client thường bao gồm nhiều thành phần và kiểu khác nhau như: html, css, js, jpg, xml … Trong hầu hết các trường hợp, thì các dữ liệu tĩnh (javascript, css …) không tạo ra nguy cơ bảo mật nào cho hệ thống, do vậy trong ModSecurity

ta cần chỉ định rõ kiểu dữ liệu cần theo dõi trong phần SecResponseBodyMimeType

# Which response MIME types do you want to inspect? You should adjust the

# configuration below to catch documents but avoid static files

# (e.g., images and archives)

# Filesystem configuration

-# The location where ModSecurity stores temporary files (for example, when

# it needs to handle a file upload that is larger than the configured limit)

#

# This default setting is chosen due to all systems have /tmp available however,

# this is less than ideal It is recommended that you specify a location that's private

#

SecTmpDir /tmp/

# The location where ModSecurity will keep its persistent data This default setting

# is chosen due to all systems have /tmp available however, it

# too should be updated to a place that other users can't access

Khuyến cáo: việc sử dụng chức năng theo dõi tập tin upload có thể là nguyên nhân của việc làm tăng dung lượng lưu trữ do có nhiều tập tin trùng lặp nội dung, đồng thời việc này sẽ làm giảm hiệu suất của ModSecurity Vì lý do này, bạn chỉ nên sử dụng chức năng này khi thật sự cần thiết

# The location where ModSecurity will store intercepted

# uploaded files This location must be private to ModSecurity

# Thực hiện ghi log cho các yêu cầu có mã lỗi từ 500-599 (lỗi từ phía server)

Default Rule Match Policy

Phần cấu hình rule mặc định cho ModSecurity là khá quan trọng, vì phần này sẽ quyết định

hệ thống mà bạn sẽ theo dõi có bị bỏ sót các tấn công trong trường hợp các tập rule không thể phát hiện được Tuy nhiên, ModSecurity khuyến cáo bạn nên cấu hình không nên chặn tất cả các kết nối khi ModSecurity hoạt động

SecRule REQUEST_URI " dangerous" " id:'900721'phase:1,deny,status:406"

Rule trên hoạt động trong trường hợp khi một người dùng cố truy cập vào URI có chứa mẫu

dangerous, thì Modsecurity sẽ trả về mã lỗi 406.

[root@mod_security ~]# curl -I http://www.ModSecurity.com/dangerous

HTTP/1.1 406 Not Acceptable

Date: Thu, 30 May 2013 22:56:06 GMT

Server: Apache

Connection: close

Content-Type: text/html; charset=iso-8859-1

VIII OWASP MODSECURITY CORE RULE SET

Giới thiệu

ModSecurity sau khi đã được cài đặt thành công cần được cấu hình các tập rule để có thể hoạt động như một WAF Tuy nhiên, việc tự viết và triển khai các rule là khá phức tạp và tốn thời gian để tối ưu các chức năng trong rule

Nhóm nghiên cứu Truswave SpiderLabs đã phát triển một nhóm các tập lệnh có tên là OWASP ModSecurity CRS, bao gồm các nội dung gói tin của kiểu tấn công đã được biết đến Một tính năng mạnh mẽ của CRS là có thể bảo vệ những ứng dụng web phổ biến cũng như những ứng dụng web tự phát triển riêng biệt

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ứ 3.

• 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

• Common Web Attacks Protection: phát hiện một số dạng tấn công phổ biếtn

vào ứng dụng web Automation Detection: phát hiện các bots, crawler, chương trình quét(scanner) và các hoạt động thu thập thông tin

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

Triển khai OWASP ModSecurity CRS

Tiến hành tải gói tin SpiderLabs-owasp-modsecurity-crs phiên bản mới nhất tại:

#STOP COMMON CONFIGURATION

#START OWASP MODSECURITY CORE RULE SET

Kiểm tra kết quả

Ta thực hiện kiểm tra tấn công SQL injection với URI sau trong trường hợp trước và sau khi triển khai OWASP CRS: http://www.modsec.com/?p=1%20order%20by%201,2,4

Hình 4: Tấn công SQLI trước khi triển khai OWASP CRS

Hình 5:Tấn công SQLI sau khi triển khai OWASP CRS

Cảnh báo ghi nhận tấn công:

[Tue Jun 04 18:40:39 2013] [error] [client 192.168.149.1] ModSecurity: Access denied with code 403 (phase 2) Pattern match "\\\\b(?i:having)\\\\b\\\\s+(\\\\d{1,10}|'[^=]{1,10}')\\\\s*?[=<>]|(?i:\\\\bexecute(\\\\s{1,5}[\\\\w\\\\.$]{1,5}\\\\s{0,3})?\\\\()|\\\\bhaving\\\\b ?(?:\\\\d{1,10}|[\\\\'\\"][^=]{1,10}[\\\\'\\"]) ?[=<>]+|(?i:\\\\bcreate\\\\s+?table.{0,20}?\\\\()|(?i:\\\\blike\\\\W*?char\\\\W*?\\\\()|(?i:(?:(select(.* " at ARGS:p [file "/opt/modsecurity/etc/crs/activated_rules/modsecurity_crs_41_sql_injection_attacks.conf"] [line "130"] [id "959070"] [rev "2"] [msg

"SQL Injection Attack"] [data "Matched Data: order by found within ARGS:p: 1 order by 1,2,4"] [severity "CRITICAL"] [ver "OWASP_CRS/2.2.7"] [maturity "9"] [accuracy "8"] [tag

"OWASP_CRS/WEB_ATTACK/SQL_INJECTION"] [tag "WASCTC/WASC-19"] [tag

"OWASP_TOP_10/A1"] [tag "OWASP_AppSensor/CIE1"] [tag "PCI/6.5.2"] [hostname

"www.modsec.com"] [uri "/"] [unique_id "Ua3SN38AAAEAAAcbBfsAAAAA"]

IX TỔNG QUAN VỀ RULE

Giới thiệu

Modsecurity định nghĩa 9 loại chỉ thị để người dùng có thể triển khai các tính năng lọc linh động cho hệ thống web

SecAction Performs an unconditional action This directive is

essentially a rule that always matches

SecDefaultAction Specifies the default action list, which will be used in

the rules that follow

SecMarker Creates a marker that can be used in conjunction with

the skipAfteraction A marker creates a rule that does nothing, but has an ID assigned to it

SecRuleInheritance Controls whether rules are inherited in a child

configuration context.

SecRuleRemoveById Removes the rule with the given ID

SecRuleRemoveByMsg Removes the rule whose message matches the given

yId Updates the target list of the rule with the given ID.

Cú pháp rule trong ModSecurity:

SecRule VARIABLES OPERATOR [TRANSFORMATION_FUNCTIONS, ACTIONS]

Trong một rule ModSecurity có 4 thành phần, trong đó hai thành phần cuối của cú pháp là tùy chọn Nếu trong một rule mà bạn định nghĩa không sử dụng 2 thành phần

TRANSFORMATION_FUNCTIONS và ACTIONS thì ModSecurity sẽ dùng các giá trị mặc định được thiết lập trong SecDefaultAction

Biến (Variables)

Trong ModSecurity, biến được sử dụng cho việc trích xuất (etract) các thành phần khác nhaucủa gói tin HTTP được Bạn cần chú ý rằng các dữ liệu tương tác trong quá trình hoạt động củaModSecurity là dữ liệu thô (raw bytes of data) bao gồm các ký tự đặc biệt Mặc dù ứng dụng web mà bạn xây dựng chỉ tương tác với các dữ liệu dạng văn bản (text), nhưng bạn không thể chắc chắn được chuyện gì đang xảy ra nếu như các đối thủ sử dụng những cách để vượt qua cáckiểm soát logic

Trong phiên bản hiện tại, ModSecurity đã hỗ trợ 77 loại biến khác nhau để tăng tính linh động chống lại các kiểu khai thác nâng cao

Operators

Tại mục này, ModSecurity sẽ xác định các thức mà một biến được xử lý Các regular

expresstion được sử dụng phổ biến, tuy nhiên ModSecurity định nghĩa sẵn các operator nhằm

hỗ trợ bạn có thể tự xây dựng một rule cho mục đích cá nhân

Scalar variables: Chứa một phần thông tin dữ liệu, có thể là chuỗi hoặc số Ví dụ,

REMOTE_ADDR luôn chứa địa chỉ IP của người dùng,

Collections: Nhóm các biến lại với nhau thành một nhóm.

Read-only collections: Nhóm các biến không thể thay đổi trong quá trình thực hiện tương

tác giữa ModSecurity và Apache

Read/write collections: Nhóm này được sử dụng trong trường hợp bạn cần triển khai các

rule có sự thay đổi trong dữ liệu đầu vào

Special collections: Nhóm các biến đặc biệt được dùng trong việc trích xuất dữ liệu đầu vào

dưới dạng XML

Persistent collections: Khi các rule sử dụng các thành phân trong nhóm này, thì dữ liệu sẽ

được lưu trữ trong cơ sở dữ liệu nội bộ của ModSecurity Trong các tác vụ như theo dõi IP, phiên làm việc hoặc theo dõi người dùng đăng nhập thì việc lưu trữ sẽ được sử dụng

Request variables

Các biến trong phân nhóm này chịu trách nhiệm trích xuất các giá trị trong HTTP request header để đưa vào phần phân tích Các trường giá trị ModSecurity hỗ trợ trong các biến được thu thập từ các URI, method (GET HEAD POST PUT …), protocol information ( HTTP 1.1, HTTP 1.0)

Bảng sau liệt kê các giá trị biến (Request variable) mà ModSecurity hỗ trợ:

ARGS_COMBINED_SIZE Total size of all request parameters combined

ARGS_NAMES Request parameters’ names (collection)

ARGS_GET Query string parameters (read-only collection)

ARGS_GET_NAMES Query string parameters’ names (read-only collection)ARGS_POST Request body parameters (read-only collection)

ARGS_POST_NAMES Request body parameters’ names (read-only collection)

FILES_COMBINED_SIZE Combined size of all uploaded files

FILES_NAMES File parameter names (read-only collection)

FILES_SIZES A list of file sizes (read-only collection)

FILES_TMPNAMES A list of temporary file names (read-only collection)

REQUEST_COOKIES Request cookies (read-only collection)

REQUEST_COOKIES_NAM Request cookies’ names (read-only collection)

REQUEST_FILENAME Request URI file name/path

REQUEST_HEADERS Request headers (collection, read-only)

REQUEST_HEADERS_NAM

REQUEST_URI Request URI, convert to exclude hostname

REQUEST_URI_RAW Request URI, as it was presented in the request

SCRIPT_BASENAME Script basename

SCRIPT_FILENAME Script file name/path

SCRIPT_GROUPNAM

SCRIPT_MODE Script permissions

SCRIPT_USERNAME Script user name

Response variables

Các biến trong phân nhóm này được dùng cho việc xác định các dữ liệu trả về người dùng Phần lớn các giá trị này được sử dụng trong pha thứ 3 Response headers (3) Một số thành phần liên quan đến nội dung gói tin HTTP (body) thì sẽ được dùng trong pha thứ 4 Response body (4)

Bảng sau liệt kê các giá trị biến (respone variable) mà ModSecurity hỗ trợ:

RESPONSE_CONTENT_LENG Response content length

RESPONSE_CONTENT_TYPE Response content type

RESPONSE_HEADERS Response headers (read-only collection)

RESPONSE_HEADERS_NAME

Miscellaneouse variables

Bảng sau liệt kê các giá trị biến (miscellaneouse variable) mà ModSecurity hỗ trợ:

HIGHEST_SEVERITY Highest severity encountered

MATCHED_VAR Contents of the last variable that matched

MATCHED_VARS Contents of all variables that matched int the most

recent ruleMATCHED_VARS_NAM

ES

Names of all variables that matched in the most recent rule

MATCHED_VAR_NAME Name of the last variable that matched

MODSEC_BUILD ModSecurity build version (e.g., 02050102)

SESSIONID Session ID associated with current transaction

UNIQUE_ID Unique transaction ID generated by mod_unique_id

USERID User ID associated with current transaction

WEBAPPID Web application ID associated with current transactionWEBSERVER_ERROR_L

MULTIPART_CRLF_LF_LINES Multipart parsing error: mixed line

endings usedMULTIPART_DATA_BEFORE Multipart parsing error: seen data before

first boundaryMULTIPART_DATA_AFTER Multipart parsing error: seen data after

last boundaryMULTIPART_FILE_LIMIT_EXCEEDED Multipart parsing error: too many filesMULTIPART_HEADER_FOLDING Multipart parsing error: header folding

semicolon before boundaryMULTIPART_STRICT_ERROR At least one multipart error except

unmatched boundary occurredMULTIPART_UNMATCHED_BOUNDAR

REQBODY_PROCESSOR Request processor that handled request

bodyREQBODY_PROCESSOR_ERROR Request processor error flag (0 or 1)REQBODY_PROCESSOR_ERROR_MSG Request processor error message

Collections variables

Các biến trong nhóm này có thể chứa biến của các nhóm khác, nhằm phục vụ việc thu thập

dữ liệu để đưa qua cơ chế phân tích hành vi trong ModSecurity

although it’s possible to use setvar

@geoLookupinvocation (read-only collec

(read/write collection)RULE IP address data storage (read/write collection)

SESSION Transient transaction data (read/write

collection)

TIME_EPOCH Seconds since January 1, 1970 (e.g.,

1251029017)

TIME_MIN Minute of the hour (0–59)

Operators

Các toán tử kiểm tra trong ModSecurity có nhiệm vụ phân tích các biến đầu vào Variables

để ra quyết định Hầu hết các rule sẽ sử dụng các regular expression cho việc phân tích, nhưng trong một số trường hợp cụ thể thì các phân nhóm toán tử khác sẽ hữu ích hơn

Ta xét trường hợp cần so sánh các giá trị là số (numberic) thì việc sử dụng Regular

expression là khá bất lợi cho việc tạo rule và tài nguyên khi thực thi so sánh rule ModSecurity

hỗ trợ một nhóm phương thức so sánh khác nhau nhằm tăng hiệu năng cho phần kiểm tra Trong trường hợp này thì việc sử dụng các toán tử về số học sẽ hiệu quả hơn nhiều so với regular expression

Các toán tử so trùng chuỗi được dùng phân tích các đầu dữ liệu vào từ các biến Toán tử

@rx và @pm thường được sử dụng nhiều trong các rule phân tích, bởi vì tính linh động của

@rx và tốc độ xử lý của @pm Trong một số trường hợp khác thì các toán tử còn lại sẽ hỗ trợ bạn phát triển các rule tùy theo mục đích chi tiết

@pmFromFile(also @pmfas of

2.6) from a fileParallel patterns matching, with patterns read

Numerical operators

Trong bảng dưới liệt kê các toán tử hỗ trợ so sánh các giá trị số Trong phiên bản

ModSecurity trước 2.5.12 thì việc so sánh các giá trị số học phải thông qua regular expression, việc này làm ảnh hưởng lớn đến hiệu năng hoạt động của server

@validateByteRange Validates that parameter consists only of

allowed byte values

@validateDTD Validates XML payload against a DTD

@validateSchema Validates XML payload against a schema

@validateUrlEncoding Validates an URL-encoded string

@validateUtf8Encoding Validates an UTF-8-encoded string

Miscellaneous operators

Và phân nhóm operator cuối cùng mà ModSecurity hỗ trợ cho phép bạn tạo ra một số rule với các chức năng lọc khá hữu dụng như: phát hiện lộ thông tin credit card (@verifyCC), kiểm tra vùng địa lý của IP người dùng (@geoLookup), kiểm tra lộ thông tin số an sinh xã hội (@verifySSN )…

@geoLookup Determines the physical location of an IP

address

@inspectFile nvokes an external script to inspect a file

(real-time block list)

@verifyCC Checks whether the parameter is a valid credit

card number

@verifyCPF Checks whether the parameter is a valid

Brazilian social security number

@verifySSN Checks whether the parameter is a valid US

social security number

@ipMatch Matches input against one or more IP addresses

or network segments

@ipMatchFromFile( and @ip

MatchF), as of 2.7.0 As @ipMatch, but reads input from a file

Các hành vi (action) là điểm mạnh của ModSecurity cho phép hệ thống web có khả năng miễn dịch với một số loại khai thác đã biết đến Các action là thành phần cuối cùng trong một rule, Apache sẽ quyết định kết quả trả về phía người dùng (thông báo lỗi, hủy kết nối hoặc cho phép truy cập…)

ModSecurity chia các action thành 7 phân mục:

pause Pause for a period of time, then execute allow

redirect Redirect request to some other web server

Flow actions

chain Connect two or more rules into a single logical

rule

skipAfter Skip after the rule or marker with the provided

ID

Metadata actions

Phân nhóm này cho phép bạn định nghĩa các thông tin mô tả về rule Các thông tin này thường được dùng để mô tả thông báo lỗi (error message), giải thích nguyên nhân xuất hiện lỗi hoặc cách khắc phục đề nghị

capture Capture results into one or more variables

deprecatevar Decrease numerical variable value over time

expirevar Remove variable after a time period

setvar Set, remove, increment, or decrement a variable

application user ID (username)

application session IDLogging actions

Các action trong phân nhóm ghi log chỉ dẫn ModSecurity phương thức và nơi lưu trữ log Các action ảnh hưởng đến việc ghi log trong rule là auditlog, log, noauditlog và nolog Để điều khiển quá trình ghi log, bạn cần tham khảo ctlaction

auditlog Log current transaction to audit log

logdata Log supplied data as part of error message

noauditlog Do not log current transaction to audit log

sanitiseArg Remove request parameter from audit log

sanitiseMatched Remove parameter in which a match occurred

from audit logsanitiseRequestHeader Remove request header from audit log

Special actions

multiMatch Activate multi-matching, where an operator

runs after every transformation

variables before matchingMiscellaneous Actions

SecRule REQUEST_URI <script>

Với biểu thức so sánh như trên thì ModSecurity thực thi kiểm tra dữ liệu trong URI từ phía người dùng và xác định có sự tồn tại của chuỗi <script> hay không Tuy nhiên, bạn có thể sử dụng thêm một operator vào rule trên để tăng hiệu quả kiểm tra trong ModSecurity, tôi sẽ viết lại rule trên như sau:

SecRule REQUEST_URI " @rx <script>"

ModSecurity hỗ trợ nhiều loại operator khác nhau Một số có cùng chức năng, nhưng các operator sẽ có ảnh hưởng khác nhau đến hiệu suất của hệ thống Trong ví dụ tôi đưa ra thì chuỗi <script> không phải là một biểu thức so sánh, bởi vì chúng không chứa ký tự đặc biệt để xác định đây là một mẫu biểu thức Tôi có thể viết lại rule trên bằng các sử dụng @contains để tối ưu:

SecRule REQUEST_URI " @contains <script>"

Hướng dẫn sử dụng biến (variable)

Trong một rule, bạn có thể sử dụng nhiều biến khác nhau bằng cách dùng ký tự pipe “|” để phân cách:

SecRule REQUEST_URI|REQUEST_PROTOCOL <script>

Nhóm các biến được dùng trong một rule được gọi là collection Trên thực tế, các rule được

viết có thể chứa nhiều hơn một thành phần tham số (parameter), ta có thể dùng dấu hai chấm

“:” để phân cách biến và tên của tham số

SecRule ARGS:p <script>

SecRule ARGS:p|ARGS:q <script>

Ta có thể sử dụng cấu trúc như ví dụ trên để so trùng bằng mẫu biểu thức, ví dụ bên dưới sẽ tìm chuỗi <script> trong các tham số bắt đầu bằng ký tự p:

SecRule ARGS:/^p/ <script>

Biến ARGS mặc định sẽ theo dõi tất cả các tham số nếu bạn không chỉ định tên tham số hoặc biểu thức mẫu Việc liệt kê các tham số giúp giảm thiểu tài nguyên hệ thống và năng hiệu suất theo dõi của ModSecurity Trong một số trường hợp, bạn có thể sử dụng toán tử phủ định (operator negation) để loại bỏ một nhóm biến trong rule, bằng cách thêm dấu chấm than vào trước nhóm biết mà bạn không sử dụng:

SecRule ARGS|!ARGS:z <script>

Hướng dẫn sử dụng liên kết rule (chain)

ModSecurity cho phép bạn liên kết các SecRule riêng lẽ với nhau thành một SecRule duy

nhất thông quan từ khóa chain Liên kết các rule sẽ giảm thiểu các tình huống cảnh báo không

chính xác, giúp bạn đơn giản hóa việc viết rule trong trường hợp cần kiểm tra các điều kiện mang tính chất tuần tự

Trong ví dụ bên dưới, ModSecurity sẽ luôn thực hiện kiểm tra SecRule đầu tiên (kiểm tra tham số p), nếu xảy ra trường hợp có dữ liệu trùng khớp thì rule tiếp theo (kiểm tra tham số q)

sẽ được kiểm tra

SecRule ARGS:p <script> chain

SecRule ARGS:q <script>

Hướng dẫn sử dụng toán tử phủ định

ModSecurity cho phép bạn sử dụng phương pháp phủ định một thành phần bất kỳ trong rule.Giả sử bạn muốn triển khai một rule có chức năng theo dõi người dùng đăng nhập ngoại trừ user admin và root, ta có thể viết như sau:

SecRule ARGS:username "!@rx ^(admin|root)$"

Trong rule SecRule ARGS:p|ARGS:q "!@eq 5" thì ModSecurity sẽ trùng khi có một trong hai

tham số p hoặc q có giá trị bằng 5 Trường hợp bạn cần kiểm tra tham số p và q có giá trị bằng

5 thì ta sử dụng từ khóa chain:

SecRule ARGS:p " !@eq 5" chain

SecRule ARGS:q " !@eq 5"

SecRule &ARGS:username " @eq 1"

Để kiểm tra trong trường hợp có nhiều hơn một tham số username, ta viết lại rule như sau:

SecRule &ARGS:username " !@eq 1"

Hướng dẫn về action

Hành vi (action) là thành phần thứ ba trong chỉ thị SecRule và là thành phần thứ nhất trong chỉ thị SecAction Một rule có thể không tồn tại action hoặc nhiều hơn một action Nếu ta sử dụng nhiều action trong một rule, ta có thể phân cách bằng dấu phẩy “,” hay khoảng trắng giữa các action Trong rule bên dưới, ta sử dụng 2 action là log và deny:

SecRule ARGS K1 log,deny

Một số action trong ModSecurity yêu cầu có tham số khi sử dụng Trong trường hợp này, ta cần phân cách action và tham số bởi dấu “:” Một ví dụ về việc sử dụng hành vị deny các yêu cầu đến server và gây lỗi “404 Not found”:

SecRule ARGS K1 log,deny,status:404

Một phần cần lưu ý đối với các hành vi có tham số chứa khoảng trắng hoặc ký tự “,” , bạn nên chắc chắn rằng các tham số này được đặt trong một cặp dấu ngoặc đơn ‘’

SecRule ARGS K1 " log,deny,msg:'Acme attack detected'"

Action Defaults

ModSecurity định nghĩa một ngữ cảnh được gọi là default action list (tạm dịch: danh sách

các hành vi mặc định), nhằm thực hiện chèn các giá trị này vào những rule không được chỉ định action

Giả sử, sau khi thực hiện cấu hình trong tập tin main.conf của ModSecurity, giá trị của

SecDefaultAction là phase:2,log,auditlog,pass Ta có một rule đơn giản không được chỉ định

action:

SecRule ARGS K1

Khi ModSecurity hoạt động, thì rule trên sẽ được hiểu như sau:

SecRule ARGS K1 phase:2,log,auditlog,pass

Bằng cách này, ModSecurity giúp bạn triển khai một rule dễ dàng hơn mà không cần phải chỉ định một action lặp lại nhiều lần:

SecDefaultAction phase:2,log,deny,status:404

(parameter), tham số này được dùng để liên kết với thành phần thứ ba trong chỉ thị SecRule.

SecAction nolog,pass,setvar:tx.counter=10

Using Transformation Functions

Trong các phương pháp khai thác lỗ hổng ứng dụng web, hacker thường sử dụng các kỹ thuật biến đổi dữ liệu (obfuscation) để vượt qua cơ chế kiểm tra Để chống lại phương pháp biến đổi, ModSecurity hỗ trợ chuyển đổi dữ liệu đầu vào trước khi thực hiện kiểm tra các tấn công Ví dụ:

Trong tấn công SQL Injection thì hacker thực hiện câu truy vấn: “id=1&UniON

%20SeLeCT%201,2,3,4,5,6” (trong trường hợp này ta cần chuyển đổi các ký tự sang chữ

thường (lowercase) trước khi kiểm tra)

Hoặc trong rule bên dưới, ModSecurity sẽ thực hiện chuyển các ký tự thành chữ thường, đồng thời loại bỏ các ký tự khoảng trắng không cần thiết:

SecRule ARGS " @contains delete from" \

Một số lý do bạn cần sử dụng chức năng chuyển đổi:

 Với các khai thác sử dụng phương pháp encode base64, ta có thể áp dụng

t:base64Decode để decode dữ liệu đầu vào

 Tương tự Base64, với trường hợp hacker chuyển đổi kiểu dữ liệu thành dạng Hexthì t:hexEncode nên được sử dụng để chuyển đổi sang dạng Plaintext

Các chỉ thị sử dụng trong ModSecurity được liên kết duy nhất với một action (hoặc chỉ thị SecAction) để xử lý kết quả đã phân tích trước đó Có ba trạng thái mà ModSecurity hỗ trợ trong việc ngăn chặn tấn công:

 Chuyển tiếp sang rule tiếp theo

 Ngưng thực hiện pha hiện thời, nhưng tiếp tục thực hiện phiên trao đổi dữ liệu

 Ngưng thực hiện pha hiện thời, đồng thời ngừng trao đổi dữ liệu

Changing Rule Flow

Giả sử trường hợp các rule trong ModSecurity được xử lý tuần tự từ rule đầu tiên đến rule cuối cùng Nếu có một giá trị trùng với mẫu so sánh, thì tiến trình kiểm tra trong các rule tiếp

sau đó nên được bỏ qua Để thực hiện việc này, từ khóa skip có thể được đưa vào sử dụng như

sau:

SecRule ARGS K1 id:1,nolog,pass,skip:2

SecRule ARGS K2 id:2,nolog,pass

SecRule ARGS K3 id:3,log,block

Với ví dụ trên, khi rule 1 trùng mẫu so sánh thì các rule tiếp sau sẽ không thực hiện kiểm tra

Từ khóa skip thường được dùng như một phương pháp tối ưu hóa trong ModSecurity Đôi

khi việc thực thi các nhóm rule có nhiều điều kiện sẽ làm lãng phí tài nguyên CPU Trong trường hợp này, bạn có thể thực hiện việc kiểm tra điều kiện của một rule và nên bỏ qua các bước tiếp theo nếu điều kiện đầu vào không thỏa tiêu chí

Ví dụ:

Trong các rule kiểm tra trong nhóm Cross Site Scripting (XSS) thì các mẫu tấn công như

UNION, ORDER BY, XP_CMD, / / /, 1’ or 1=1 , … là không cần thiết phải kiểm tra Việc

sử dụng từ khóa skip sẽ giúp tối ưu tài nguyên xử lý trong trường hợp này.

If-Then-Else

Tuy ModSecurity không hỗ trợ các từ khóa if-then-else trong cấu trúc rule, nhưng bạn vẫn

có thể thực hiện cấu trúc kiểm tra điều kiện thông qua ví dụ bên dưới:

SecRule ARGS K1 id:1,nolog,pass,skip:2

SecRule ARGS K2 id:2,block

SecAction nolog,pass,skip:1

SecRule ARGS K3 id:3,block

SecRule đầu tiên sẽ quyết định một rule được thực hiện bên dưới Nếu trong rule 1 trùng mẫu, thì hành vi skip được thực hiện và chuyển đến thực hiện rule 3 Tuy nhiên, nếu rule 1 không trùng mẫu thì rule 2 sẽ được thực hiện và SecAction sẽ được thực hiện sau đó Cấu trúc

rẽ nhánh này đảm bảo ruel 3 sẽ không thực thi nếu rule 1 không trùng mẫu dữ liệu

Capturing Data

Các biến trong nhóm TX được phân biệt bởi giá trị từ 0 đến 9 Những biến này được dùng trong việc thu thập dữ liệu đầu vào Để sử dụng chức năng thu thập dữ liệu, bạn cần chú ý hai điều sau:

Sử dụng dấu ngoặc đơn () trong trường hợp dùng các biểu thức so sánh, việc này giúp ModSecurity xác định vị trí dữ liệu cần thu thập

Sử dụng hành vi carpture trong rule, nơi mà bạn muốn thu thập dữ liệu.

Giả sử trong ứng dụng web có sử dụng việc chèn một mã xác định phiên làm việc (session) vào URI như bên dưới:

http://www.modsec.com/69d032331009e7b0/index.html

Yêu cầu đặt ra là bạn cần xác định giá trị 69d032331009e7b0 trong URI để phục vụ việc kiểm tra session người dùng Tham khảo biểu thức so sánh trong rule sau:

# Initialize session state from the session identifier in URI

SecRule REQUEST_URI ^/([0-9a-fA-f]{16})/ phase:1,nolog,pass,capture,setsid:%{TX.1} Phân tích biểu thức ^/([0-9a-fA-f]{16})/ ta có:

^/ Xác định vị trí thu thập dữ liệu, bắt

đầu bằng ký tự “/” /69d032331009e7b0/TX.0 = ([0-9a-fA-f]{16}) Nội dung SessionID là một chuỗi bao

gồm 16 ký tự số, chữ thường, chữ hoa (biểu thức phải được đặt trong dấu ngoặc đơn)

TX.1 = 69d032331009e7b0

Dưới dây là log audit quá trình ModSecurity thực hiện phân tích biểu thức:

[4] Recipe: Invoking rule 15b6610; [file

"/opt/modsecurity/etc/crs/activated_rules/carpturedata.conf"] [line "1"] [id "10000"].

[5] Rule 15b6610: SecRule "REQUEST_URI" "@rx ^/([0-9a-fA-f]{16})/"

"phase:1,auditlog,id:10000,nolog,pass,capture,setsid:%{TX.1}"

[4] Transformation completed in 7 usec

[4] Executing operator "rx" with param "^/([0-9a-fA-f]{16})/" against REQUEST_URI.[9] Target value: "/69d032331009e7b0/index.html"

[9] Added regex subexpression to TX.0: /69d032331009e7b0/

[9] Added regex subexpression to TX.1: 69d032331009e7b0

[4] Operator completed in 58 usec

[9] Resolved macro %{TX.1} to: 69d032331009e7b0

Variable Manipulation

Hầu hết các dữ liệu mà ModSecurity phân tích sẽ được thao tác ở chế độ chỉ đọc (dữ liệu tĩnh hoặc không thay đổi) Tuy nhiên, ModSecurity cũng hỗ trợ việc tạo ra các biến có giá trị thay đổi nhằm phục vụ một số mục đích cụ thể

Ta có thể tạo ra một biến bằng cách sử dụng hành vi setvar:

SecAction nolog,pass,setvar:tx.score=1 #giá trị của biến tx.score là 1

SecAction nolog,pass,setvar:!tx.score #xóa giá trị biến tx.score

SecAction nolog,pass,setvar:tx.score=+2 #giá trị tx.score sẽ tăng 2 mỗi khi thực hiện action

SecAction nolog,pass,setvar:tx.score=-1 #giá trị tx.score sẽ giảm mỗi khi thực hiện action

Metadata

Metadata được dùng trong rule với mục đích hiển thị thông tin chi tiết về cảnh báo mà rule tạo ra Các thông tin này không gây ảnh hưởng đến quá trình phân tích dữ liệu Tuy nhiên, metadata sẽ hỗ trợ bạn dễ dàng quản lý các cảnh báo trong quá trình phân tích log, giúp xác định nhanh chóng nguyên nhân và cách phòng tránh các khai thác vào web server

Tôi sẽ băt đầu với rule đơn giản như sau:

SecRule REQUEST_METHOD "!^(GET|HEAD)$" \

Id:10001,phase:1,t:none,log,block

Với các tham số như trên, thì rule 10001 vẫn hoạt động ổn định khi trùng mẫu Tuy nhiên,

dữ liệu sau khi phân tích không cung cấp đủ thông tin chi tiết về thông tin kỹ thuật, các hướng dẫn xử lý v.v…

[22/Jun/2013:01:21:57 +0700] [www.modsec.com/sid#139efb0][rid#1606370][/][2]

Warning Match of "rx ^(GET|HEAD)$" against "REQUEST_METHOD" required [file

"/opt/modsecurity/etc/crs/activated_rules/addingMetadata.conf"] [line "1"] [id "10001"]

Để rule 10001 được mô tả tốt hơn về thông báo lỗi, tôi sẽ tùy biến rule lại như sau:

SecRule REQUEST_METHOD "!^(GET|HEAD)$" \

"phase:1,t:none,log,block,id:1001,rev:2,\

severity:WARNING,msg:'Request method is not allowed'"

Trong thông báo log, ta có thể ghi nhận thay đổi:

[22/Jun/2013:01:28:19 +0700] [www.modsec.com/sid#17f1fb0][rid#1a59350][/][2]

Warning Match of "rx ^(GET|HEAD)$" against "REQUEST_METHOD" required [file

"/opt/modsecurity/etc/crs/activated_rules/addingMetadata.conf"] [line "3"] [id "10001"] [rev

"2"] [msg "Request method is not allowed"] [severity "EMERGENCY"]

#rev: xác định phiên bản thay đổi của rule

#msg: dữ liệu mô tả về rule

#severity: thông báo mức độ nguy hiểm khi có cuộc tấn công vào hệ thống web (mức độ nguy hiểm nhất là EMERGENCY (1) và ít nguy hiểm nhất là DEBUG (7)

XI PHÂN TÍCH CÁC RULE ỨNG DỤNG THỰC TẾ

Trường hợp 1: Chống tấn công Replay attack thông qua cơ chế đánh token ngẫu nhiên.Tham khảo DANH MỤC LỖ HỔNG BẢO MẬT OWASP 2010: Replay Testing (OWASP-WS-007)

Trong phần này, tôi sẽ phân tích trường hợp hạn chế việc khai thác vào các form html Việc

sử dụng phương thức POST để nhận dữ liệu từ phía người dùng thường tạo ra nguy cơ gói tin

bị thay đổi trên đường truyền, nhầm thực hiện thêm/bớt dữ liệu phục vụ cho từng loại tấn công khác nhau

Để thực hiện chống lại phương pháp tấn công này, ta cần tham khảo các chỉ thị mà

SecHashMethodrx "HashHref" "[a-zA-Z0-9]"

SecRule REQUEST_URI "@validateHash [a-zA-Z0-9]"

"phase:2,id:1000,t:none,block,msg:'Request Validation Violation.',ctl:HashEnforcement=On"