Bảo mật máy chủ ứng dụng Web với ModSecurity

Ngày nay rất nhiều doanh nghiệp, tổ chức sử dụng ứng dụng web để cung cấp dịch vụ thương mại trực tuyến, kết nối khách hàng, đối tác và nhân viên một cách hiệu quả nhất. Tuy nhiên, ứng dụng web cũng đem đến những rủi ro đáng kể cho hệ thống và dữ liệu. Đa số ứng dụng web có thể bị những lỗi mà các phương pháp và cách phòng chống mạng thông thường không bảo vệ được. Sau đây là một số nguy cơ tạo điểm yếu (lỗ hổng) trong ứng dụng web phổ biến hiện nay Nguy cơ đầu tiên xuất phát từ phiên bản máy chủ web và máy chủ cơ sở dữ liệu mà chúng ta đang sử dụng. Ở mỗi phiên bản sử dụng đều có những lỗ hổng mà nhờ đó kẻ tấn công có thể thâm nhập vào hệ thống của chúng ta. Để khắc phục nguy cơ này, người quản trị cần phải cập nhật các bản vá từ nhà cung cấp sản phẩm. Dễ dàng để trả lời là chưa an toàn, vì mỗi hệ thống sẽ có một cấu hình riêng, do đó sau khi cập nhật nó có thể làm cho hệ thống hoạt động không ổn định vì sự không tương thích này. Nguy cơ thứ hai xuất phát từ mã nguồn của Website. Với nguy cơ này ta có thể sửa đổi mã nguồn để hạn chế những lỗ hổng phát sinh do mã nguồn. Nguy cơ thứ ba xuất phát từ bên ngoài gồm có: -Nguy cơ tấn công từ chối dịch vụ (DoS, DDoS) làm cho hệ thống ngưng trệ, không có khả năng phục vụ các yêu cầu chính đáng -Nguy cơ bị thay đổi nội dung trang web, làm giảm uy tín hoặc bôi nhọ tổ chức -Nguy cơ đánh cắp các thông tin nhạy cảm như: thông tin tài khoản, mật khẩu truy cập hệ thống và thông tin thẻ tín dụng … -Nguy cơ do người lập trình chưa kiểm soát được dữ liệu đầu vào. Các tấn công phổ biến ở dạng này bao gồm oCross site scripting oLỗi tràn bộ đệm oTấn công Format string oSQL injection oCookie poisoning Hiện nay có rất nhiều cách khắc phục các điểm yếu trong ứng dụng web và đảm bảo cho máy chủ ứng dụng web vận hành an toàn và liên tục như -Kết nối bên ngoài bao gồm các thiết bị định tuyến kết nối ADSL, Lease-line… cùng các thiết bị cân bằng tải -Kết nối bảo mật: các thiết bị tường lửa, các hệ thống phòng chống tấn công IDS (Intrusion detection system), IPS (Intrusion prevention system) và phần mềm giám sát hệ thống mạng -Hệ thống máy chủ: các máy chủ cài phần mềm diệt virut, chống spam mail (thư rác), loại bỏ các dịch vụ không cần thiết… -Hệ thống lưu trữ: các thiết bị lưu trữ dữ liệu tích hợp SAN (Storage Area Network) Trong đề tài này nhóm em xin đi sâu vào phần bảo mật máy chủ ứng dụng web bằng Modsecurity

MỤC LỤC

MỤC LỤC 1

DANH MỤC HÌNH ẢNH 3

DANH MỤC CÁC BẢNG 3

CHƯƠNG I –TỔNG QUAN VỀ ỨNG DỤNG WEB VÀ VẤN ĐỀ VỀ BẢO MẬT HIỆN NAY 5

1.1 Khái niệm ứng dụng web 5

1.2 Cấu trúc cơ bản và mô tả hoạt động của ứng dụng web 5

1.2.1 Cấu trúc cơ bản của một ứng dụng web 5

1.2.2 Mô tả hoạt động của một ứng dụng web 6

1.3 Các nguy cơ mất an toàn ứng dụng web và vấn đề bảo mật hiện nay 7

