Embed Size (px)
DESCRIPTION
d
Citation preview
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
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
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
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.
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 …
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
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
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
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
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
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.
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
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
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
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
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ẽ
17
không trình bày. Các bạn có thể tham khảo ở
http://tools.ietf.org/html/rfc2068
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
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.
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
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
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
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
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
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,
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.
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
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"
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
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 < 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:
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
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
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.
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”
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.
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--
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.
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.
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
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
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"
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ẽ
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
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
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
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"
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>
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ụ:
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 …
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
<
>
(
)
#
&
“
‘
<
>
(
)
#
&
"
'
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
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"]
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.
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
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
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-—
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ế.
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
