57
1 MỤC LỤC MỤC LỤC .......................................................................... 1 LỜI MỞ ĐẦU .................................................................... 4 DANH MỤC HÌNH ẢNH ..................................................... 6 DANH MỤC CÁC BẢNG ..................................................... 7 CHƯƠNG I – TỔNG QUAN VỀ GIAO THỨC HTTP ................ 8 1.1.Giới thiệu chung .......................................................... 8 1.1.1. .................................. URI – Uniform Resource Identifiers 8 1.1.2. ................................... Một số phương thức thường dùng: 9 1.2.Thông điệp HTTP ....................................................... 13 1.2.1. .................................................. Cấu trúc thông điệp HTTP 13 1.2.2. .......................................... Các trường trong HTTP header 16 CHƯƠNG II - MODSECURITY.......................................... 18 2.1.Tìm hiểu về ModSecurity ............................................. 18 2.1.1. ........................................................ Khái niệm Modsecurity 18 2.1.2. ......................................... Các khả năng của ModSecurity 18 2.1.3.Quá trình xử lý các request của Apache và ModSecurity 20 2.2.Các luật (Rules) ......................................................... 22 2.2.1. ........................................................ ModSecurity Core Rule 22 2.2.2. ......................................... Cấu hình các chỉ thị (Directive) 23 2.2.3. .................. Biến (Variables ) và bộ chọn lọc (Collection) 26 2.2.4. ......................................................... Chức năng chuyển đổi 29

Mod Security v3

Embed Size (px)

DESCRIPTION

d

Citation preview

Page 1: Mod Security v3

1

MỤC LỤC

MỤC LỤC .......................................................................... 1

LỜI MỞ ĐẦU .................................................................... 4

DANH MỤC HÌNH ẢNH ..................................................... 6

DANH MỤC CÁC BẢNG ..................................................... 7

CHƯƠNG I – TỔNG QUAN VỀ GIAO THỨC HTTP ................ 8

1.1. Giới thiệu chung .......................................................... 8

1.1.1. .................................. URI – Uniform Resource Identifiers 8

1.1.2. ................................... Một số phương thức thường dùng: 9

1.2. Thông điệp HTTP ....................................................... 13

1.2.1. .................................................. Cấu trúc thông điệp HTTP 13

1.2.2. .......................................... Các trường trong HTTP header 16

CHƯƠNG II - MODSECURITY .......................................... 18

2.1. Tìm hiểu về ModSecurity ............................................. 18

2.1.1. ........................................................ Khái niệm Modsecurity 18

2.1.2. ......................................... Các khả năng của ModSecurity 18

2.1.3.Quá trình xử lý các request của Apache và ModSecurity 20

2.2. Các luật (Rules) ......................................................... 22

2.2.1. ........................................................ ModSecurity Core Rule 22

2.2.2. ......................................... Cấu hình các chỉ thị (Directive) 23

2.2.3. .................. Biến (Variables ) và bộ chọn lọc (Collection) 26

2.2.4. ......................................................... Chức năng chuyển đổi 29

Page 2: Mod Security v3

2

2.2.5. ............................................................ Toán tử (Operators) 30

2.2.6. ........................................................... Hành động (Actions) 33

2.3. Logging .................................................................... 35

2.3.1. ............................................................................. Debug Log 35

2.3.2. ......................................................................... Audit logging 36

2.2.3. ......................................................... Tuỳ biến thông tin log 37

2.4. Biểu thức chính quy (Regular expressions) ..................... 37

2.4.1. ..................................... Giới thiệu về biểu thức chính quy 37

2.4.2. .. Ứng dụng của biểu thức chính quy trong Modsecurity 38

2.5. Cài đặt và cấu hình cơ bản ModSecurity trên máy chủ

CentOs .......................................................................... 39

2.5.1. ............................................................ Cài đặt ModSecurity 39

2.5.2. ................................................................... Cấu hình cơ bản 40

2.6. Viết và phân tích một số luật cơ bản ............................. 41

CHƯƠNG III - XÂY DỰNG CHÍNH SÁCH TRÊN

MODSECURITY CHỐNG LẠI MỘT SỐ TẤN CÔNG LÊN ỨNG

DỤNG WEB .................................................................... 44

3.1. Mô hình triển khai ModSecurity và xây dựng kịch bản Demo44

3.1.1. .................................................... Xây dựng kịch bản demo 44

3.2. Xây dựng chính sách trên ModSecurity chống lại một số tấn

công lên ứng dụng Web .................................................... 45

3.2.1. ......................................... Ngăn chặn HTTP Fingerprinting 45

3.2.2. ....................................... Ngăn chặn tấn công Brute Force 47

3.3.3. ............ Ngăn chặn tấn công Cross-Site Scripting (XSS) 48

Page 3: Mod Security v3

3

3.3.4. .................................... Ngăn chặn tấn công SQL injection 52

KẾT LUẬN ...................................................................... 56

TÀI LIỆU THAM KHẢO .................................................... 57

Page 4: Mod Security v3

4

LỜI MỞ ĐẦU

Trong những năm gần đây, Ứng dụng Web phát triển rất mạnh

mẽ, hầu như mọi người ai cũng từng nghe và làm việc trên ứng

dụng web. Website trở nên phổ biến và trở thành một phần quan

trọng của mọi người nhất là các doanh nghiệp, tổ chức. Ứng dụng

Web càng phổ biến thì các cuộc tấn công ứng dụng Web cũng trở

nên hết sức phức tạp. Điều này đặt ra vấn đề về sự cần thiết của

bảo mật ứng dụng web. Nhiều tổ chức, công ty đã xây dựng tường

lửa ứng dụng web để bảo vệ hệ thống máy chủ ứng dụng web như

sản phẩm Imperva, CheckPoint hay ModSecurity. Trong đó Imperva

và Checkpoint là sản phẩm thương mại, còn ModSecurity là một sản

phẩm mã nguồn mở.

Do đó trong đề tài này nhóm em xin thực hiện nghiên cứu triển

khai “Nghiên cứu, triển khai hệ thống ModSecurity ”. Với mục đích xây

dựng nên các chính sách để phòng chống một số tấn công phổ biến

lên ứng dụng Web hiện nay như tấn công HTTP Fingerprinting, tấn

công Brute Force, Cross Site Scripting (XSS), SQL Injection, tấn

công Dos … Trong giới hạn của đề tài này, nhóm em xin trình bày

chuyên đề gồm 3 phần chính, như sau:

Chương 1: Tổng quan về giao thức HTTP

Ở phần này nhóm em xin giới thiệu về URI cũng như một số

phương thức mà HTTP thường dùng, làm rõ được hoạt động của

HTTP và cấu trúc của một thông điệp request / response

Chương 2: ModSecurity

Ở phần này nhóm em xin giới thiệu tổng quan về ModSecurity

cách thức ModSecurity hoạt động cũng như quá trình xử lý request

của Apache và Modsecurity. Đồng thời giới thiệu cú pháp của một

rule và các thành phần trong đó.

Chương 3: Xây dựng chính sách trên ModSecurity chống

lại một số tấn công lên ứng dụng web.

Page 5: Mod Security v3

5

Phần này, nhóm đưa ra một số tập luật nhằm chống lại một số

tấn công lên ứng dụng web phổ biến như XSS, Brute force, SQL

Injection, Dos …

Page 6: Mod Security v3

6

DANH MỤC HÌNH ẢNH

Hình 1- 1 Cơ bản về giao thức HTTP .................................................... 8

Hình 1- 2 Cấu trúc đầy đủ của URI ..................................................... 9

Hình 1- 3 Phương thức GET ............................................................... 10

Hình 1- 4 Web Forms POST ............................................................... 10

Hình 1- 5 Hoạt động POST’ ............................................................... 11

Hình 1- 6 Hoạt động của PUT ............................................................ 11

Hình 1- 7 Hoạt động File Delection – DELETE ...................................... 12

Hình 1- 8 Cấu trúc thông điệp HTTP Resquest ..................................... 14

Hình 1- 9 Một số ví dụ về nội dung thông điệp HTTP ............................ 14

Hình 1- 10 Ví dụ cụ thể về Request-Line ............................................. 15

Hình 1- 11 Cấu trúc thông điệp HTTP Response ................................... 15

Hình 1- 12 Response HTTP................................................................ 16

Hình 1- 13 Cụ thể trường Status-Line ................................................. 16

Hình 1- 14 Ví dụ về HTTP header ....................................................... 16

Hình 2- 1 Mô hình tổng quan ModSecuriy ........................................... 18

Hình 2- 2 Quá trình xử lý các request của Apache và Modsecurity .......... 20

Hình 2- 3 Trước khi cấu hình ModSecurity ........................................... 41

Hình 2- 4 Sau khi cấu hình cơ bản ModSecurity ................................... 41

Hình 3- 1 Mô hình triển khai Modsecurity ............................................ 44

Hình 3- 2 Kết quả tấn công HTTP Fingerprinting .................................. 46

Hình 3- 3 Kết quả ngăn chặn tấn công HTTP Fingerprinting ................... 47

Hình 3- 4 Kết quả ngăn chặn tấn công Brute-force ............................... 48