CHƯƠNG II - MODSECURITY 9

2.1 Tìm hiểu về ModSecurity 9

2.1.1 Khái niệm Modsecurity 9

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

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

2.2 Các luật (Rules) 12

2.2.1 ModSecurity Core Rule 12

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

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

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

2.2.5 Toán tử (Operators) 19

2.2.6 Hành động (Actions) 20

2.3 Logging 22

2.3.1 Debug Log 22

2.3.2 Audit logging 23

2.3.3 Tuỳ biến thông tin log 24

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

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

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

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

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 28

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

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

3.1.2 Cài đặt ModSecurity trên máy chủ CentOS 29

3.1.3 Cấu hình cơ bản 30

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 31

3.2.1 Ngăn chặn HTTP Fingerprinting 31

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

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

3.2.4 Ngăn chặn tấn công SQL injection 36

KẾT LUẬN 39

TÀI LIỆU THAM KHẢO 40

DANH MỤC HÌNH ẢNH

Hình 1.1 Mô hình phân tầng đơn giản trong cấu trúc ứng dụng Web 6

Hình 1.2 Mô tả hoạt động của ứng dụng web 6

Hình 2.1 Mô hình tổng quan ModSecuriy 9

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

Hình 3.1 Mô hình triển khai Modsecurity 28

Hình 3.2 Trước khi cấu hình ModSecurity 31

Hình 3.3 Sau khi thực hiện cấu hình cơ bản Modsecurity 31

Hình 3.4 Kết quả tấn công HTTP Fingerprinting 33

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

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

Hình 3.7 Kết quả ngăn chặn tấn công XSS 37

Hình 3.8 Kết quả tấn công trước khi cấu hình ModSecurity 39

Hình 3.9 Kêt quả ngăn chặn tấn công SQL Injection 39

DANH MỤC CÁC BẢNG Bảng 2.1 Các loại chỉ thị trong Modsecurity 14

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

Bảng 2.3 Các toán tử String –matching 20

Bảng 2.4 Các toán tử hỗ trợ so sánh 20

Bảng 2.5 Các toán tử kiểm tra 20

Bảng 2.6 Toán tử Miscellaneous 21

Bảng 3.1 Thành phần trong mô hình 28

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

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

LỜI MỞ ĐẦU

Trong những năm gần đây, Việt Nam ngày càng phát triển và nhất là về mặtcông nghệ thông tin Đặc biệt là về ứng dụng Web, hầu như mọi người ai cũng từngnghe 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ầnquan 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âydựng tường lửa ứng dụng web để bảo vệ hệ thống máy chủ ứng dụng web như sảnphẩm Imperva, CheckPoint hay ModSecurity Trong đó Imperva và Checkpoint là sảnphẩ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 triển khai “Bảo mật máy chủ ứngdụng web với ModSecurity” Với mục đích xây dựng nên các chính sách để phòngchố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 HTTPFingerprinting, tấn công Brute Force, Cross Site Scripting (XSS), SQL Injection …Trong giới hạn của đề tài này, nhóm em xin trình bày chuyên đề gồm 3 chương chính,như sau:

Chương 1: Tổng quan về ứng dụng web và vấn đề bảo mật hiện nay

Chương này nhóm em xin trình bày khái quát về ứng dụng web, các nguy cơmất an toàn ứng dụng web và vấn đề bảo mật hiện nay Từ đó thấy tầm quan trọng củabảo mật ứng dụng web hiện nay

Chương 2: ModSecurity

Ở phần này nhóm em xin giới thiệu tổng quan về ModSecurity cách thứcModSecurity 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.

Trong quá trình thực hiện đề tài này, nhóm em xin gửi lời cảm ơn chân thànhđến các thầy cô trong Học viện Kỹ thuật Mật Mã nói chung và các thầy cô khoa Côngnghệ thông tin đã truyền đạt những kiến thức quý báu cho nhóm em trong suốt thờigian qua Đặc biệt, nhóm em xin gửi lời cảm ơn sâu sắc tới thầy giáo Ths Nguyễn ĐàoTrường đã nhiệt tình hướng dẫn nhóm em hoàn thành đề tài này Do thời gian chuẩn bịcòn hạn chế nên đề tài không tránh khỏi thiếu sót Nhóm em rất mong nhận được sựđánh giá, những ý kiến quý báu từ phía thầy cô và các bạn để hoàn thiện hơn

