Phương thức phòng chống tấn công sử dụng Mod security

ModSecurity là một Opensource web application firewall được Ivan Ristic phát triển dành cho Web Server Apache. Ivan Ristic cũng là tác giả quyển sách “Mod Security Handbook”. Ông là một người có rất nhiều kinh nghiệm trong bảo vệ Web Server Apache. Ông đã có nhiều thời gian nghiên cứu Web Application Security, Web Intrusion Detection, và Security Patterns. Trước khi chuyển sang lĩnh vực security, Ivan đã có nhiều năm làm việc như một Developer, System Architect, Technical Director trong phát triển phần mềm. Ông là người sáng lập ra công ty ThinkingStone làm các dịch vụ liên quan đến web application security.

MOD SECURITY

PHẦN 1: CƠ BẢN VỀ GIAO THỨC HTTP

Phần này chỉ giới thiệu sơ lược các kiến thức cơ bản về giao thức HTTP, tạo tiền đề để

phần 2 trình bày về MODSECURITY Vì vậy, nếu bạn nào cần tìm hiểu sâu hơn, hãy

tham khảo RFC hoặc cuốn HTTP Essentials

11 Giới thiệu chung

1.1.1 Lớp của giao thức HTTP

HTTP (Hypertext Transfer Protocol) là giao thức thuộc lớp ứng dụng trong mô hình tham chiếu OSI Hoạt động thông thường ở port 80 và là giao thức hướng kết nối Nói cách khác, trước khi thực hiện phiên làm việc, giao thức HTTP sẽ thực hiện bắt tay ba bước

Hình 1.1 Lớp của giao thức HTTP

1.1.2 URI – Uniform Resource Identifiers

Thông thường, chúng ta thường quen thuộc với định nghĩa URL (Uniform Resource Locators) Địa chỉ http://www.example.com.vn là một ví dụ về URL Trên thực tế, không

có nhiều khác biệt giữa hai khái niệm URL và URI, URL một chỉ là một loại của URI

URI là một đặc điểm kỹ thuật của giao thức HTTP Như hình dưới cho thấy một URI chứa rất nhiều các thành phần, không đơn giản như URL

Hình 1.2 Cấu trúc đầy đủ của URI

- Protocol: Xác định các giao thức và các ứng dụng cần thiết để truy cập tài nguyên,

trong trường hợp này là giao thức HTTP

- Username: Nếu giao thức hỗ trợ khái niệm về tên người dùng thì username cung cấp

tên người dùng để chứng thực truy cập tài nguyên

- Password: Mật khẩu truy cập tài nguyên

- Host: Tên miền truyền thông cho webserver,

- Port: Là port cho các giao thức lớp ứng dụng, ví dụ như HTTP là cổng 80 (có thể bỏ

qua tham số này)

- Path: đường dẫn phân cấp đến tài nguyên được đặt trên Server

- File: Tên các tập tin tài nguyên trên Server

- Query: Các tuy vấn thêm thông tin về tài nguyên của Client

- Fragment: Một vị trí nào đó trong tài nguyên

Hình 1.3 Hoạt động của HTTP

Hiện nay, giao thức HTTP đã hỗ trợ một phiên kết nối TCP cho phép nhiều HTTP request

Hình 1.4 Hoạt động kết nối của HTTP

1.2.2 Pipelining

Pipelining cũng nhằm mục đích cải thiện hiệu năng của HTTP Client không cần phải chờ Server response mới có thể request và ngược lại

Hình 1.5 Hoạt động Pipelining của HTTP

1.2.3 Web Page Retrieval – GET

Hoạt động HTTP đơn giản nhất là GET Đó là cách để Client lấy một đối tượng hoặc tài nguyên nào đó trên Server Các trình duyệt sẽ yêu cầu một website từ Server với GET

Hình 1.6 Hoạt động GET của HTTP

Với ví dụ trên, Client khởi tạo và gởi thông điệp GET đến Server, thông điệp này định danh đối tượng mà Client yêu cầu Server đáp ứng bằng một URI (Uniform Resource Identifier) Server có thể trả về tài nguyên mà Client yêu cầu với một mã trạng thái 200

OK Nếu Server không đáp ứng được yêu cầu Client thì nó sẽ gởi về một số mã trạng thái khác được mô tả ở bảng bên dưới

Bảng 1.1 Mã trạng thái được trả về của HTTP

1.2.4 Web Forms – POST