Hình 3- 5 Kết quả tấn công XSS ........................................................ 49

Hình 3- 6 Kết quả ngăn chặn tấn công XSS ......................................... 51

Hình 3- 7 Kết quả tấn công SQL Injection ........................................... 53

Hình 3- 8 Kêt quả ngăn chặn tấn công SQL Injection ........................... 54

Page 7: Mod Security v3

7

DANH MỤC CÁC BẢNG

Bảng 2- 1 Các loại chỉ thị trong Modsecurity ............................... 24

Bảng 2- 2 Các chức năng chuyển đổi của Modsecurity ................. 30

Bảng 2- 3 Các toán tử String –matching .................................... 31

Bảng 2- 4 Các toán tử hỗ trợ so sánh ........................................ 31

Bảng 2- 5 Các toán tử kiểm tra ................................................. 32

Bảng 2- 6 Toán tử Miscellaneous ............................................... 32

Bảng 3- 1 Các ký tự nên mã hoá để ngăn chặn tấn công XSS ....... 50

Bảng 3- 2 Các lệnh thường được sử dụng trong tấn công SQL

Injection ................................................................................ 53

Page 8: Mod Security v3

8

CHƯƠNG I – TỔNG QUAN VỀ GIAO THỨC HTTP

1.1. Giới thiệu chung

HTTP (Hypertext Transfer Protocol) là giao thức thuộc lớp ứng

dụng trong mô hình tham chiếu OSI. HTTP cho phép giao tiếp giữa

nhiều loại server/client với nhau chủ yếu thông qua bộ giao thức

TCP/IP. Cổng giao tiếp chuẩn là 80, tuy nhiên có thể dùng bất kỳ

cổng khác. Giao tiếp giữa client và server dựa vào một cặp

request/reponse. Client khởi tạo HTTP request và nhận HTTP

response từ server gửi về.

Hình 1- 1 Cơ bản về giao thức HTTP

HTTP request bao gồm 2 thành phần quan trọng là URI và

phương thức được gửi từ client. Ở phía ngược lại, server trả về

HTTP response trong đó chứa mã trạng thái (Status code) và

Message body

1.1.1. URI – Uniform Resource Identifiers

Ta thường quen thuộc với định nghĩa URL (Uniform Resource

Locators). Ví dụ http://www.at7a.kma. Không có nhiều khác biệt

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

một đặc tả kĩ thuật của giao thức HTTP

Page 9: Mod Security v3

9

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

- 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 truy vấn them thông tin về tài nguyên của Client

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

1.1.2. Một số phương thức thường dùng:

- GET

Được sử dụng để Client lấy một đối tượng hoặc tài nguyên nào

đó trên Server. Được chỉ ra trong URI

Ở Hình 1-3, 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. 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

Page 10: Mod Security v3

10

cá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ả ở mục các trạng thái (link tới phần mã trạng thái)

Hình 1- 3 Phương thức GET

- POST

Trong khi GET cho phép một server gửi thông tin đến client, thì

hoạt động của 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 1- 4 Web Forms POST

Page 11: Mod Security v3

11

Hình 1- 5 Hoạt động POST’

Hình 1-5. Hoạt động của POST đơn giản như phương thức 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.

- File Upload – PUT

PUT 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

Hình 1- 6 Hoạt động của PUT

Như hình 1-6 cho thấy, nó hoạt động rất giống với phương thức

POST. Với POST client gửi bao gồm một URI và dữ liệu. Web server

trả về mã trạng thái , tùy 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 PUT, các URI xác định

đối tượng trong đó các server nên đặt dữ liệu

- 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 xóa các đối, tài nguyên từ các server.

Page 12: Mod Security v3

12

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 xóa. Các server đáp ứng

với một mã trạng thái và dữ liệu kèm theo.

Hình 1- 7 Hoạt động File Delection – DELETE

Page 13: Mod Security v3

13

- 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.2. Thông điệp HTTP

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ởi các tiêu đề (header)

khác nhau và phần thân (body) của thông điệp.

1.2.1. Cấu trúc 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.

HTTP Request

Page 14: Mod Security v3

14

Hình 1- 8 Cấu trúc thông điệp HTTP Resquest

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 1-9

cho thấy một thông điệp HTTP dưới dạng văn bản khi

dùng firefox truy cập trang http://at7a.kma 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- 9 Một số ví dụ về nội dung thông điệp HTTP

Hình 1-10 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

Page 15: Mod Security v3

15

Hình 1- 10 Ví dụ cụ thể về Request-Line

Phương thức cụ thể xuất hiện đầu tiên trong Request-Line.

Trong ví dụ trên đây là một phương thức GET. Mục tiêu tiếp theo

trong Request-Line là Request-URI. Request-URI chứa nguồn tài

nguyên cần truy cập. Trong ví dụ trên, Request-URI là (/), chỉ ra

một yêu cầu đối với các nguồn tài nguyên gốc. Phần cuối cùng của

Request-Line là phiên bản HTTP. Như ví dụ trên cho thấy, HTTP

phiên bản 1.1

HTTP Response

Request Resonse bắt đầu bởi Status-Line (dòng mã trạng thái).

Sau đó là phần thông tin của Header và một dòng trắng. Cuối cùng

là phần body

Hình 1- 11 Cấu trúc thông điệp HTTP Response

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

Ví dụ trả về của request HTTP tới http://at7a.kma

Page 16: Mod Security v3

16

Hình 1- 12 Response HTTP

Hình 1- 13 Cụ thể trường Status-Line

1.2.2. Các trường trong HTTP header

Hình 1- 14 Ví dụ về HTTP header

Như chúng ta đã thấy ở các phần trước, HTTP Request và HTTP

Reponse có thể bao gồm một hoặc nhiều thông điệp header.

Message header bắt đầu với một tên trường và dấu hai chấm. 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ẽ

Page 17: Mod Security v3

17

không trình bày. Các bạn có thể tham khảo ở

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

Page 18: Mod Security v3

18

CHƯƠNG II - MODSECURITY

2.1. Tìm hiểu về ModSecurity

2.1.1. Khái niệm Modsecurity

ModSecurity là một open source web application firewall được

Ivan Ristic phát triển dành cho Apache Web Server. Nó được xem là

một bộ máy phát hiện và phòng chống xâm nhập dành cho các ứng

dụng web. Hoạt động như một module của Web Server Apache

hoặc có thể đứng độc lập một mình như một reverse proxy để bảo

vệ nhiều loại webserver như là IIS, Tomcat, Apache.

Hình 2- 1 Mô hình tổng quan ModSecuriy

ModSecurity được sử dụng dưới hai hình thức là Open source

hoặc thương mại với nhiều hỗ trợ từ nhà cung cấp. Nó có thể hoạt

động tốt trên hàng loạt các hệ điều hành như: Linux, Windows,

Solaris, FreeBSD, Mac OS.

2.1.2. Các khả năng của ModSecurity