Hà Nội, ngày 18 tháng 12 năm 2013

CHƯƠNG I –TỔNG QUAN VỀ ỨNG DỤNG WEB VÀ VẤN ĐỀ VỀ BẢO

MẬT HIỆN NAY1.1 Khái niệm ứng dụng web

Ứng dụng web là một ứng dụng khách/chủ truy cập qua mạng Internet hayintranet sử dụng giao thức HTTP/HTTPS để tương tác với người dùng hay hệ thốngkhác

Trình khách dành cho người sử dụng là một phần mềm phổ biến và chung chocác ứng dụng web như là Internet Explorer, Nescape, Firefox … Ứng dụng web rấtphổ biến bởi sự cập nhật và duy trì mà không cần phần mềm phân phối, cài đặt tạihàng nghìn máy tính của người sử dụng Các ứng dụng web phổ biến hiện nay là:webmail, bán hàng trực tuyến, đấu giá, mạng xã hội và nhiều chức năng khác

Trước đây ứng dụng web được xây dựng trên mô hình tập trung, nghĩa là ứngdụng chạy trên một máy chủ và kết nối vào cơ sở dữ liệu ngay trên máy chủ đó Hiệnnay các ứng dụng web được xây dựng theo mô hình phân tán, nhiều máy chủ đáp ứngyêu cầu và kết nối tới nhiều nguồn cơ sở dữ liệu Trình chủ được viết bằng các ngônngữ như : PHP, ASP, ASP.NET, JSP…

1.2 Cấu trúc cơ bản và mô tả hoạt động của ứng dụng web

1.2.1 Cấu trúc cơ bản của một ứng dụng web

Cấu trúc đơn giản của một ứng dụng Web được chia thành 3 tầng: Model –View - Controller, mỗi tầng đảm nhận một nhiệm vụ chuyên biệt

- Tầng truy vấn (Model): Chứa các mã lệnh kết nối tới database, truy vấn, thêm,xóa sửa dữ liệu

- Tầng nhập và hiển thị (View): Chứa code tạo giao diện tương tác với ngườidùng, tái hiện dữ liệu và dẫn dắt người dùng các tương tác với dữ liệu.

- Tầng điều khiển (Controller): Chứa code điều khiển dòng dữ liệu, gắn kết tầngModel và tầng View lại với nhau

Cấu trúc này giúp chia nhỏ quá trình xử lý, có thể làm việc trên từng thành phầnriêng lẻ trong khi các thành phần khác sẽ không bị ảnh hưởng tới Chẳng hạn chúng tamuốn ứng dụng có thể truy xuất trên di động thì chỉ cần tạo một tầng View mới màtầng Model và Controller không thay đổi Hay nếu ta muốn thay đổi database ta chỉcần tạo ra một tầng Model mới, phần View và Controller không bị ảnh hưởng

Hình 1.1 Mô hình phân tầng đơn giản trong cấu trúc ứng dụng Web

1.2.2 Mô tả hoạt động của một ứng dụng web

Hoạt động của ứng dụng web được biểu diễn như hình sau:

Hình 1.2 Mô tả hoạt động của ứng dụng web

Một ứng dụng web bao gồm hai phía:

- Phía Client: là trình duyệt web

- Phía Server: kiến trúc ứng dụng web bao gồm 2 lớp: lớp logic (Web Server,Web Application Server) và lớp dữ liệu (Database Server)

- Ngoài ra tường lửa được sử dụng để chống lại sự truy cập trái phép, bảo vệ cácnguồn thông tin nội bộ cũng như hạn chế sự xâm nhập vào hệ thống

Mô tả hoạt động như sau:

Đầu tiên Client sẽ gửi một yêu cầu (request) đến Web Server thông qua các lênh

