MỤC LỤC MỤC LỤC ............................. ............................................................ ............................................. .............. 1 LỜ I MỞ ĐẦ ........................................... ......................... 4 Ở ĐẦU .................................................................... DANH MỤC
HÌNH ẢNH ............................. ..................................................... ........................ 6
DANH MỤC
..................................................... ........................ 7 CÁC BẢNG .............................
CHƯƠ NG NG I
– TỔNG QUAN V Ề GIAO THỨ C HTTP ................ 8
1.1.Gi 1.1.Giới thiệu chung .......................................................... ...... .................................................... 8 1.1.1. .................................. URI
– Uniform Resource Identifiers 8
1.1.2. ................................... Một số ph phương thứ c thường 1.2.Thông
dùng: 9
................ ....................................... 13 điệp HTTP .......................................................
1.2.1. .................................................. Cấu 1.2.2. .......................................... Các
trúc thông đ iệp HTTP 13
trường trong HTTP header 16
CHƯƠ NG NG II - MODSECURITY .............................. .......................................... ............ 18 2.1.Tìm
hiểu v ề ModSecurity ............................................. 18
2.1.1. ........................................................ 2.1.2. ......................................... 2.1.3. Quá 2.2.Các
Khái niệm Modsecurity 18
Các khả năng của ModSecurity 18
trình xử lý xử lý các request của Apache và ModSecurity 20
luật (Rules) ......................................................... 22
2.2.1. ........................................................ ModSecurity Core Rule 22 2.2.2. ......................................... Cấ u 2.2.3. .................. Biến
hình các chỉ thị (Directive) 23
(Variables ) và bộ chọn lọc (Collection) 26
2.2.4. ......................................................... Chứ c năng chuyển 1
đổi 29
2.2.5. ............................................................
Toán tử (Operators) 30
2.2.6. ...........................................................
Hành động (Actions) 33
2.3.Logging 2.3.Logging .................................................................... 35 2.3.1. ............................................................................. Debug Log 35 2.3.2. ......................................................................... Audit logging 36 2.2.3. ......................................................... Tuỳ biế n thông 2.4.Bi 2.4.Biểu thức
chính quy (Regular expressions) ..................... 37
2.4.1. ..................................... Giới thiệu v ề biểu thức 2.4.2. .. Ứ ng ng dụng của biểu thức 2.5.Cài
tin log 37
chính quy 37
chính quy trong Modsecurity 38
đặt và cấu hình cơ bản ModSecurity trên máy chủ
CentOs .......................................................................... ........................... ............................................... 39 39 2.5.1. ............................................................
Cài đặt ModSecurity 39
2.5.2. ................................................................... Cấu 2.6.Vi 2.6.Viết
hình cơ bản 40
luật cơ bản ............................. 41 và phân tích mộ t số lu
CHƯƠ NG NG
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 NG DỤNG WEB ............................. .............................................................. ....................................... ...... 44 3.1.Mô
III
-
ng kịch bản Demo44 hình triển khai ModSecurity và xây dự ng
3.1.1. ....................................................
ng kịch bản demo 44 Xây dự ng
3.2.Xây
ng l ại một s ố t t ấ n dựng chính sách trên tr ên ModSecurity chố ng ng dụng Web .................................................... 45 công lên ứ ng 3.2.1. ......................................... Ngăn 3.2.2. ....................................... Ngăn 3.3.3. ............ Ngăn
chặn HTTP Fingerprinting 45
chặn tấn công Brute Force 47
chặn tấn công Cross -Site Scripting (XSS) 48 2
2.2.5. ............................................................
Toán tử (Operators) 30
2.2.6. ...........................................................
Hành động (Actions) 33
2.3.Logging 2.3.Logging .................................................................... 35 2.3.1. ............................................................................. Debug Log 35 2.3.2. ......................................................................... Audit logging 36 2.2.3. ......................................................... Tuỳ biế n thông 2.4.Bi 2.4.Biểu thức
chính quy (Regular expressions) ..................... 37
2.4.1. ..................................... Giới thiệu v ề biểu thức 2.4.2. .. Ứ ng ng dụng của biểu thức 2.5.Cài
tin log 37
chính quy 37
chính quy trong Modsecurity 38
đặt và cấu hình cơ bản ModSecurity trên máy chủ
CentOs .......................................................................... ........................... ............................................... 39 39 2.5.1. ............................................................
Cài đặt ModSecurity 39
2.5.2. ................................................................... Cấu 2.6.Vi 2.6.Viết
hình cơ bản 40
luật cơ bản ............................. 41 và phân tích mộ t số lu
CHƯƠ NG NG
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 NG DỤNG WEB ............................. .............................................................. ....................................... ...... 44 3.1.Mô
III
-
ng kịch bản Demo44 hình triển khai ModSecurity và xây dự ng
3.1.1. ....................................................
ng kịch bản demo 44 Xây dự ng
3.2.Xây
ng l ại một s ố t t ấ n dựng chính sách trên tr ên ModSecurity chố ng ng dụng Web .................................................... 45 công lên ứ ng 3.2.1. ......................................... Ngăn 3.2.2. ....................................... Ngăn 3.3.3. ............ Ngăn
chặn HTTP Fingerprinting 45
chặn tấn công Brute Force 47
chặn tấn công Cross -Site Scripting (XSS) 48 2
3.3.4. .................................... Ngăn
chặn tấn công SQL injection 52
KẾ T LUẬN .......................................................... ........................... ........................................... ............ 56 .................................................... ...................... 57 TÀI LIỆU THAM KHẢO ..............................
3
Ở ĐẦU LỜ I MỞ ĐẦ Trong những
năm gần đây, Ứ ng 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 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. c. Ứ ng ng dụng Web càng phổ biến thì các cuộc tấn công ứ 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 ều tổ chức, công ty đã xây dựng tườ ng bảo mật ứ ng ng dụng web. Nhi ề lử a ứ ng ng d ụng web để b ảo vệ hệ thống máy chủ ứ ng 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 ng một s ố t t ấn công phổ bi ế n lên ứ ng 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ý 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 tấn công lên ứ ng ng dụng web. web.
4
Ph ần
này, nhóm đưa ra một số tập luật nhằm chố ng ng lại một số tấn công lên ứ ng ng dụng web phổ biến như XSS, Brute force, SQL Injection, Dos …
5
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 6
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
7
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
8
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 ợ
-
Password: mật khẩu truy cập
-
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ị
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.
1.1.2. -
tài nguyên
trí nào đó trong tài nguyên
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 9
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
10
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 GE T
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. 11
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
12
-
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 t hì 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 Thông điệp HTTP
1.2.
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
13
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
14
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
15
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ẽ 16
không
trình
bày.
Các
bạn
http://tools.ietf.org/html/rfc2068
17
có
thể
tham
khảo
ở
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 18
đượ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 h ay 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.
19
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: Các luật được đặt tại đây sẽ được thự c hiện ngay sau khi Apache đọc request header (Postread-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 Header (phase 1):
-
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
20
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 o
mã hoá request body sau:
Application/x-www-form- urlencoded:
Dùng để truy ền form
dữ liệu o
Multipart/form-data :
o
Text/xml:
Dùng để truy ền file
Dùng để phân tích dữ liệu XML
Đâ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 Header (phase 3):
-
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 Injectio n, 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. -
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. Phase logging (phase 5):
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 21
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ý. 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 Phase
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 22
-
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
-
Cấu
-
Yêu cầu v ề logic là phát hiện các cuộc tấn công.
-
Thiết
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. 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. đặ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). đị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. ModSecurity
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 23
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 24
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 -
-
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 VARIABLES:
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, 25
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. 26
Để 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
-
ARGS_NAMES:
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. 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 27
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
"allow,log,msg:'dang nhap',phase:2" 28
"^login\.php$"
-
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 đổi
năng chuyển
Base64Encode
Mô tả Mã hóa chuỗi sang base64 29
Giải
Base6Decode
mã từ base64
compressWhitespace Chuyển tab, dòng mới, space, liên tiế p sang một dấ u space
và nhiều space
cssDecode
Giải
escapeSeqDecode
Gi ải mã ANSI C escape (\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 < thành <)
Giải
mã JavaScript escape sequences
jsDecode
mã ký tự CSS sequences
Length
Chuyển một chuỗi
Lowercase
Chuyển chuỗi sang tấ t cả
Md5
Chuyển
urlDecode
Giải
urlDecodeUni
Giống urlDecode, nhưng kiểu ký tự Unicode
Bảng 2- 2
2.2.5. Toán
thành độ dài của chuỗi đó ký tự thường
ký tự nhập vào sang MD5
mã một chuỗi URL xử lý được mã hóa
Các chức năng chuyển đổ i c ủa Modsecurity
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:
30
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
31
-
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
32
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 status.
là status code của ngườ i quản trị thiế t lập chỉ thị
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” -
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ụ : Allow:
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, gử i một
hành động dừ ng một kế t nối TCP và
gói FIN
Secondary Actions
Secondary Actions s ẽ bổ sung cho Primary Actions, m ột luật thể -
có
có nhiều Secondary Actions.
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. Status:
Khi
m ột
Request
vi
33
ph ạm
m ột
luật
-
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:
-
Pause: ModSecurity s ẽ
Không ghi log đợ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ử ,
hình trong tập tin Modsecurity.conf, giá trị SecDefaultAction là của phase:2,log,auditlog,pass . Ta có một rule đơn giản không đượ c chỉ định action như sau: sau
khi
th ự c
hiện
cấu
SecRule REQUEST_BASENAME "^login\.php$" Khi ModSecurity ho ạt SecRule
động, thì luật trên sẽ được hiểu như sau:
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”
34
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.
35
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--
36
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 -
On
– log tấ t cả các request
-
Off
– không ghi log
-
RelevantOnly
4 giá trị sau:
– chỉ log nhữ ng gì được sinh ra bởi các filtering
rules -
– log nhữ ng request tạo ra nội dung hoặc những request được sinh ra bởi các filtering rules. DynamicOrRelevanl
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.
37
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 -
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 Epsilon:
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. 38
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/modsecurityapache_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 [root@webserver ~]#yum
(cài đặ t apxs)
–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 39
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
40
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"
41
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-A gent đó 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ẽ 42
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) t rướ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
43
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 44
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
45
-
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
Chặn
Đổi thông tin server thành Microsoft -IIS/6.0
các request với các giao thứ c ngoại trừ giao thứ c HTTP 1.0 và 1.1 các request không chưa Host header
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" 46
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.
47
# 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"
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ụ : 48
http://at7a.kma/vulnerabilities/xss_r/?name=<script>alert(document.coo kie)
Ở 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 … 49
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
<
<
>
>
(
(
)
)
#
#
&
&
“ ‘
" '
Bảng 3- 1 -
Tập luật thự c hiện chặn tấn
SecRule SecRule SecRule SecRule SecRule -
Các ký tự nên mã hoá để ngăn chặn t ấn công XSS
ARGS ARGS ARGS ARGS ARGS
công XSS
"&\{.+}" "t:lowercase,redirect:/noxss.html,msg:'XSS'" "<.+>" "t:lowercase,redirect:/noxss.html,msg:'XSS'" "javascript:" "t:lowercase,redirect:/noxss.html,msg:'XSS'" "script:" "t:lowercase,redirect:/noxss.html,msg:'XSS'" "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)
-
Kế t quả sau khi vi ết
rules ngăn chặn tấn công XSS
50
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"] 51
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.
52
SQL code
Biểu thức
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 -
chính quy
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
53
-
Xây dự ng tập luật ModSecurity để phòng chố ng tấn công SQL Injection
SecRule SecRule SecRule SecRule SecRule SecRule SecRule SecRule SecRule -
ARGS ARGS ARGS ARGS ARGS ARGS ARGS ARGS ARGS
"union\s+select" "t:lowercase, redirect:/nosql.html" "union\s+all\s+select" "t:lowercase, redirect:/nosql.html " "into\s+outfile" "t:lowercase,redirect:/nosql.html" "drop\s+table" "t:lowercase,redirect:/nosql.html" "alter\s+table" "t:lowercase,redirect:/nosql.html" "load_file" "t:lowercase,redirect:/nosql.html" "select\s+from" "t:lowercase,redirect:/nosql.html" "or\s" "t:lowercase,redirect:/nosql.html" "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 54
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-—
55
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ế .
56