Lọc các request (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ý

Chống các kỹ thuật tấn công (Anti-evasion techniques): đường

dẫn (paths) và thông số (parameters) được chuẩn hóa trước khi

phân tích để chống các kỹ thuật tấn công.

Hiểu giao thức HTTP (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

Page 19: Mod Security v3

19

đượ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...

Phân tích nội dung của phương thức POST (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.

Tự động ghi log (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.

Lọc giao thức HTTPS (HTTPS filtering): ModSecurity có thể phân

tích HTTPS.

Phân tích những yêu cầu được nén (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.

Page 20: Mod Security v3

20

2.1.3. Quá trình xử lý các request của Apache và

ModSecurity

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:

- Phase Request Header (phase 1): Các luật được đặt tại đây sẽ

được thực hiện ngay sau khi Apache đọc request header (Post-

read-request), lúc này phần request body vẫn chưa được đọc.

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, Local

file include, Cross Site Script (XSS)…

- Phase Request Body (phase 2): Đây là thời điểm các thông tin

chức năng chung đưa vào được phân tích và xem xét, các luật

mang tính ứng dụng hướng kết nối (application-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. Mục đích chung

Page 21: Mod Security v3

21

của phase này là phân tích đầu vào dữ liệu, dịch URI, kiểm tra

header, kiểm tra truy cập, xác thực…

ModSecurity hỗ trợ ba loại mã hoá request body sau:

o Application/x-www-form-urlencoded: Dùng để truyền form

dữ liệu

o Multipart/form-data: Dùng để truyền file

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

- Phase Response Header (phase 3): Đây là thời điểm ngay sau

khi phần response header được gửi trả về cho client. Chúng ta

đặt luật ở đây nếu muốn giám sát quá trình sau khi phần

response được gửi đi.

- Phase Response Body (phase 4): Sau khi ModSecurity đã hoàn

thành việc kiểm tra tại response 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

khá hiệu quả để phát hiện và phòng chống xâm nhập trong

trường hợp 1 và 2 không phát hiện tấn công.

Ví dụ: trong khai thác SQL Injection, nếu hacker cố gắng sử

dụng một số kỹ thuật nhằm ẩn đi 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.

- Phase logging (phase 5): Là thời điểm các hoạt động log được

thực hiện, các luật đặt ở đây sẽ định rõ việc log sẽ như thế nào,

nó sẽ kiểm tra các thông báo lỗi 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.

Một luật được thực đúng từng phase theo thứ tự. Điều này có

nghĩa là ModSecurity sẽ duyệt tất cả các luật trong phase 1, sau đó

đến phase 2, phase 3, phase 4 và cuối cùng là phase 5. Trong mỗi

phase, các luật được xử lí theo thứ tự mà chúng xuất hiện trong các

Page 22: Mod Security v3

22

tập tin cấu hình. Chúng ta có thể hiểu khi có request, ModSecurity

sẽ duyệt các tệp tin năm lần, mỗi lần cho một phase. Trong thời

gian xử lý ModSecurity chỉ xem xét các luật thuộc pha đang xử lý.

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ỳ một hàng động ngăn chặn nào vì khi đó response đã

được gửi cho người truy cập

Vì vậy, cần phải cẩn thận không để cho bất kỳ hành động nào

trái quy định được truyền vào luật ở phase 5. Nếu không sẽ lỗi làm

cho Apache không khởi động được. Để khắc phục điều này ta có thể

đặt luật sau đây trước các luật thuộc phase 5 (nhưng cần phải đặt

sau các luật của phase trước đó)

SecDefaultAction “phase:5,pass”

2.2. Các luật (Rules)

2.2.1. ModSecurity Core Rule

ModSecurity là một tường lửa ứng dụng do vậy bản thân nó mặc

định cũng không có khả năng chống các tấn công nếu không có các

luật đã được cấu hình cẩn thận. Để tận dụng triệt để những tính

năng của Modsecurity, tập đoàn Breach Security đã xây dựng sẵn

một tập luật khá chặt chẽ và đầy đủ, và miễn phí. Khác với hệ

thống phát hiện xâm nhập khác, chỉ dựa trên những dấu hiệu, đặc

điểm cụ thể từ những tấn công trước, các core rule này được cung

cấp sự bảo vệ chung nhất từ những tổn hại chưa được biết tới

thường thấy ở các ứng dụng web. Core rule mới nhất được tìm thấy

tại website của ModSecurity tại website

www.modsecurity.org/projects/rules/

Để cung cấp sự bảo vệ ứng dụng web một cách bao quát, core

rule bao gồm những nội dung sau:

- Bảo vệ luồng dữ liệu HTTP – phát hiện các hành vi vi phạm của

các giao thức HTTP và chính sách sử dụng được định nghĩa

Page 23: Mod Security v3

23

- Phòng chống các tấn công phổ biến vào web server – phát hiện

các tấn công vào ứng dụng web server. Tự động phát hiện – phát

hiện bots, các công cụ dò tìm và các mã độc hại

- Phòng chống Trojan – phát hiện truy cập của Trojan horses

- Các lỗi ẩn – các thông báo từ web server

- Cấu hình luật của ModSecurity bao gồm các thông tin khác nhau

các thiết đặt khác nhau về nhiều nội dung.

- Cấu trúc Core Rule bao gồm chỉ thị, các biến, các hàm chuyển

đổi, các chữ ký (signature) và các hành động (Action) tương ứng

cho phép, không cho phép, ghi log.

- Yêu cầu về logic là phát hiện các cuộc tấn công.

- Thiết đặt chính sách đưa ra hành động xử lý nếu phát hiện ra tấn

công

- Thông tin về các cuộc tấn công

2.2.2. Cấu hình các chỉ thị (Directive)

ModSecurity là một tường lửa ứng dụng thuộc loại rules-based,

nghĩa là người quản trị cần thiết lập các luật. Khi ModSecurity chạy

sẽ căn cứ vào luật này để thực hiện các yêu cầu, đảm bảo cho hệ

thống được an toàn. Các luật này được thể hiện dưới dạng các

directives (chỉ thị) và có thể đặt trực tiếp trong file cấu hình Apache

(thông thường là httpd.conf).

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.

Directive Description

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

Page 24: Mod Security v3

24

marker creates a rule that does nothing,

but has an ID assigned to it.

SecRule Creates a rule.

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 regular

expression.

SecRuleScript Creates a rule implemented using Lua.

SecRuleUpdateActionById Updates the action list of the rule with

the given ID.

Bảng 2- 1 Các loại chỉ thị trong Modsecurity

Các chỉ thị này đóng vai trò rất quan trọng trong các luật. Tương

ứng với mỗi yêu cầu cần thiết cho một luật là các chỉ thị tương ứng

được sử dụng. Một trong số chỉ thị được dùng rất nhiều là SecRule,

SecAction, SecRuleEngine. Các request sẽ bị từ chối nếu phạm vào

một trong các chị thị này như request phạm vào giao thức HTTP,

các request có nội dung bất thường. Những luật này, cùng với các

file core rule không nên đặt cùng file cấu hình http.conf của

Apache. Điều này sẽ làm cho việc nâng cấp dễ hơn vì những file

core rule mới đều được công ty Breach Security public ở trang web

của ModSecurity.Dưới đây là một số các chỉ thị quan trọng.

SecRuleEngine

Mặc định thì trong filtering engine bị disable. Để kích hoạt

ModSecurity ta cần thêm chỉ thị sau vào file cấu hình.

SecRuleEngine On

Chỉ thị này dùng để điều khiền filter engine, người quản trị có

thể thiết đặt các tùy chọn là On, Off hoặc DynamicOnly.

On: Các luật của ModSecurity được áp dụng cho tất cả các nội

dung

Page 25: Mod Security v3

25

Off: Vô hiệu hóa Modsecurity

DynamicOnly: Các luật của ModSecurity không được áp dụng

cho nội dung tĩnh (static content) như các file.html mà chỉ áp dụng

cho các request trả về nội dung động như request đến các file php…

SecAction

Mô tả: Sec Action sẽ xử lý vô điều kiện danh sách các hành động

mà nó nhận được như tham số đầu tiên và duy nhất. Nó chấp nhận

một tham số, cú pháp của tham số này giống tham số thứ ba của

SecRule.

Cú pháp: SecAction action1, action2, action3

Ví dụ: SecAction "log,deny,msg:'chan truy cap'"

SecAction sử dụng tốt nhất khi thực thi một hành động vô điều

kiện. Bình thường các hành dộng này được kích hoạt có điều kiện cơ

bản trên dữ liệu yêu cầu và trả lời (request/reponse)

SecRule

Mô tả: SecRule là chỉ thị chính của Modsecurity. Nó được sử

dụng để phân tích dữ liệu và thực hiện các hành động cơ bản và

đưa ra kết quả.

Cấu trúc chuẩn của một luật trong ModSecurity như sau:

SecRule VARIABLES OPERATOR [ACTION]

Ví dụ: SecRule ARGS “<script>”

log,deny,status:404

- 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

toán tử được dùng theo dạng biểu thức chính quy nhằm tạo nên

cơ chế phân tích linh động cho các luật

ACTION: 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,

Page 26: Mod Security v3

26

deny, status:404 có nghĩa là khi trùng mẫu <script> trong gói tin

thì thực hiện gi log, chặn gói tin bằng các sử dụng mã trạng thái

404 (Not found).

Ví dụ: dưới đây là một HTTP request

GET /document/index.html HTTP/1.1

Host=www.kmasecurity.net

User-Agent=Mozilla/5.0 (Windows NT 6.1; rv:25.0) Gecko/20100101

Firefox/25.0

Accept=text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.

8

Accept-Language=vi-vn,vi;q=0.8,en-us;q=0.5,en;q=0.3

Accept-Encoding=gzip, deflate

Content-Type=application/x-www-form-urlencoded; charset=UTF-8

Referer=http://www.kmasecurity.net/xforce/index.php

Content-Length=20

Cookie=xf_session=9e9b13d4955a3e03f46d173e5bc02935

POSTDATA=rndval=1386222108554

Từ request ở trên thấy các HTTP Header như là: GET, Host,

User-Agent, Accept, Referer, Content – Length, Cookie, POSTDATA

Chẳng hạn ta viết rules để cấm các request có chức từ “admin”

SecRule REQUEST_URI "admin" "phase:2,deny,log,msg:'khu vuc

cam truy cap'"

Hay không cho phép User-Agent có từ Mozilla

SecRule HTTP_User-Agent "Mozilla"

"phase:1,deny,log,msg:'deny mozilla'"

2.2.3. Biến (Variables ) và bộ chọn lọc (Collection)

Hiện nay có khoảng hơn 70 biến có sẵn trong ModSecurity.

ModSecurity sử dụng 2 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ề Collection là REQUEST_HEADERS, trong đó

chứa tất cả các trường 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.

Page 27: Mod Security v3

27

Để 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 tùy chọn mà chúng ta muốn truy cập. ví dụ:

SecRule REQUEST_HEADERS:User-agent "hacker"

"log,deny,status:404"

Với trường hợp trên ta chỉ có thể kiểm tra dữ liệu trên trường

User-agent. Để có thể kiểm tra toàn bộ dữ liệu trên tất cả các

collection ta sử dụng biên ARGS. Ví dụ ta muốn kiểm tra sự hiện

diện của chuỗi hacker trên tất cả collection ta sử dụng luật sau:

SecRule ARGS “hacker” “log,deny,status:404”

Dưới đây là một số biến và collection được hỗ trợ:

HTTP: Biến này là một tiền tố đặc biệt đi theo sau phần đầu của

header và có thể được sử dụng để chặn truy cập vào các request

header. Ví dụ:

SecRule HTTP_referer "at7a.kma/index.php"

"phase:2,deny,nolog,status:404"

ARGS: ARGS giống như QUERY_STRING | POST_PAYLOAT là

URI phía sau dấu ? Ví dụ:

/index.php?i=10 thì QUERY_STRING là i=10

REMOTE_HOST: Nếu HostnameLookUps được thiết lập là On,

thì biến này sẽ nắm giữ tên host remote được phân giải bởi DNS.

Nếu nó được thiết lập Off thì nó sẽ giữ các địa chỉ IP. Có thể sử

dụng các biến này để từ chối các client nguy hiểm, các mạng đã

đưa vào blacklist, hoặc ngược lại cho phép xác thực các host.

- REMOTE_PORT: Biến này chứa thông tin về cổng nguồn mà

client đã sử dụng khi bắt đầu cho kết nối đến Web Server.

- ARGS_COMBINED_SIZE: Biến này cho phép biết thêm nhiều

kết luận về giá trị trên tổng dung lượng của các đối số, so với

bình thường thì chỉ thị cuả Apache là có giới hạn.

- ARGS_NAMES: là một tập hợp các đối số. Có thể tìm kiếm, cụ

thể tên đối số mà người quản trị muốn cấm. Trong một kịch bản

Page 28: Mod Security v3

28

với chính sách rõ ràng, người quản lý có thể thiết lập một danh

sách trắng.

- AUTH_TYPE: Biến này chứa các phương pháp xác thực được sử

dụng để xác nhận tính hợp lệ của người sử dụng. Ví dụ:

SecRule AUTH_TYPE "basic" log,deny,phase:1

- FILES: Chứa một tập hợp các tên tập hợp các tập tin ban đầu.

Chú ý: Chỉ sẵn sàng khi các file được trích từ request body. Ví

dụ:

SecRule FILES "\.conf$" log,deny,status:404,phase:2

- FILES_COMBINED_SIZE: Giá trị đơn. Tổng dung lượng của 1

file upload. Chú ý: Chỉ sẵn sàng khi các file được trích xuất từ

request body.

- QUERY_STRING: Biến này chứa sữ liệu mẫu thông qua

script/header bằng cách nối thêm dữ liệu vào sau câu hỏi đã

được đánh dấu. Ví dụ:

SecRule QUERY_STRING "or" "phase:1,log,deny,status:403"

- REMOTE_ADDR: Biến này chứa các địa chỉ IP của các client từ

xa. Ví dụ:

SecRule REMOTE_ADDR "^192\.168\.1\.15$" "deny"

- REMOTE_USER: Biến này giữ các tên người sử dụng xác thực.

- REQBODY_PROCESSOR: Xây dựng xử lý các URL đã được mã

hóa MULTIPART và XML.

- REQBODY_PROCESSOR_ERROR: 0 (no error) hoặc 1 (error)

Nếu người quản lý muốn quá trình xử lý một lỗi phải đặt luật này

trong phase 2. Ví dụ:

SecRule REQBODY_PROCESSOR_ERROR "@eq 1"

deny,log,phase:2

- REQUEST_BASENAME: Biến này chỉ là một phần của tập tin

tên REQUEST_FILENAME. Ví dụ:

SecRule REQUEST_BASENAME "^login\.php$"

"allow,log,msg:'dang nhap',phase:2"

Page 29: Mod Security v3

29

- REQUEST_BODY: Biến này chứa dữ liệu trong request body (

Bao gồm cả POST_PAYLOAD data). REQUEST_BODY nên được sử

dụng. Ví dụ:

SecRule REQUEST_BODY

"^username=\w{25,}\&password=\w{6,}\&Login= Login$"

"phase:2,log,deny,msg:'truy cap tu choi'"

- REQUEST_COOKIES: biến này bao gồm tập hợp tất cả dữ liệu

cookie. Ví dụ:

SecRule REQUEST_COOKIES "@eq 1" "phase:2,deny,log"

- REQUEST_COOKIES-NAME: Biến này là tập hợp các tên Cookie

trong các request header.

SecRule REQUEST_COOKIES_NAMES:PHPSESSID "@eq 1"

"phase:2,deny"

2.2.4. 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, 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. Ví dụ:

SecRule ARGS “<script>” “deny,t:lowercase”

Luật trên sẽ chặn tất cả các URL chứa chuỗi >, <, script bất kể chữ

hoa hay thường sCript, ScRipt, SCRIPT…

Các chức năng chuyển đổi của ModSecurity như sau

Chức năng chuyển

đổi

Mô tả

Base64Encode Mã hóa chuỗi sang base64

Page 30: Mod Security v3

30

Base6Decode Giải mã từ base64

compressWhitespace Chuyển tab, dòng mới, space, và nhiều space

liên tiếp sang một dấu space

cssDecode Giải mã ký tự CSS

escapeSeqDecode Giải mã ANSI C escape sequences

(\n,\r,\\,\?,\”” …)

hexEncode Mã hóa chuỗi bằng cách sử dụng mã Hex

hexDecode Giải mã chuỗi hex

htmlEntityDecode Giải mã HTML (ví dụ: chuyển &lt thành <)

jsDecode Giải mã JavaScript escape sequences

Length Chuyển một chuỗi thành độ dài của chuỗi đó

Lowercase Chuyển chuỗi sang tất cả ký tự thường

Md5 Chuyển ký tự nhập vào sang MD5

urlDecode Giải mã một chuỗi URL

urlDecodeUni Giống urlDecode, nhưng xử lý được mã hóa

kiểu ký tự Unicode

Bảng 2- 2 Các chức năng chuyển đổi của Modsecurity

2.2.5. Toán tử (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 biểu thức chính quy cho việc phân tích, nhưng trong một

số trường hợp cụ thể thì các phân tính 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ố thì việc sử dụng

biểu thức chính quy 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 hợp này thì này việc sử dụng các toán tử về số học sẽ hiệu

quả hơn so với biểu thức chính quy.

ModSecurity hỗ trợ 4 nhóm sau:

Page 31: Mod Security v3

31

Toán tử String – matching: toán tử này dùng phân tích các dữ

liệu đầ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.

Operator Description

@begins With Input begins with parameter

@contains Input contains parameter

@ends With Input ends with parameter

@rx Regular patterns match in input

@pm Parallel patterns matching, with patterns read

from a file

Bảng 2- 3 Các toán tử String –matching

Toán tử Numerical: Các toán tử hỗ trợ so sánh các giá trị số

Operator Description

@eq Equal

@ge Greater or equal

@gt Greater than

@le Less or equal

@lt Less than

Bảng 2- 4 Các toán tử hỗ trợ so sánh

Page 32: Mod Security v3

32

- Toán tử Validation: Các toán tử kiểm tra mà ModSecurity hỗ trợ

được liệt kê sau

Operator Description

@validateByteRange Validates that parameter consists only of

allowed byte values

@validateSchema Vallidates XML payload against a schema

@validateDTD Validates XML payload against a DTD

@validateUrlEncoding Validates an URL-encoder string

@validateUtf8Encoding Validates an UTF-8-encoded string

Bảng 2- 5 Các toán tử kiểm tra

Toán tử Miscellaneous: toán tử này 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)

Operator Description

@geoLookup Determines the physical location of an IP address

@inspectFile Nvokes an external script to inspect a file

@rbl Looks up the parameter against a RBL (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 wherther the parameter is a valid US social

security number

@ipMatch Matches input against one or more IP addresses or

network segment

Bảng 2- 6 Toán tử Miscellaneous

Page 33: Mod Security v3

33

2.2.6. Hành động (Actions)

Khi request vi phạm một luật nào đó thì ModSecurity sẽ thực thi

một hành động (action). Khi action không được chỉ rõ trong luật thì

luật đó sẽ sử dụng default action. Có 3 loại actions:

Primary Actions

Primary Actions sẽ quyết định cho phép request tiếp tục hay

không. Mỗi luật chỉ có một Primary Actions. Có 5 Primary Actions :

- Deny: Request sẽ bị ngắt, ModSecurity sẽ trả về HTTP status

code 500 hoặc là status code của người quản trị thiết lập chỉ thị

status. Ví dụ:

SecRule REQUEST_URI “hacker” “deny,status:403”

- Pass: Cho phép request tiếp tục được xử lý ở các luật tiếp theo.

Ví dụ:

SecRule secret “log,pass”

- Allow: Cho phép truy cập ngay lập tức và bỏ qua các phase khác

(trừ pha logging). Nếu muốn chỉ cho qua phase hiện tại thì cần

chỉ rõ allow phase. Khi đó sẽ vẫn được kiểm tra bởi các luật tại

các phase sau. Chỉ cho phép truy cập tới các request. Ví dụ:

SecRule REMOTE_ADDR "^192\.168\.1\.15$" "allow"

- Redirect: Redirect một request đến một url nào đó. Ví dụ:

SecRule ARGS “<script>” Redirect:/noxss.html

- Drop: Ngay lập tức kết nối, hành động dừng một kết nối TCP và

gửi một gói FIN

Secondary Actions

Secondary Actions sẽ bổ sung cho Primary Actions, một luật có

thể có nhiều Secondary Actions.

- Status: Khi một Request vi phạm một luật nào đó thì

ModSecurity có thể trả về các HTTP status code n thay vì status

code 500 mặc định. Người quản trị có thể tạo riêng một trang trả

lời với status code, khi request vi phạm các luật.

Page 34: Mod Security v3

34

- Exec: Thực thi một lệnh nào đó nếu một request vi phạm

- Log: Ghi nhận những request vi phạm luật

- Nolog: Không ghi log

- Pause: ModSecurity sẽ đợi một thời gian n (mili giây) rồi mới trả

về kết quả

Flow Actions

- Chain: Kết nối 2 hay nhiều luật lại với nhau

- Skipnext: ModSecurity sẽ bỏ qua n luật theo sau nó

Default Action

Khi một luật không chỉ rõ action thì luật đó sẽ dùng default

action được thiết lập trong SecDefaultAction.

Giả sử, sau khi thực hiện cấu hình trong tập tin

Modsecurity.conf, 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 như sau:

SecRule REQUEST_BASENAME "^login\.php$"

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

SecRule REQUEST_BASENAME "^login\.php$"

“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 chỉ định một action lặp đi lặp lại nhiều lần

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

SecRule ARGS “X1”

SecRule ARGS “X2”

SecRule ARGS “Xn”

Page 35: Mod Security v3

35

2.3. Logging

2.3.1. Debug Log

Sử dụng chỉ thị SecDebugLog lựa chọn file để ghi lại các thông

tin debug:

SecDebugLog logs/modsec_debug_log

Người quản trị có thể thay đổi mức độ chi tiết các thông tin được

log thông qua chỉ thị:

SevDebuglevel 9

Giá trị log có thể thay đổi từ 0-9:

0 – không ghi log.

1 –Chỉ liệt kê các request bị chặn.

2 –Cảnh báo.

3 – Thông báo cho admin

4 – Chi tiết về các transaction được xử lý.

5 - Cũng giống như 4, nhưng nó đưa ra thông tin log chi tiết

hơn

9 – Ghi lại mọi thứ, rất chi tiết và đầy đủ về toàn bộ thông tin.

Page 36: Mod Security v3

36

Ví dụ:

[11/Dec/2013:23:36:22 --0800] [at7a.kma/sid#f0cfa0][rid#b6972c18]

[/vulnerabilities/csrf/] [1] Access denied with code 403 (phase 2). Match

of "rx ^192\\.168\\.1\\.16" against "REMOTE_ADDR" required. [file

"/etc/httpd/conf.d/Modsecurity.conf"] [line "104"]

2.3.2. Audit logging

Apache log ít thông tin vì thế nó không cho phép người quản trị

có thể lần ngược các bước của kẻ tấn công. ModSecurity hỗ trợ

audit logging với đầy đủ thông tin và từ đó có thể lần ngược lại quá

trình của kẻ tấn công, cũng như là chỉnh sửa các luật cho hợp lý

tránh bị “false positive”. Có 2 directives:

- SecAuditEngine On

- SecAuditlog logs/audit_log

Ví dụ về Audit log:

--e2456e72-A--

[11/Dec/2013:23:36:22 --0800] UqlndsCoAWMAADUbGHEAAAAA

192.168.1.15 54625 at7a.kma 80

--e2456e72-B--

GET /vulnerabilities/csrf/ HTTP/1.1

Host: at7a.kma

User-Agent: hacker (Windows NT 6.1; rv:25.0) Gecko/20100101

Firefox/25.0

Accept:

text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8

Accept-Language: vi-vn,vi;q=0.8,en-us;q=0.5,en;q=0.3

Accept-Encoding: gzip, deflate

Referer: http://at7a.kma/vulnerabilities/sqli/

Cookie: PHPSESSID=ssj74gomhhnbaeg88eabnu3t50; security=high

Connection: keep-alive

--e2456e72-F--

HTTP/1.1 403 Forbidden

Content-Length: 301

Connection: close

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

--e2456e72-H--

Page 37: Mod Security v3

37

Message: Access denied with code 403 (phase 2). Match of "rx

^192\\.168\\.1\\.16" against "REMOTE_ADDR" required. [file

"/etc/httpd/conf.d/Modsecurity.conf"] [line "104"]

Action: Intercepted (phase 2)

Stopwatch: 1386833782214868 4718 (2035 2927 -)

Producer: ModSecurity for Apache/2.5.12 (http://www.modsecurity.org/).

Server: Apache/2.2.15 (CentOS)

2.2.3. Tuỳ biến thông tin log

SecAuditEngine chấp nhận 4 giá trị sau:

- On – log tất cả các request

- Off – không ghi log

- RelevantOnly – chỉ log những gì được sinh ra bởi các filtering

rules

- DynamicOrRelevanl – log những request tạo ra nội dung hoặc

những request được sinh ra bởi các filtering rules.

2.4. Biểu thức chính quy (Regular expressions)

2.4.1. Giới thiệu về biểu thức chính quy

Biểu thức chính quy (regular expression) là một biểu thức mà nó

sẽ đại diện cho một tập hợp các chuỗi ký tự, theo những quy tắc cú

pháp nhất định. Nó thường được dùng trong các trình biên tập văn

bản và các tiện ích tìm kiếm và xử lý văn bản dựa trên các mẫu

được quy định. Nhiều ngôn ngữ lập trình cũng hỗ trợ biểu thức

chính quy trong việc xử lý chuỗi, chẳng hạn như Perl có bộ máy

mạnh mẽ để xử lý biểu thức chính quy được xây dựng trực tiếp

trong cú pháp của chúng

Cơ bản biểu thức chính quy có 5 loại sau:

- Ký hiệu (sysbol): Dùng để diễn đạt một thành ngữ chỉ chứa duy

nhất ký tự đó mà thôi. Thể loại này thường được dùng để diễn

đạt những chữ viết thường hay một nhóm chữ đã được xác định.

Page 38: Mod Security v3

38

Ví dụ: biểu thức chính quy “a” diễn tả thành ngữ chỉ chứa một

chữ cái là “a”. hay biểu thức chính quy “abc” diễn tả thành ngữ

chứa “abc”

- Thay thế (Alternation): Dùng để diễn đạt tính cái này hoặc cái

kia (OR). Ký tự | được dùng để diễn tả thay

Ví dụ: Giả sử biểu thức chính quy A nhận ký tự a và biểu thức

chính quy B nhận ký tự b, thì thay thế thế của A và B hay A | B sẽ

là một biểu thức chính quy mới và nhận a hoặc b. Viết ngắn gọn A |

B mô tả thành ngữ {“a”,”b”}

- Kết hợp (Concatenation): Dùng để diễn đạt tính chất AND. Dấu

chấm (.) được dùng để diễn tả AND

Ví dụ: Giả sử A and B là 2 biểu thức chính quy, thì kết hợp của A

và B hay là A.B. Ở đây kết hợp là dấu chấm (.). Nếu biểu thức

chính quy A nhận ký tự a và biểu thức chính quy B nhận ký tự b, thì

kết hợp của A và B hay A.B sẽ là một biểu thức chính quy mới nhận

a và b

- Epsilon: Dùng để diễn đạt chuỗi kí tự trống. dấu €(epsilon) được

dung để diễn tả chuỗi kí tự trống

Ví dụ: (“ab” | e) mô tả thành ngữ (“”,”ab”)

- Lặp đi lặp lại (Repetition): Dùng để diễn đạt sự lặp đi lặp lại của

ký tự. Có vài dấu hiệu dùng để diễn tả sự lặp lại

2.4.2. Ứng dụng của biểu thức chính quy trong

Modsecurity

Qua trên ta thấy được việc sử dụng biểu thức chính quy trong

việc lập trình và đặc biệt là ứng dụng vào việc thiết lập các luật cho

ModSecurity là rất hữu ích. Biểu thức chính quy giúp cho việc tối ưu

hóa các luật một cách đơn giản nhất mà vẫn đảm bảo được khả

năng kiểm tra luồng dữ liệu. Bình thường dựa vào các mẫu không

phải là biểu thức chính quy thì số ký tự sẽ phải đầy đủ, do đó độ dài

của một luật sẽ lớn. Dẫn tới việc xử lý sẽ chậm đi rất nhiều.

Page 39: Mod Security v3

39

2.5. Cài đặt và cấu hình cơ bản ModSecurity trên máy chủ

CentOs

2.5.1. Cài đặt ModSecurity

Trước khi cài đặt, chúng ta cần phải đảm bảo Web Server

Apache đã hoạt động tốt. ModSecurity hiện nay có thể cài đặt trên

nhiều hệ điều hành, sau đây nhóm em xin giới thiệu về cách cài đặt

ModSecurity trên máy chủ CentOS (6.5).

Download ModSecurity tại website:

https://www.modsecurity.org/tarball/2.5.12/modsecurity-

apache_2.5.12.tar.gz

- Các thư viện cần thiết cho việc cài đặt ModSecurity: apxs,

libxml2, pcre và cần file mod_unique_id.so

[root@webserver ~]# yum -y install http-devel (cài đặt apxs)

[root@webserver ~]#yum –y install libxml2-devel (cài đặt

libxml2)

[root@webserver ~]#yum -y install pcre-devel(cài đặt pcre)

- Thêm dòng sau vào file http.conf (/etc/http/conf/http.conf) dòng

sau:

LoadModule unique_id_module module/mod_unique_id.so

- Giải nén tập tin

[root@webserver ~]#tar xfvz modsecurity-apache_2.5.12.tar.gz

- Cài đặt ModSecurity

[root@webserver ~]#cd modsecurity-apache_2.5.12/apache2

[root@webserver apache2]# ./configure

[root@webserver apache2]# make

[root@webserver apache2]# make install

- Tích hợp Modesecurity với Apache

Page 40: Mod Security v3

40

Sau khi cài đặt thành công tập tin mod_security2.so sẽ được tạo

trong thư mục /etc/httpd/modules/. Tiếp tục ta cần thêm vào file

httpd.conf để thực hiện load module ModSecurity bằng các thêm

dòng sau và restart lại dịch vụ httpd

LoadModule security2_module modules/mod_security2.so

[root@webserver ~]#service httpd restart

2.5.2. Cấu hình cơ bản

ModSecurity là một tường lửa ứng dụng thuộc loại rules-based,

chúng ta cần phải thiết lập các luật để ModSecurity hoạt động. Các

rules này được thể hiện dưới dạng các đường dẫn (directive) và có

thể đặt trực tiếp trong tập tin cấu hình Apache (httpd.conf). Ngoài

ra ta có thể đặt các cấu hình này vào một tập tin riêng bằng cách

copy file modsecurity.conf-minimal vào thư mục conf.d và đổi tên

thành Modsecurity.conf :

cp modsecurity.conf-minimal /etc/httpd/conf.d/Modsecurity.conf

Tiếp theo ta cần thêm vào tập tin httpd.conf

Include conf.d/Modsecurity.conf

Theo mặc định thì rule engine bị disable. Để kích hoạt

ModSecurity ta cần thêm các chỉ thị sau vào file cấu hình

SecRuleEngine On

Để kiểm tra hoạt động của ModSecurity ta xây dựng một kịch

bản như sau: Tiến hành tạo hai file trong thư mục web

(Attacker.html và index.html). 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 403

Page 41: Mod Security v3

41

Hình 2- 3 Trước khi cấu hình ModSecurity

Hình trên cho ta thấy khi chưa cấu hình ModSecurity để chặn các

request có chứa từ Attacker thì người dùng vẫn truy cập 2 trang

web bình thường. Tiến hành kiểm tra bằng cách thêm rule sau vào

file Modsecurity.conf sau đó khởi động lại Apache và kiểm tra kết

quả:

#xây dựng rule thử nghiệm block tất cả request có uri chứa “Hacker”

SecRule REQUEST_URI “hacker” “phase:2,deny,log,status:403”

Hình 2- 4 Sau khi cấu hình cơ bản ModSecurity

Kết quả hình trên cho ta thấy ModSecurity đã hoạt động. Khi

người dùng truy cập tới http://at7a.kma/hacker.html đã bị chặn bởi

ModSecurity và đưa ra thông báo lỗi.

2.6. Viết và phân tích một số luật cơ bản

Ví dụ 1: cấm các request có chưa từ “script”

SecRule REQUEST_URI "script" "phase:2,deny,status:404"

Page 42: Mod Security v3

42

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. Nếu như chuỗi “script” xuất hiện trong

URI thì các hành động (action) được thực hiện. Trong trường hợp

này, ta sử dụng 2 hành động là deny và status để cấm các truy cập

đấy tới server và đưa ra thông báo mã trạng thái lỗi 404 (Not

found).

Chú ý: 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

Liên kết các luật (chain) và Sử dụng toán tử phủ định

ModSecurity cho phép liên kết các SecRule riêng lẽ với nhau

thành một SecRule duy nhất thông qua từ khóa “chain”. Liên kết

này sẽ giảm thiểu các tình huống cảnh báo không chính xác, giúp

đơn giản hóa việc viết luật trong trường hợp cần kiểm tra các điều

kiện mang tính tuần tự. Ngoài ra ModSecurity còn cho phép sử

dụng phương pháp phủ định một thành phần bất kỳ trong rule.

Ví dụ 2: Người quản trị web server muốn chặn tất cả người

dùng truy cập có User-Agent là “hacker” , Trừ địa chỉ IP

192.168.1.15 là được truy cập ta viết như sau:

SecRule HTTP_User-Agent "hacker" "chain,deny"

SecRule REMOTE_ADDR "!^192\.168\.1\.15"

Trong ví dụ trên ta sử dụng “chain” để liên kết 2 luật với nhau.

Luật thứ nhất ta sử dụng biến HTTP_User-Agent để lọc User-Agent

có tên là “hacker”. Và thực hiện hành động deny để chặn truy cập

nếu User-Agent đó là hacker. Luật thứ 2 sử dụng biến

REMOTE_ADDR để chỉ định ra địa chỉ IP và ở trường hợp này là

192.168.1.15. Sử dụng dấu (!) ở đây có chức năng phủ định lại luật

trên. Giả sử như ở luật thứ 2 ta không sử dụng dấu chấm than (!)

thì 2 luật đấy sẽ có ý nghĩa là User-Agent là “hacker” từ địa chỉ IP

192.168.1.15. Còn khi ta sử dụng dấu chấm than (!) ở luật thứ 2

khi đó địa chỉ IP 192.168.1.15 nếu có User-agent là “hacker” sẽ

Page 43: Mod Security v3

43

vẫn được truy cập tới server, còn lại các địa chỉ IP khác nếu có

User-Agent là “hacker ” sẽ bị cấm

Ví dụ 3: Khi hacker sử dụng kỹ thuật biến đổi dữ liệu nhằm thực

hiện câu truy vấn trong tấn công SQL Injection như sau

“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. Ví dụ ta sử dụng luật sau:

SecRule ARGS "@contains union select " "phase:2,t:lowercase,

t:compressWhitespace,deny,status:404"

Ở luật trên ta đưa ra chuỗi “union select” đây 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 ưu hơn ta sử dụng toán tử

@contains. Khi sử dụng các hành động như lowercase,

compressWhitespace ModSecurity sẽ thực hiện lọc các tự khóa có

dạng sau:

union select

uNioN SeLect

UNION SELECT

Page 44: Mod Security v3

44

CHƯƠNG III - XÂY DỰNG CHÍNH SÁCH TRÊN

MODSECURITY CHỐNG LẠI MỘT SỐ TẤN CÔNG LÊN

ỨNG DỤNG WEB

3.1. Mô hình triển khai ModSecurity và xây dựng kịch bản

Demo

Hình 3- 1 Mô hình triển khai Modsecurity

Trong mô hình triển khai gồm có:

Máy chủ Web Apache có IP private 10.0.0.11 sử dụng hệ điều

hành CentOS 6.5 cài đặt Apache Server, và cài đặt ứng dụng Damn

Vulnerable Web App (DVWA) – đây là ứng dụng tạo các lỗ hổng

web phổ biến phục vụ cho việc demo tấn công. Và tại Web Server

được cài đặt ModSecurity để bảo vệ các tấn công lên ứng dụng web.

Gatewall Firewall dùng để chia sẻ Web Server ra ngoài ở đây sử

dụng tường lửa pfSense ( đây là một giải pháp mã nguồn mở dùng

để bảo vệ mạng bên trong, định tuyến, lọc gói tin, …) trong mô

hình này pfSense được sử dụng với mục đích định tuyến là chính,

còn các chức năng firewall bị vô hiệu hóa. Gateway có 2 card mạng

card bên trong có địa chỉ 10.0.0.1 và địa chỉ dùng để public web

server ra ngoài internet có IP 192.168.234.123

Attacker có thể là 1 người nào đó trên internet. Attacker sẽ dùng

các kĩ thuật để khai thác lỗ hổng và tấn công lên máy chủ Web

3.1.1. Xây dựng kịch bản demo

Attacker sử dụng các kỹ năng để thực hiện tấn công lên ứng

dụng ở máy chủ Web để xem khả năng chống trả của Web Server.

Đầu tiên Attacker sử dụng công cụ để thực hiện HTTP FingerPrinting

nhằm khai thác thông tin về Web Server sau đó Attacker sẽ thực

Page 45: Mod Security v3

45

hiện phân tích các lỗ hổng có thể trên website, Attacker thực hiện

các cuộc tấn công như HTTP Fingerprinting, Brute Force, SQL

Injection, XSS, Dos.

Về phía người quản trị sau khi phát hiện website đặt trên máy

chủ Web bị tấn công. Để khắc phục những điểm yếu đó người quản

trị đã cài đặt ModSecurity và tiến hành thiết lập các Luật (Rule) để

ngăn chặn các cuộc tấn công tương tự có thể xảy ra sau này.

3.2. Xây dựng chính sách trên ModSecurity chống lại một số

tấn công lên ứng dụng Web

3.2.1. Ngăn chặn HTTP Fingerprinting

HTTP Fingerprinting hoạt động bằng cách gửi các request tới

web server và kiểm tra các đặc tính riêng của web server bằng các

response trả về khi thăm dò được và lấy các thông tin thu thập

được đem so sánh với một cơ sở dữ liệu về thông tin cho các web

server được biết đến để xác định tên web server và phiên bản mà

nó đang chạy. Có nhiều cách để các phần mềm HTTP Fingerprinting

có thể phát hiện phiên bản của web server đang chạy trên hệ

thống. Sau đây là một số phương pháp phổ biến sau:

- Server banner: là một chuỗi trả về bởi server trong response

header (ví dụ: Server: Apache/2.2.15 (CentOS)) mang thông tin

của phần mềm chạy web server cũng như hệ điều hành của

server đó.

- Các response của giao thức HTTP: để lấy được thông tin web

server, có thể sử dụng các request phi tiêu chuẩn (non -

standard) hoặc request bất thường để web server gửi về các

response kèm theo thông tin về server cần thu thập. Các request

có thể sử dụng để lấy thông tin từ web server như:

Request HTTP DELETE không hợp lệ

Request sai phiên bản HTTP

Request sai giao thức

Page 46: Mod Security v3

46

- Xây dựng chính sách trên ModSecurity để phòng chống tấn công

HTTP Fingerprinting

- Ý tưởng: Sử dụng ModSecurity để tùy chỉnh các thông số của

web server để đánh lừa công cụ HTTP Fingerprinting nhằm cung

cấp một thông tin sai lệch cho Attacker. Cụ thể như sau:

Chỉ cho phép các phương thức GET, POST và HEAD

Chặn các request với các giao thức ngoại trừ giao thức

HTTP 1.0 và 1.1

Chặn các request không chưa Host header

Đổi thông tin server thành Microsoft-IIS/6.0

- Thực hiện tấn công trước khi viết luật ngăn chặn tấn công

Sử dụng công cụ httprecon để thực hiện tấn công server

at7a.kma

Kết quả trả về cho ta thấy máy chủ sử dụng Apache phiên

bản 2.2.15 và sử dụng hệ điều hành CentOS:

Hình 3- 2 Kết quả tấn công HTTP Fingerprinting

- Sau khi phát hiện tấn công, dựa vào ý tưởng phân tích trên

xây dựng tập luật

# Chỉ cho phép GET,POST và HEADvà phiên bản HTTP 1.0,1.1

SecRule REQUEST_METHOD !^(GET|POST|HEAD)$

"phase:1,t:lowerCase,deny"

Page 47: Mod Security v3

47

SecRule REQUEST_PROTOCOL !^HTTP/1\.(0|1)$

"phase:1,t:lowercase,deny"

# Từ chối các request không chứa host,accept header

SecRule &REQUEST_HEADERS:Host "@eq 0" "phase:1,deny"

SecRule &REQUEST_HEADERS:Accept "@eq 0" "phase:1,deny"

#Thay đổi chữ ký server thành Microsoft-IIS/6.0

SecServerSignature "Microsoft-IIS/6.0"

- Kết quả sau khi viết luật thông tin server đã được thay đổi thành

Microsoft-IIS/6.0, các request thăm dò tới server đã bị chặn

(thông điệp trả về mã lỗi 403 Forbidden)

Hình 3- 3 Kết quả ngăn chặn tấn công HTTP Fingerprinting

3.2.2. Ngăn chặn tấn công Brute Force

- Bản chất của tấn công này là kẻ tấn công (Attacker) thực hiện

đoán các thông tin đăng nhập như tên người dùng, mật khẩu,

email … của nạn nhân và thực hiện đăng nhập đến khi nào thông

tin đăng nhập là đúng. Hầu hết người dùng đều sử dụng thông

tin đăng nhập giống nhau trên tất cả các website mà họ thường

đăng nhập, dẫn đến tài khoản của họ bị xâm nhập trên hàng loạt

các website khi thông tin đăng nhập bị lộ bởi một website khác.

- Để ngăn chặn hình thức tấn công này cách tốt nhất là giới hạn số

lần đăng nhập không đúng. Ví dụ nếu người sử dụng đăng nhập

không đúng quá 3 lần, sẽ thực hiện khóa đăng nhập của người

này trong 5 phút hoặc lâu hơn.

- Sau đây là các rules của ModSecurity cho phép ta thực hiện điều

này.

<LocationMatch ^/login.php>

Page 48: Mod Security v3

48

# khởi tạo collection IP

SecAction "initcol:ip=%{REMOTE_ADDR},pass,log,msg:'faile login'"

# phát hiện đăng nhập không thành công

SecRule RESPONSE_BODY "Login failed" "phase:4,log,pass,

setvar:ip.brute_force=+1, expirevar:ip.brute_force=300"

# chuyển hướng sang trang nobru.html nếu đăng nhập sai quá 3

lần

SecRule IP:BRUTE_FORCE "@gt 3" "redirect:/nobru.html"

</LocationMatch>

Các luật trên dựa vào điểm trả về của website khi người ta truy

cập không thành công “Login failed”. Các luật trên sẽ khởi tạo

collection IP và tăng giá trị biến ip.brute_force lên một đơn vị sau

mỗi lần đăng nhập không thành công. Action expirevar sẽ thiết lập

biến ip.brute_force về 0 sau 5 phút. Vì vậy, khi biến BRUTE_FORCE

lớn hơn hoặc bằng 3, rule cuối sẽ khoá đăng nhập của người dùng

trong 5 phút.

Kiểm tra tập luật trên bằng cách thực hiện đăng nhập 3 lần sai

liên tiếp vào trang http://at7a.kma/login.php. Kết quả trả về đã

redirect tới trang cảnh báo nobru.html ở luật cuối cùng chỉ định.

Như vậy ngăn chặn tấn công brute force thành công

Hình 3- 4 Kết quả ngăn chặn tấn công Brute-force

3.3.3. Ngăn chặn tấn công Cross-Site Scripting (XSS)

Bản chất của tấn công XSS là các request được gửi từ các máy

client tới server nhằm chèn vào đó các thông tin vượt quá tầm kiểm

soát của server. Nó có thể là một request được gửi từ các form dữ

liệu hoặc cũng có nằm trong request URI, ví dụ:

Page 49: Mod Security v3

49

http://at7a.kma/vulnerabilities/xss_r/?name=<script>alert(document.coo

kie)</script>

Ở ví dụ trên attacker đã thực hiện một câu lệnh javascript đơn

giản để truyền vào URL nhằm hiện lên cookie của phiên làm việc.

Kết quả của việc tấn công mô tả ở hình sau:

Hình 3- 5 Kết quả tấn công XSS

XSS chỉ gây tổn hại đối với website ở phía client mà nạn nhân

trực tiếp là những người khách duyệt site đó. Tất nhiên đôi khi các

Attacker cũng sử dụng kĩ thuật này đề chiếm quyền điều khiển các

website nhưng đó vẫn chỉ tấn công vào bề mặt của website. XSS là

những Client-Side Script, những đoạn mã này sẽ chỉ chạy bởi trình

duyệt phía client do đó XSS không làm ảnh hưởng đến hệ thống

website nằm trên server. Mục tiêu tấn công của XSS là người sử

dụng khác của website, khi họ vô tình vào các trang có chứa các

đoạn mã nguy hiểm do các Attacker để lại, họ có thể bị chuyển tới

các website khác, đặt lại trang chủ, hay nặng hơn là mất mật khẩu,

mất cookie thậm chí máy tính người truy cập có thể sẽ bị cài các

loại virus, backdoor, worm …

Để ngăn chặn tấn công XSS, ta phải đảm bảo tất cả dữ liệu mà

người dùng gửi lên đều được cản lọc. Cụ thể, chúng ta có thể thay

thế hoặc loại bỏ các ký tự, các chuỗi thường được sử dụng trong tấn

công XSS như dấu lớn hơn (>), nhỏ hơn (<), script …

Page 50: Mod Security v3

50

Sau đây là danh sách các ký tự nên mã hóa khi được client cung

cấp để lưu vào cơ sở dữ liệu

Ký tự Mã hóa HTML

<

>

(

)

#

&

&lt;

&gt;

&#40;

&#41;

&#35;

&amp;

&quot;

&#39;

Bảng 3- 1 Các ký tự nên mã hoá để ngăn chặn tấn công XSS

- Tập luật thực hiện chặn tấn công XSS

SecRule ARGS "&\{.+}" "t:lowercase,redirect:/noxss.html,msg:'XSS'"

SecRule ARGS "<.+>" "t:lowercase,redirect:/noxss.html,msg:'XSS'"

SecRule ARGS "javascript:" "t:lowercase,redirect:/noxss.html,msg:'XSS'"

SecRule ARGS "script:" "t:lowercase,redirect:/noxss.html,msg:'XSS'"

SecRule ARGS "alert" "t:lowercase,redirect:/noxss.html,msg:'XSS'"

- Sau khi cấu hình chặn tấn công XSS thực hiện lại tấn công ở ví dụ

trên để kiểm tra kết quả:

http://at7a.kma/vulnerabilities/xss_r/?name=<script>alert(document.

cookie)</script>

- Kết quả sau khi viết rules ngăn chặn tấn công XSS

Page 51: Mod Security v3

51

Hình 3- 6 Kết quả ngăn chặn tấn công XSS

Kiểm tra Audit log để thấy rõ hơn ModSecurity đã thực hiện

redirect khi gặp tấn công XSS

--efb35936-A--

[29/Apr/2014:03:22:56 +0700] U164oAoAAAsAAJKNOnsAAAAA

192.168.234.1 52699 10.0.0.11 80

--efb35936-B--

GET

/vulnerabilities/xss_r/?name=%3Cscript%3Ealert%28document.cookie%2

9%3C%2Fscript%3E+ HTTP/1.1

Host: at7a.kma

User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:28.0)

Gecko/20100101 Firefox/28.0

Accept:

text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8

Accept-Language: en-US,en;q=0.5

Accept-Encoding: gzip, deflate

Referer: http://at7a.kma/vulnerabilities/xss_r/

Cookie: PHPSESSID=m7i9tvtgtuve2ljsk14pou7ue0; security=low

Connection: keep-alive

--efb35936-F--

HTTP/1.1 302 Found

Location: /noxss.html

Content-Length: 195

Connection: close

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

--efb35936-H--

Message: Access denied with redirection to /noxss.html using status 302

(phase 2). Pattern match "<.+>" at ARGS:name. [file

"/etc/httpd/conf.d/Modsecurity.conf"] [line "84"] [msg "XSS"]

Page 52: Mod Security v3

52

Action: Intercepted (phase 2)

Stopwatch: 1398716576868009 991 (444 689 -)

Producer: ModSecurity for Apache/2.5.12 (http://www.modsecurity.org/).

Server: Apache/2.2.15

--efb35936-Z--

3.3.4. Ngăn chặn tấn công SQL injection

Bản chất tấn công SQL Injection là một kỹ thuật cho phép

Attacker lợi dụng lỗ hổng của việc kiểm tra dữ liệu đầu vào trong

các ứng dụng web và các thông báo lỗi của hệ quản trị cơ sở dữ liệu

trả về để tiêm vào các câu lệnh SQL bất hợp pháp.

Ví dụ, ta xét câu lệnh truy vấn khi thực hiện đăng nhập dưới

đây:

SELECT * FROM user WHERE username = '%s' AND password =

'%s';

Với truy vấn trên, nếu Attacker muốn đăng nhập vào với tài

khoản admin mà chưa biết mật khẩu, Attacker sẽ thực hiện nhập

tên đăng nhập là admin và mật khẩu là ‘ OR ‘1’ = ‘1 -- Khi thực

hiện truy vấn, thông tin đăng nhập được đưa vào sẽ trở thành:

SELECT * FROM user WHERE username = 'admin' AND password

= '’ OR ‘1’ = ‘1

Câu lệnh trên có nghĩa: Truy vấn lấy thông tin tất cả các trường

từ bảng user với điều kiện trường username có giá trị là admin và

mật khẩu là trống ‘’ hoặc 1 = 1. Mà 1 = 1 là luôn đúng nên mặc dù

mật khẩu không đúng, câu lệnh trên vẫn được thực thi và truy vấn

lấy thông tin user admin thành công. Đăng nhập sẽ được chấp

nhận.

Sau đây là bảng liệt kê danh sách các lệnh thường được sử dụng

trong tấn công SQL Injection cùng với các biểu thức chính quy dùng

để ngăn chặn.

Page 53: Mod Security v3

53

SQL code Biểu thức chính quy

UNION SELECT union\s+select

UNION ALL SELECT union\s+all\s+select

INTO OUTFILE into\s+outfile

DROP TABLE drop\s+table

ALTER TABLE alter\s+table

LOAD_FILE load_file

SELECT FROM select\s+from

OR or\s

AND and\s

Bảng 3- 2 Các lệnh thường được sử dụng trong tấn công SQL Injection

- Thực hiện tấn công SQL Injection trước khi xây dựng tập luật. Sử

dụng truy vấn 1' UNION SELECT DATABASE(),USER() # tiêm vào

URL

http://at7a.kma/vulnerabilities/sqli/?id=1'+UNION+SELECT+DAT

ABASE(),USER()+#&Submit=Submit#

Hình 3- 7 Kết quả tấn công SQL Injection

Page 54: Mod Security v3

54

- Xây dựng tập luật ModSecurity để phòng chống tấn công SQL

Injection

SecRule ARGS "union\s+select" "t:lowercase, redirect:/nosql.html"

SecRule ARGS "union\s+all\s+select" "t:lowercase, redirect:/nosql.html "

SecRule ARGS "into\s+outfile" "t:lowercase,redirect:/nosql.html"

SecRule ARGS "drop\s+table" "t:lowercase,redirect:/nosql.html"

SecRule ARGS "alter\s+table" "t:lowercase,redirect:/nosql.html"

SecRule ARGS "load_file" "t:lowercase,redirect:/nosql.html"

SecRule ARGS "select\s+from" "t:lowercase,redirect:/nosql.html"

SecRule ARGS "or\s" "t:lowercase,redirect:/nosql.html"

SecRule ARGS "and\s" "t:lowercase,redirect:/nosql.html"

- Kết sau khi cấu hình ModSecurity

Hình 3- 8 Kêt quả ngăn chặn tấn công SQL Injection

- Kiểm tra Audit Log để thấy rõ hơn hành động mà ModSecurity

thực hiện

--f9cd6132-A--

[29/Apr/2014:03:29:42 +0700] U166NgoAAAsAAJNbH9UAAAAB

192.168.234.1 52740 10.0.0.11 80

--f9cd6132-B--

GET

/vulnerabilities/sqli/?id=1%27+UNION+SELECT+DATABASE%28%29%2C

USER%28%29+%23&Submit=Submit HTTP/1.1

Host: at7a.kma

User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:28.0)

Gecko/20100101 Firefox/28.0

Accept:

text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8

Page 55: Mod Security v3

55

Accept-Language: en-US,en;q=0.5

Accept-Encoding: gzip, deflate

Referer: http://at7a.kma/vulnerabilities/sqli/

Cookie: PHPSESSID=m7i9tvtgtuve2ljsk14pou7ue0; security=low

Connection: keep-alive

--f9cd6132-F--

HTTP/1.1 302 Found

Location: /nosql.html

Content-Length: 195

Connection: close

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

--f9cd6132-H--

Message: Access denied with redirection to /nosql.html using status 302

(phase 2). Pattern match "union\s+select" at ARGS:id. [file

"/etc/httpd/conf.d/Modsecurity.conf"] [line "91"]

Action: Intercepted (phase 2)

Stopwatch: 1398716982044622 849 (418 544 -)

Producer: ModSecurity for Apache/2.5.12 (http://www.modsecurity.org/).

Server: Apache/2.2.15

--f9cd6132-Z-—

Page 56: Mod Security v3

56

KẾT LUẬN

Qua một thời gian tìm hiểu đề tài “Bảo mật máy chủ ứng dụng

web với ModSecurity ” nhóm em đã có cơ hội tìm hiểu về tường lửa

ứng dụng, cụ thể là phần mềm mã nguồn mở ModSecurity. Do điều

kiện thời gian và thiết bị triển khai còn thiếu do vậy nhóm em chưa

có điều kiện triển khai vào thực tế được.

Trong đề tài này nhóm đã đạt được kết quả nhất định như

sau:

Về lý thuyết đã tìm hiểu được tầm quan trọng của

ModSecurity

Hiểu được nguyên tắc hoạt động và nhiệm vụ của

ModSecurity

Có khả năng viết Rule.

Về mặt thực hành nhóm em đã tiến hành cài được các dịch

vụ Web và ModSecurity trên máy chủ CentOS, đồng thời

thực hiện viết rules ngăn chặn một số tấn công như: HTTP

FingerPrinting, tấn công Brute Force, XSS, SQL Injection.

Những việc chưa làm được

Do chưa có hệ thống máy chủ thực tế, mô hình triển khai

lab của đề tài này chỉ mới xây dựng trong mạng LAN.

Sử dụng các rules chưa được linh hoạt

Hướng phát triển

Triển khai và phát triển thêm các luật cho thêm một số

hình thức tấn công mới.

Kết hợp ModSecurity và Iptable chống tấn công Dos và

DDos

Xây dựng triển khai ModSecurity trên hệ thốngWeb Server

thực tế.

Page 57: Mod Security v3

57

TÀI LIỆU THAM KHẢO

[1]. ModSecurity 2.5 - Securing your Apache installation and web

applications, Packt Publishing Ltd, Magnus Mischel (11-2009).

[2]. Modsecurity Handbook: The Complete Guide to the Popular

Open Source Web Application Firewall. Ristic, Ivan. S.l.: Feisty

Duck, 2010. Web

[3]. Đề tài tìm hiểu ModSecurity – Học viện kỹ thuật Mật Mã

[4]. Bảo mật Web server Apache với modsecurity – diễn đàn HVA

http://www.hvaonline.net/hvaonline/posts/list/1754.hva

[5]. https://github.com/SpiderLabs/ModSecurity/wiki/Reference-

Manual#args