cơ bản GET, POST… của giao thức HTTP/HTTPS, Web Server lúc này có thể thựcthi một chương trình được xây dựng từ nhiều ngôn ngữ như Perl, C/C++… hoặc nó sẽyêu cầu bộ diễn dịch thực thi các trang ASP, JSP… theo yêu cầu của trình duyệt.Tùy theo các tác vụ của chương trình được cài đặt mà nó xử lý, tính toán, kết nối đến

cơ sở dữ liệu, lưu các thông tin do trình duyệt gửi đến và từ đó trả về cho Client mộtluồng dữ liệu có định dạng theo giao thức HTTP, nó gồm 2 phần:

- Header: mô tả các thông tin về gói dữ liệu và các thuộc tính, trạng thái trao đổigiữa trình duyệt và Web Server

- Body: là phần nội dung dữ liệu mà Server gửi về Client, nó có thể là một fileHTML, một hình ảnh, video hay một văn bản bất kỳ

Theo hình 1.2, với Firewall luồng thông tin giữa trình duyệt và Web Server làluồng thông tin hợp lệ, vì thế nếu hacker tìm thấy vài lỗ hổng trong ứng dụng web thìfirewall không còn hữu dụng trong việc ngăn chặn hacker này Do đó các kỹ thuật tấncông vào một hệ thống mạng ngày nay chủ yếu là tập trung vào những lỗ hổng trongquá trình tạo ứng dụng của nhà phát triển web hơn là tấn công trực tiếp vào hệ thốngmạng

1.3 Các nguy cơ mất an toàn ứng dụng web và vấn đề bảo mật hiện nay

Ngày nay rất nhiều doanh nghiệp, tổ chức sử dụng ứng dụng web để cung cấpdịch vụ thương mại trực tuyến, kết nối khách hàng, đối tác và nhân viên một cách hiệuquả nhất Tuy nhiên, ứng dụng web cũng đem đến những rủi ro đáng kể cho hệ thống

và dữ liệu Đa số ứng dụng web có thể bị những lỗi mà các phương pháp và cáchphòng chống mạng thông thường không bảo vệ được Sau đây là một số nguy cơ tạođiểm yếu (lỗ hổng) trong ứng dụng web phổ biến hiện nay

Nguy cơ đầu tiên xuất phát từ phiên bản máy chủ web và máy chủ cơ sở dữ liệu

mà chúng ta đang sử dụng Ở mỗi phiên bản sử dụng đều có những lỗ hổng mà nhờ đó

kẻ tấn công có thể thâm nhập vào hệ thống của chúng ta Để khắc phục nguy cơ này,

người quản trị cần phải cập nhật các bản vá từ nhà cung cấp sản phẩm Dễ dàng để trảlời là chưa an toàn, vì mỗi hệ thống sẽ có một cấu hình riêng, do đó sau khi cập nhật

nó có thể làm cho hệ thống hoạt động không ổn định vì sự không tương thích này

Nguy cơ thứ hai xuất phát từ mã nguồn của Website Với nguy cơ này ta có thểsửa đổi mã nguồn để hạn chế những lỗ hổng phát sinh do mã nguồn

Nguy cơ thứ ba xuất phát từ bên ngoài gồm có:

- Nguy cơ tấn công từ chối dịch vụ (DoS, DDoS) làm cho hệ thống ngưng trệ, không

có khả năng phục vụ các yêu cầu chính đáng

- Nguy cơ bị thay đổi nội dung trang web, làm giảm uy tín hoặc bôi nhọ tổ chức

- Nguy cơ đánh cắp các thông tin nhạy cảm như: thông tin tài khoản, mật khẩu truycập hệ thống và thông tin thẻ tín dụng …

- Nguy cơ do người lập trình chưa kiểm soát được dữ liệu đầu vào Các tấn công phổbiến ở dạng này bao gồm

o Cross site scripting

- Hệ thống máy chủ: các máy chủ cài phần mềm diệt virut, chống spam mail (thưrác), loại bỏ các dịch vụ không cần thiết…