Trong khi GET cho phép một Server gửi thông tin đến Client, thì hoạt động POST cung cấp một cách để Client gửi thông tin đến các Server Trình duyệt sử dụng POST để gởi nội dung các Form đến Web Server Hình dưới cho thấy một ví dụ như vậy

Hình 1.7 Ví dụ về Web Forms POST

Hình 1.8 Hoạt động POST của HTTP

Như hình trên cho thấy, hoạt động POST đơn giản như GET Client gửi một thông điệp POST và bao gồm thông tin mà nó muốn gửi đến server Cũng giống như GET, một phần của thông điệp POST là URI Nhưng trong trường hợp này, URI xác định các đối tượng trên Server có thể xử lý thông tin

Cũng như GET, Server có thể trả về thông tin cho client Đối với trình duyệt web, thông tin thường là một trang web mới để hiển thị

1.2.5 File Upload – PUT

Các hoạt động PUT cũng cung cấp một cách để client gửi thông tin đến các Server Hay

nói cách khác, PUT dùng để upload dữ liệu lên server

Như hình dưới cho thấy, hai hoạt động nhìn rất giống nhau Với POST, Client gửi bao gồm một URI và dữ liệu Web Server về mã trạng thái, tuỳ chọn kèm theo và dữ liệu Sựkhác biệt giữa POST và PUT ở chỗ URI : Với POST, các URI xác định một đối tượng trên Server mà có thể xử lý dữ liệu Với một PUT, các URI xác định đối tượng trong đó các Server nên đặt dữ liệu (ví dụ đường dẫn cho Server đặt dữ liệu)

Trong khi một POST URI thường chỉ ra một chương trình, script thì PUT uri thường là đường dẫn và tên cho tập tin

Hình 1.9 Hoạt động PUT của HTTP

Hình 1.10 Ví dụ về File Upload - PUT

1.2.6 File Deletion – DELETE

Với GET và PUT, giao thức HTTP trở thành một giao thức chuyển file đơn giản Hoạt

động DELETE sẽ hoàn thành chức năng này bằng cách giúp client xoá các đối tượng, tàinguyên từ các server

Như hình dưới cho thấy, client gửi một thông điệp DELETE cùng với các URI của đối tượng mà server nên xoá Các server đáp ứng với một mã trạng thái và dữ liệu kèm theo

Hình 1.11 Hoạt động File Delection - DELETE

1.2.7 Trạng thái - HEAD

Các hoạt động của HEAD giống như GET, ngoại trừ Server không trả lại đối tượng thực

tế yêu cầu Cụ thể, server sẽ trả về một mã trạng thái nhưng không có dữ liệu (HEAD cónghĩa là "tiêu đề," nghĩa là server chỉ trả về thông điệp chứa tiêu đề chứ không chứa dữ liệu)

Client có thể sử dụng thông điệp HEAD khi muốn xác minh rằng một đối tượng có tồn tại hay không,

Ví dụ: Có thể sử dụng thông điệp HEAD để đảm bảo liên kết đến một đối tượng hợp lệ

mà không tiêu tốn băng thông

Cache trong trình duyệt cũng có thể sử dụng thông điệp HEAD để xem một đối tượng đãthay đổi hay không, nếu không thay đổi thì hiển thị thông tin đã được lưu trước đây, nếu thay đổi thì sẽ thực hiện GET để lấy dữ liệu về từ Server

1.3 Thông điệp HTTP

Các phần trước đã trình bày hoạt động của HTTP, và chúng ta đã xem xét từng thông điệp cụ thể Không giống như các giao thức truyền thông khác, các thông điệp HTTP chủ yếu là các văn bản tiếng Anh Thay vì lo lắng về các bit và byte, trong phần này chúng ta xem xét những từ mà HTTP định dạng

Phần này sẽ trình bày cấu trúc tổng thể của thông điệp HTTP Chúng ta sẽ thấy, một thông điệp HTTP bắt đầu với một “line” hay một mã trạng thái, có thể được theo sau bởicác tiêu đề (header) khác nhau và phần thân (body) của thông điệp

1.3.1 Cấu trúc của thông điệp HTTP

HTTP có hai tác nhân là client và server Các client gởi yêu cầu (request) và server trả lời (response) Vì vậy, chúng ta sẽ phân tích hai thông điệp chính là HTTP Requests và HTTP Responses

a HTTP Request

Hình 1.12 Cấu trúc thông điệp HTTP Request

Hình trên cho thấy cấu trúc cơ bản của HTTP Requests Một HTTP Requests bắt đầu bởi Request-Line Request-Line có thể được theo sau bởi một hoặc nhiều header và body

Để cụ thể hơn, hình bên dưới cho thấy một thông điệp http (dưới dạng văn bản) do Internet Explorer của Microsoft gửi khi người dùng truy cập vào trang www.ft.com Dòng đầu tiên là Request-Line, và tiêu đề thông điệp tạo nên phần còn lại của văn bản

Hình 1.13 Một ví dụ về nội dung thông điệp HTTP

Hình dưới phân tích cụ thể hơn Request-Line, bao gồm 3 phần: Method – phương thức của thông điệp, URI, và Version- phiên bản của HTTP

Status-Line bắt đầu bởi số phiên bản của HTTP (trường hợp này là HTTP/1.1), sau đó là

mã trạng thái(trường hợp này là 200 OK)

Như ví dụ trên, các Message header là Accept: , Accept-Language…

Trong HTTP header có rất nhiều trường đảm nhận các tính năng, mục đích khác nhau Bài viết này chỉ mang tính giới thiệu nên sẽ không trình bày Các bạn có thể tham khảo ở

http://tools.ietf.org/html/rfc2068

Kết thúc phần 1

PHẦN 2: MODSECURITY

2.1 GIỚI THIỆU MODSECURITY

ModSecurity là một Opensource web application firewall được Ivan Ristic phát triển dành cho Web Server Apache Ivan Ristic cũng là tác giả quyển sách “Mod Security Handbook” Ông là một người có rất nhiều kinh nghiệm trong bảo vệ Web Server Apache Ông đã có nhiều thời gian nghiên cứu Web Application Security, Web

Intrusion Detection, và Security Patterns Trước khi chuyển sang lĩnh vực security, Ivan

đã có nhiều năm làm việc như một Developer, System Architect, Technical Director trong phát triển phần mềm Ông là người sáng lập ra công ty ThinkingStone làm các dịch vụ liên quan đến web application security

Hiện tại ModSecurity sử dụng giấy phép GPL, hoàn toàn miễn phí

2.2 CÁC KHẢ NĂNG CỦA MODSECURITY

Hình 2.1 Mô hình tổng quan của ModSecurity

- Request filtering: Tất cả các request gửi đến web server đều được phân tích và cản

lọc (filter) trước khi chúng được đưa đến các modules khác để xử lý

- Understanding of the HTTP protocol: ModSecurity là một tường lửa ứng dụng nên

nó có khả năng hiểu được giao thức HTTP ModSecurity có khả năng cản lọc dựa trên các thông tin ở HTTP Header hay có thể xem xét đến từng thông số hay cookies của các

request vv

- POST payload analysis: Ngoài việc cản lọc dựa trên HTTP Header, ModSecurity có

thể dựa trên nội dung (payload) của POST requests

- Audit logging: Mọi requests đều có thể được ghi lại (bao gồm cả POST) để người

quản trị có thể theo dõi nếu cần

- HTTPS filtering: ModSecurity có thể phân tích HTTPS

- Compressed content filtering: ModSecurity sẽ phân tích sau khi đã giải nén các các dữliệu được yêu cầu

Hình 2.2 Quá trình xử lý các request của Apache và ModSecurity

Modsecurity cho phép chúng ta đặt rule tại một trong năm thời điểm trong chu kỳ xử lý

của Apache như sau:

1 Phase Request Header: Rule được đặt tại đây sẽ được thực hiện ngay say khi

Apache đọc request header, lúc này phần request body vẫn chưa được đọc

2 Phase Request Body: Đây là thời điểm các thông tin chức năng chung đưa vào vào

được phân tích và xem xét, các rule mang tính ứng dụng hướng kết nối oriented) thường được đặt ở đây Ở thời điểm này, Server đã nhận đủ các thông số của request và phần request body đã được đọc Modsecurity hỗ trợ ba loại mã hoá request body