- Hệ thống lưu trữ: các thiết bị lưu trữ dữ liệu tích hợp SAN (Storage Area Network)Trong đề tài này nhóm em xin đi sâu vào phần bảo mật máy chủ ứng dụng webbằng Modsecurity

CHƯƠNG II - MODSECURITY 1.

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áttriển dành cho Apache Web Server Nó được xem là một bộ máy phát hiện và phòngchống xâm nhập dành cho các ứng dụng web Hoạt động như một module của WebServer 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ạivớ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ềuhà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ậttấn công

- Hiểu giao thức HTTP (Understanding of the HTTP protocol): ModSecurity là mộttường lửa ứng dụng nên nó có khả năng hiểu được giao thức HTTP ModSecurity

có khả năng cản lọc dựa trên các thông tin ở HTTP Header hay có thể xem xét đếntừ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ệccả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

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 ngaysau khi Apache đọc request header (Post-read-request), lúc này phần request bodyvẫ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àoHTTP method cũng như dựa vào URL như SQL Injection, Local file include, CrossSite 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 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 củaphase này là phân tích đầu vào dữ liệu, dịch URI, kiểm tra header, kiểm tra truycậ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 responseheader đượ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 tratại response header thì nội dung trong phần body sẽ được kiểm tra so trùng với mẫutrong 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 trongtrườ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ànhcô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ủaApache Đâ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 mongmuố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úngxuất hiện trong các 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 loggingbắ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 đượctruyề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ưngcầ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ũngkhô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ẩnthậ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ốngphá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ấncô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ạichư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ấytạ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ồmnhữ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ứcHTTP và chính sách sử dụng được định nghĩa

- 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 đặtkhá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, ghilog.

- 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ườiquả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ựchiệ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ướidạng các directives (chỉ thị) và có thể đặt trực tiếp trong file cấu hình Apache (thôngthườ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ínhnăng lọc linh động cho hệ thống web

SecAction Performs an unconditional action This directive is

essentially a rule that always matches

SecDefaultAction Specifies the default action list, which will be used

in the rules that follow

SecMarker Creates a marker that can be used in conjunction

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

SecRuleInheritance Controls whether rules are inherited in a child

configuration context

SecRuleRemoveById Removes the rule with the given ID

SecRuleRemoveByMsg Removes the rule whose message matches the

given 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ỗiyê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ôngnê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 webcủa ModSecurity.Dưới đây là một số các chỉ thị quan trọng

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

- 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 đượcnhư 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áchà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ố trongrequest

- OPERATOR: chỉ định cách mà ModSecurity sẽ tìm kiếm mẫu Các toán tử đượcdù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 chocá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, 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

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ếnCollection (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ệpheader mà Client gửi tới Server, chẳng hạn như User-agent, hoặc Referer

Để truy cập vào một trường trong collection, chúng ta ghi tên collection, tiếptheo 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 truycậ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ụ tamuố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 "192.168.1.99/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ụngkhi 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à

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àngkhi 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áchnố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óaMULTIPART 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ênREQUEST_FILENAME Ví dụ:

SecRule REQUEST_BASENAME "^login\.php$" "allow,log,msg:'dang nhap',phase:2"

- 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ácrequest 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ể ápdụ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 saocủ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ốnphá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 ápdụ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ườngsCript, ScRipt, SCRIPT…

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

Base64Encode Mã hóa chuỗi sang base64

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

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

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

jsDecode Giải mã JavaScript escape sequences

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

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

urlDecodeUni Giống urlDecode, nhưng xử lý được mã hóa kiểu ký tự

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ínhquy 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ăngcho 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ệuquả hơn so với biểu thức chính quy

ModSecurity hỗ trợ 4 nhóm sau:

- 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ácbiến Toán tử @rx và @pm thường được sử dụng nhiều trong các rule phân tích

@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ố

@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ứcnăng lọc khá hữu dụng như: phát hiện lộ thông tin credit card (@verifyCC), kiểmtra vùng địa lý của IP người dùng (@geoLookup)…

@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