(application-+ application/x-www-form-urlencoded: Dùng để truyền form dữ liệu

+ multipart/form-data: Dùng để truyền file

+ text/xml: Dùng để phân tích dữ liệu XML

3 Phase Response Header: Đây là thời điểm ngay sau khi phần response header được

gửi trả về cho client Chúng ta đặt rule ở đây nếu muốn giám sát quá trình sau khi phần response được gửi đi

4 Phase Response Body: Đây là thời điểm chúng ta muốn kiểm tra những dữ liệu

HTML gửi trả về

5 Phase logging: Là thời điểm các hoạt động log được thực hiện, các rules đặt ở đây sẽ

định rõ việc log sẽ như thế nào, nó sẽ kiểm tra các error message log của Apache Đây cũng là thời điểm cuối cùng để chúng ta chặn các kết nối không mong muốn, kiểm tra các response header mà chúng ta không thể kiểm tra ở phase 3 và phase 4

- Thực hiện tải mã nguồn về

+ Đầu tiên cần download chữ ký :

Code:

wget http://www.modsecurity.org/download/modsecurity-apache_2.5.11.tar.gz.asc

gpg: aka "Brian Rectanus (personal) <brectanu@gmail.com>"

- Kiểm tra thành công Thực hiện giải nén mã nguồn:

apxs: /usr/sbin/apxs

Nếu chưa có, chúng ta phải cài thêm gói httpd-devel (hay apache2-dev đối với dòng debian,ubuntu )

Code:

yum install httpd-devel (hoặc apt-get install apache2-dev)

+ libxml2: Kiểm tra bằng cách :

Code:

whereis -b libxml2

libxml2: /usr/lib/libxml2.a /usr/lib/libxml2.so /usr/include/libxml2

Nếu chưa có, chúng ta phải cài thêm gói libxml2-devel (hay libxml2-dev đối với

debian,ubuntu )

Code:

yum install libxml2-devel (hoặc apt-get install libxml2-dev)

+ pcre: Kiểm tra bằng cách :

Code:

whereis pcre

pcre: /usr/include/pcre.h /usr/share/man/man3/pcre.3.gz

Nếu chưa có thì chúng ta phải cài thêm gói pcre-devel :

yum install pcre-devel (hoặc apt-get install pcre-dev)

+ mod_unique_id: Là mod thường đã được biên dịch cùng Apache Có thể kiểm tra lại

bằng cách tìm trong httpd.conf dòng:

Code:

LoadModule unique_id_module modules/mod_unique_id.so

Nếu chưa có, chúng ta phải thêm vào với nội dung như trên

- Chuyển vào thư mục chứa mã nguồn và tiến hành biên dịch :

configure: creating /config.status

config.status: creating Makefile

config.status: creating build/apxs-wrapper

config.status: creating mlogc-src/mlogc-batch-load.pl

config.status: creating t/run-unit-tests.pl

config.status: creating t/run-regression-tests.pl

config.status: creating t/gen_rx-pm.pl

config.status: creating t/csv_rx-pm.pl

config.status: creating t/regression/server_root/conf/httpd.conf

config.status: creating /tools/rules-updater.pl

config.status: creating mlogc-src/Makefile

config.status: creating mod_security2_config.h

+ Tiến hành biên dịch

Code:

make

Sau khi biên dịch thành công file mod_security2.so sẽ được tạo ra trong thư mục libs

- Tích hợp ModSecurity vào Apache

Để Apache nhận ra sự tồn tại của ModSecurity chúng ta cần copy mod_security2.so đếnthư mục chứa

modules của apache, đối với distro CentOS là /etc/httpd/modules

Code:

cp /libs/mod_security2.so /etc/httpd/modules/

Sửa lại file httpd.conf để thực hiện load module ModSecurity:

Code:

vi /etc/httpd/conf/httpd.conf

Thêm dòng

Code:

LoadModule security2_module modules/mod_security2.so

- Quy định file cấu hình ModSecurity

Chúng ta có thể cấu hình trực tiếp các thông số và rule của ModSecurity vào file

httpd.conf Nhưng để cho rõ ràng và đảm bảo không sai sót trong quá trình thực hiện - gây ảnh hưởng Apache, Chúng ta nên tạo một file cấu hình riêng và sau đó include vào.Trong CentOS các file cấu hình riêng mặc định chứa trong /etc/httpd/conf.d/

# rule thu nghiem block tat ca request co uri chua "hacker"

SecRule REQUEST_URI "hacker"

</IfModule>

Thực hiện thử nghiệm để kiểm tra hoạt động của ModSecurity Tiến hành tạo 2 file trong thư mục web, hacker.html và index.html chẳng hạn Khi chúng ta truy cập vào file index.html thì trình duyệt trả về kết quả bình thường

Còn khi truy cập vào hacker.html thì trình duyệt báo lỗi :

SecRule Target Operator [Actions]

Target (mục tiêu): Quy định cụ thể mục tiêu của request hoặc response mà chúng ta

muốn kiểm tra Trong ví dụ kiểm cơ bản được đưa ra trong phần trước, sử dụng biến có

tên REQUEST_URI, trong đó có các URI được request trên server, để nhận diện và

chặn bất cứ Client nào truy cập vào các vị trí /hacker.html Hiện có hơn 70 biến có thể

được sử dụng để tạo rule

Ngoài ra còn có một loại biến đặc biệt được gọi là biến collection có thể chứa nhiều đối

số Một ví dụ về collection là ARGS, trong đó có chứa tất cả các đối số được truyền

trong một chuỗi truy vấn hoặc thông qua một request POST

Phần Operator xác định phương pháp và so sánh khớp dữ liệu để kích hoạt Action Với

Operator, mặc định là @rx

Cuối cùng, Actions (hành động) là một danh sách các hành động được thực hiện nếu

phù hợp (matching) rule Action có thể là allow (cho phép) hoặc deny (từ chối) các request; và quy định cụ thể các mã trạng thái (status code) khi trả về (response) cho client Nếu không có action nào được quy định, các action mặc định của action

SecDefaultAction sẽ được sử dụng (rule chứa action này thường được khai báo đầu tiên)

Để làm rõ hơn, chúng ta xem ví dụ Giả sử chúng ta là một chủ doanh nghiệp nhỏ bán sách dạy nấu ăn ở định dạng file PDF trên website Để lôi kéo khách hàng mua sách, chúng ta cung cấp một chương mẫu có chứa các công thức nấu ăn ngon nhất trong cuốnsách, mà họ có thể tải về miễn phí để xem trước khi quyết định mua

Công việc kinh doanh đang ổn định, nhưng sau đó đột nhiên chúng ta nhận được đơn khiếu nại qua email nói rằng trang web của chúng ta rất chậm hoặc không truy cập được

Khi nhìn vào log chúng ta nhận thấy rằng, một IP kết nối tới server web tràn ngập với các request cho các chương mẫu Các chuỗi user-agent thấy được có tên Red Bullet

Downloader User-agent này của các chương trình Download nhanh

Giải pháp đưa ra để giải quyết vấn đề này là dùng Mod Securiry để ngăn chặn các agent này download Rules được viết như sau

user-Code:

SecRule REQUEST_HEADERS:User-Agent "Red Bullet" "deny,nolog"

Trong ví dụ trên, REQUEST_HEADERS là một Collection chứa tất cả các trường

trong thông điệp header (message header) được gởi đến bởi client và trong header này chứa User-agent Vì vậy, ta sử dụng từ khoá cho user-agent là “Red Bullet” vì từ Red Bullet này thường xuyên xuất hiện trong các header được gởi đển từ client Và Action

là deny – là từ chối và nolog là không ghi lại log

2.4.1.1 Biến và bộ chọn lọc Collection

Hiện khoản hơn 70 biến có sẵn ModSecurity sử dụng hai loại biến: biến Standard, đơn giản chỉ chứa một giá trị duy nhất, và biến Collection, có thể chứa nhiều hơn một giá trị Một ví dụ về một Collection là REQUEST_HEADERS, trong đó chứa tất cả các trường trong thông điệp header mà Client gởi tới Server, chẳng hạn như User-agent hoặc Referer

Để truy cập vào một trường trong collection, chúng ta ghi tên collection, tiếp theo là dấu hai chấm và sau đó là tên của trường hoặc tuỳ chọn mà chúng ta muốn truy cập Ví dụ:

Code:

SecRule REQUEST_HEADERS:Referer "bad-referer.com"

Trong trường hợp kiểm tra toàn bộ dữ liệu trên tất cả các collection Ví dụ, nếu chúng tamuốn kiểm tra sự hiện diện của chuỗi script có thể sử dụng rules sau đây:

Code:

SecRule ARGS "script"

Nếu muốn kiểm tra thêm các chuỗi truy vấn được gửi là username=john&login=yes ,

chúng ta có thể mở rộng rule bằng cách

Code:

SecRule ARGS:john|ARGS:login "script"

Các collection có sẵn trong ModSecutity 2.5

2.4.1.2 Chuyển đổi giữa các Collection

TX Collection còn được gọi là các Transaction collection Chúng ta có thể sử dụng nó

để tạo ra các biến phục vụ riêng cho mình

Code:

SecRule REQUEST_URI “passwd” “pass,setvar:tx.hackscore=+5”

SecRule TX:HACKSCORE “@gt 10” deny

Trong hai rule đầu tiên sử dụng action setvar để thiết lập các biến collection Thực hiện tạo biến hackscore và tăng giá trị lên 5 nếu rule được thực thi (matching rule) Đến khi biến hackscore có giá trị bằng 10 thì thực thi rule thứ hai sẽ được thực thi với action là deny

(Có thể loại bỏ biến bằng cách sử dụng setvar cú pháp setvar:!tx.hackscore)

2.4.1.3 Lưu trữ các Request

Có ba loại collection trong ModSecurity được sử dụng để lưu trữ liên tục( persistent storage) Như phần trước đã trình bày, setvar giúp tạo ra một biến và gán giá trị cho nó Tuy nhiên, biến sẽ hết hạn và không còn nữa khi các request hiện tại đã được xử lý Trong một số trường hợp chúng ta muốn lưu trữ giá trị biến và truy cập nó cho các request sau này, có thể sử dụng kiểu lưu trữ này

Có ba collection có thể được sử dụng cho mục đích này:

- IP

- SESSION

- USER

Collection IP được sử dụng để lưu trữ thông tin về IP của người sử dụng Nó có thể

được sử dụng để lưu trữ IP ở các trường hợp như: Số lần truy cập không thành công vàotài nguyên trên server, hoặc số lượng các request của người dùng…

Trước khi sử dụng một trong các collection, chúng ta cần khởi tạo nó Điều này được thực hiện bằng cách sử dụng các action initcol:

2.4.1.4 Kiểm tra nhiều biến

ModSecurity có thể kiểm tra nhiều biến cùng một lúc, mục đích để kết hợp so sánh (matching) một chuỗi

Ví dụ:

Code:

SecRule ARGS|REQUEST_HEADERS "park" deny

Dấu (|) được sử dụng để tách các tên biến Nó cũng có nhiều chức năng logic giống như

“or” trong lập trình

2.4.1.5 Sử dụng dấu “ khi viết rule

Chúng ta xem xét các rule sau

Code:

SecRule REQUEST_URI "secret" "deny"

SecRule REQUEST_URI secret deny

SecRule REQUEST_URI "secret place" deny

Hai rule đầu đều đúng và có tác dụng như nhau Dấu (“) được sử dụng để chứa các cụm

từ cách nhau bởi có dấu space Các đơn từ thì có thể dùng hoặc không dùng

Sử dụng (“) còn để nhóm các thông điệp ghi log

SecRule REQUEST_URI "secret place" "deny,log,msg:'Someone\'s trying to hack us!'"

2.4.1.6 Tạo rule kết chuỗi – chain

Để kết hợp nhiều rule hoạt động liên tiếp với nhau, ta sử dụng chain

Ví dụ: Người quản trị web server muốn chặn một số người download nhiều file gây ảnhhưởng đến web server, nhưng một số khách hàng khác cũng download mà không gây ảnh hưởng đến webserver bởi họ chỉ download vài file là xong và ta không chặn những

người này Và người quản trị server quyết định chặn những người có user-agent có chứa “Red Bullet” và IP của người này nằm trong dãy IP của một ISP xác định Với từ chain trong action Sử dụng nó, chúng ta có thể tạo ra một chain rule mà nếu phù hợp tất cả các rule trong chain thì action của chain sẽ được thực hiện

Ví dụ đây là rule cấm người dùng với user-agent có từ “Red Bullet”

Code:

SecRule REQUEST_HEADERS:User-agent “Red Bullet” deny

Rule thứ hai là chỉ những client nằm trong dãy IP 192.168.1.0-192.168.1.255:

SecRule REQUEST_HEADERS:User-agent “Red Bullet” “chain,deny”

SecRule REMOTE_ADDR “^192\.168\.1\.” “chain”

SecRule TIME_HOUR “@lt 18”

Từ @lt viết tắt của “less-than” là nhỏ hơn Thuộc cú pháp so sánh số (matching

number), sẽ được trình bày chi tiết ở phần 2.4.3

Bài gởi: 137Đến từ: TP - HCMOffline

2.4.2.2 Các biểu thức chính quy khác

SecRule REMOTE_HOST "\.microsoft\.com$" deny

Cả hai rule đề có tác dụng như sau là chặn các host truy cập từ xa từ tập đoàn

Microsoft Mục tiêu của @rx mà bỏ qua rule thứ hai bởi hai rule đều có mục đích như

Có 5 giai đoạn (phase)

Một rule được thực hiện đúng từng phase theo thứ tự Điều này có nghĩa là

ModSecurity duyệt tất cả các rule trong phase 1 ("REQUEST_HEADERS") Sau đó, đến phase 2…

Trong mỗi phase, rule được xử lý theo thứ tự mà chúng xuất hiện trong các tập tin cấu hình Chúng ta có thể hiểu khi có action, ModSecurity sẽ duyệt các tập tin năm lần, mộtlần cho từng phase

Trong thời gian xử lý ModSecurity chỉ xem xét rule thuộc pha hiện đang xử lý, và những rule được áp dụng theo thứ tự chúng xuất hiện trong các tập tin cấu hình

Phase LOGGING đặc biệt ở chỗ nó luôn luôn được thực hiện cả khi request đã được cho phép hay từ chối trong các phase trước đó Ngoài ra, một khi phase LOGGING bắt đầu, chúng ta không thể thực hiện bất kỳ action ngăn chặn nào vì response đã được gửi cho người truy cập

Vì vậy, chúng ta phải cẩn thận không để cho bất kỳ action nào trái quy định được truyền vào rule ở phase 5 Nếu không sẽ gây lỗi làm Apache không khởi động được Nếu chúng ta đặt rule sau đây trước các rule thuộc phase 5 sẽ ngăn chặn được lỗi này xảy ra (nhưng phải đặt sau các rule của phase trước đó)

Code:

SecDefaultAction "phase:5,pass"

2.4.5 Chức năng chuyển đổi

ModSecurity cung cấp một số chức năng chuyển đổi mà chúng ta có thể áp dụng cho các biến và các collection Những biến đổi được thực hiện trên một bản sao của dữ liệu được kiểm tra, có nghĩa là các HTTP request hoặc response ban đầu vẫn được giữ nguyên, không thay đổi

Chức năng này rất quan trọng Nếu chúng ta muốn phát hiện tấn công XSS (cross-site scripting), chúng ta phải phát hiện mã JavaScript bất kể trường hợp nó được viết in hay viết thường Để làm điều này, chức năng chuyển đổi có thể được áp dụng để so sánh một chuỗi viết hoa với chuỗi viết thường

Code:

SecRule ARGS "<script" "deny,t:lowercase"

Rule trên sẽ chặn tất cả các URL chứa chuỗi >;<;script bất kể chữ hoa thường, vd sCript; >;<;scripT

Bảng 2.4 Một số chức năng chuyển đổi của ModSecurity 2.4.5.1 Thiết lập so sánh với @pm và @pmFromFile Vd: thay vì sử dụng red|blue|green ta có thể sử dụng

SecRule ARGS "@pm red green blue" deny

Nếu có quá nhiều chuỗi muốn đặt vào, ta có thể liệt kê các chuỗi này vào một file và dùng @pmFromFile

Vd: Trong file /usr/log/alo.txt chứa nội dung red green blue yellow magenta cyan orange maroon pink black white gray grey violet purple brown tan olive Ta có rule:

Code:

SecRule ARGS “@pmFromFile /usr/log/alo.txt”

2.4.6 Khoá một số request thông thường

Giả sử một website khai báo thuế của chính phủ muốn tăng độ bảo mật, website này chỉ

mở cửa vào ban ngày (từ 8 giờ sáng đến 5 giờ chiều) Chúng ta có thể sử dụng biến TIME_HOUR cùng với biểu thức chính quy để thực hiện rule này

Code:

SecRule TIME_HOUR !^(8|9|10|11|1213|14|15|16|17)$ deny

2.4.7 Khoá một số request không thông thường

Ba phương thức (method) HTTP thường được sử dụng cho request là GET, POST và HEAD Chúng ta có thể ngạc nhiên khi biết rằng HTTP thực sự thực có rất nhiều phương thức, nếu một web server hỗ trợ WebDAV (Web-based Distributed Authoring

và Versioning), tổng số method trở nên gần như 30

Ví dụ, ở đây là những phương thức request thực hiện bởi phiên bản mới nhất của Apache: