PHẦN 2: MODSECURITY
2.1. GIỚI THIỆU MODSECURITY
ModSecurity là một Opensource web application firewall được Ivan
Ristic phát triển dành cho Web Server Apache. Ivan Ristic cũng là tác
giả quyển sách “Mod Security Handbook”. Ông là một người có rất nhiều
kinh nghiệm trong bảo vệ Web Server Apache. Ông đã có nhiều thời gian
nghiên cứu Web Application Security, Web Intrusion Detection, và
Security Patterns. Trước khi chuyển sang lĩnh vực security, Ivan đã có
nhiều năm làm việc như một Developer, System Architect, Technical
Director trong phát triển phần mềm. Ông là người sáng lập ra công ty
ThinkingStone làm các dịch vụ liên quan đến web application security.
Hiện tại ModSecurity sử dụng giấy phép GPL, hoàn toàn miễn phí
2.2. CÁC KHẢ NĂNG CỦA MODSECURITY
Hình 2.1 Mô hình tổng quan của ModSecurity
- Request filtering: Tất cả các request gửi đến web server
đều được phân tích và cản lọc (filter) trước khi chúng được đưa đến các
modules khác để xử lý
- Understanding of the HTTP protocol: ModSecurity là một
tường lửa ứng dụng nên nó có khả năng hiểu được giao thức HTTP.
ModSecurity có khả năng cản lọc dựa trên các thông tin ở HTTP Header hay
có thể xem xét đến từng thông số hay cookies của các request...vv
- POST payload analysis: Ngoài việc cản lọc dựa trên HTTP Header, ModSecurity có thể dựa trên nội dung (payload) của POST requests.
- Audit logging: Mọi requests đều có thể được ghi lại (bao gồm cả POST) để người quản trị có thể theo dõi nếu cần.
- HTTPS filtering: ModSecurity có thể phân tích HTTPS.
- Compressed content filtering: ModSecurity sẽ phân tích sau khi đã giải nén các các dữ liệu được yêu cầu.
Hình 2.2 Quá trình xử lý các request của Apache và ModSecurity
Modsecurity cho phép chúng ta đặt rule tại một trong năm thời điểm trong chu kỳ xử lý của Apache như sau:
1. Phase Request Header: Rule được đặt tại đây sẽ được thực hiện ngay say khi Apache đọc request header, lúc này phần request body vẫn chưa được đọc.
2. Phase Request Body: Đây là thời điểm các thông tin chức
năng chung đưa vào vào được phân tích và xem xét, các rule mang tính ứng
dụng hướng kết nối (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. Modsecurity hỗ trợ ba loại mã hoá request body
+ application/x-www-form-urlencoded: Dùng để truyền form dữ liệu
+ multipart/form-data: Dùng để truyền file
+ text/xml: Dùng để phân tích dữ liệu XML
3. Phase Response Header: Đây là thời điểm ngay sau khi phần
response header được gửi trả về cho client. Chúng ta đặt rule ở đây nếu
muốn giám sát quá trình sau khi phần response được gửi đi.
4. Phase Response Body: Đây là thời điểm chúng ta muốn kiểm tra những dữ liệu HTML gửi trả về.
5. Phase logging: Là thời điểm các hoạt động log được thực
hiện, các rules đặt ở đây sẽ định rõ việc log sẽ như thế nào, nó sẽ kiểm
tra các error message log của Apache. Đây cũng là thời điểm cuối cùng
để chúng ta chặn các kết nối không mong muốn, kiểm tra các response
header mà chúng ta không thể kiểm tra ở phase 3 và phase 4.
2.3. CÀI ĐẶT VÀ CẤU HÌNH
(phần cài đặt được tham khảo từ một bài viết của forum ceh.vn, có một số chỉnh sửa cho phù hợp...)
Trước khi cài đặt, chúng ta phải đảm bảo web server Apache đã hoạt
động tốt. Distro Linux sử dụng là CentOS5 và phiên bản ModSecurity sử
dụng là 2.5. Có thể thực hiện trên các Distro khác như Ubuntu, Fedora...
- Thực hiện tải mã nguồn về
Code:
wget http://www.modsecurity.org/download/modsecurity-apache_2.5.11.tar.gz
.......
01:52:06 (161 KB/s) - `modsecurity-apache_2.5.11.tar.gz' saved [1338425/1338425]
- Thực hiện tra tính toàn vẹn của mã nguồn (việc này không bắt buộc
nhưng chúng ta nên có thói quen kiểm tra để đảm bảo rằng mã nguồn đã
không bị can thiệp vào dưới bất kỳ hình thức nào). Có thể sử dụng MD5
hay PGP để làm việc này. Ở đây sử dụng PGP
+ Đầu tiên cần download chữ ký :
Code:
wget http://www.modsecurity.org/download/modsecurity-apache_2.5.11.tar.gz.asc
......
02:04:38 (14.8 MB/s) - `modsecurity-apache_2.5.11.tar.gz.asc' saved [189/189]
+ Download Publick Key:
Code:
gpg --keyserver pgp.mit.edu --recv-key E77B534D
.....
gpg: Total number processed: 1
gpg: imported: 1
+ Kiểm tra chữ ký:
Code:
gpg --verify modsecurity-apache_2.5.11.tar.gz.asc
......
gpg: Good signature from "Brian Rectanus (work)"
gpg: aka "Brian Rectanus"
gpg: aka "Brian Rectanus (personal)"
- Kiểm tra thành công. Thực hiện giải nén mã nguồn:
Code:
tar xfvz modsecurity-apache_2.5.11.tar.gz
- Kiểm tra các gói thư viện cần thiết, ModSecurity yêu cầu có 4 thành phần sau trước khi biên dịch :
+ apxs : Kiểm tra bằng cách :
Code:
whereis -b apxs
......
apxs: /usr/sbin/apxs
Nếu chưa có, chúng ta phải cài thêm gói httpd-devel (hay apache2-dev đối với dòng debian,ubuntu.. )
Code:
yum install httpd-devel (hoặc apt-get install apache2-dev)
+ libxml2: Kiểm tra bằng cách :
Code:
whereis -b libxml2
......
libxml2: /usr/lib/libxml2.a /usr/lib/libxml2.so /usr/include/libxml2
Nếu chưa có, chúng ta phải cài thêm gói libxml2-devel (hay libxml2-dev đối với debian,ubuntu...)
Code:
yum install libxml2-devel (hoặc apt-get install libxml2-dev)
+ pcre: Kiểm tra bằng cách :
Code:
whereis pcre
......
pcre: /usr/include/pcre.h /usr/share/man/man3/pcre.3.gz
Nếu chưa có thì chúng ta phải cài thêm gói pcre-devel :
yum install pcre-devel (hoặc apt-get install pcre-dev)
+ mod_unique_id: Là mod thường đã được biên dịch cùng Apache. Có thể kiểm tra lại bằng cách tìm trong httpd.conf dòng:
Code:
LoadModule unique_id_module modules/mod_unique_id.so
Nếu chưa có, chúng ta phải thêm vào với nội dung như trên.
- Chuyển vào thư mục chứa mã nguồn và tiến hành biên dịch :
Code:
cd modsecurity-apache_2.5.11/apache2/
+ Tạo Make file :
Code:
./configure
......
configure: creating ./config.status
config.status: creating Makefile
config.status: creating build/apxs-wrapper
config.status: creating mlogc-src/mlogc-batch-load.pl
config.status: creating t/run-unit-tests.pl
config.status: creating t/run-regression-tests.pl
config.status: creating t/gen_rx-pm.pl
config.status: creating t/csv_rx-pm.pl
config.status: creating t/regression/server_root/conf/httpd.conf
config.status: creating ../tools/rules-updater.pl
config.status: creating mlogc-src/Makefile
config.status: creating mod_security2_config.h
+ Tiến hành biên dịch
Code:
make
Sau khi biên dịch thành công file mod_security2.so sẽ được tạo ra trong thư mục libs.
- Tích hợp ModSecurity vào Apache
Để Apache nhận ra sự tồn tại của ModSecurity chúng ta cần copy mod_security2.so đến thư mục chứa
modules của apache, đối với distro CentOS là /etc/httpd/modules
Code:
cp /libs/mod_security2.so /etc/httpd/modules/
Sửa lại file httpd.conf để thực hiện load module ModSecurity:
Code:
vi /etc/httpd/conf/httpd.conf
Thêm dòng
Code:
LoadModule security2_module modules/mod_security2.so
- Quy định file cấu hình ModSecurity
Chúng ta có thể cấu hình trực tiếp các thông số và rule của
ModSecurity vào file httpd.conf. Nhưng để cho rõ ràng và đảm bảo không
sai sót trong quá trình thực hiện - gây ảnh hưởng Apache, Chúng ta nên
tạo một file cấu hình riêng và sau đó include vào.
Trong CentOS các file cấu hình riêng mặc định chứa trong /etc/httpd/conf.d/
Code:
vi /etc/httpd/conf.d/modsecurity.conf
Thêm vào các thông số cấu hình cơ bản
Code:
# Bat che do loc cua Modsecurity
SecRuleEngine On
# Thiet lap action mac dinh
SecDefaultAction "phase:2,deny,log,status:404"
# rule thu nghiem block tat ca request co uri chua "hacker"
SecRule REQUEST_URI "hacker"
Thực hiện thử nghiệm để kiểm tra hoạt động của ModSecurity. Tiến
hành tạo 2 file trong thư mục web, hacker.html và index.html chẳng hạn.
Khi chúng ta truy cập vào file index.html thì trình duyệt trả về kết quả
bình thường
Còn khi truy cập vào hacker.html thì trình duyệt báo lỗi :
Code:
404 – Forbidden
Đó là kết quả do ModSecurity đã chặn những URI có chứa chuỗi hacker và cũng đồng nghĩa với việc ModSecurity đã hoạt động.
2.4. VIẾT RULES
2.4.1. Cú pháp SecRule
SecRule được sử dụng để tạo các rule cho ModSecurity . Cú pháp rất đơn giản
Code:
SecRule Target Operator [Actions]
Target (mục tiêu): Quy định cụ thể mục tiêu của request hoặc
response mà chúng ta muốn kiểm tra. Trong ví dụ kiểm cơ bản được đưa ra
trong phần trước, sử dụng biến có tên REQUEST_URI, trong đó có các URI được request trên server, để nhận diện và chặn bất cứ Client nào truy cập vào các vị trí /hacker.html. Hiện có hơn 70 biến có thể được sử dụng để tạo rule.
Ngoài ra còn có một loại biến đặc biệt được gọi là biến collection có thể chứa nhiều đối số. Một ví dụ về collection là ARGS, trong đó có chứa tất cả các đối số được truyền trong một chuỗi truy vấn hoặc thông qua một request POST.
Phần Operator xác định phương pháp và so sánh khớp dữ liệu để kích hoạt Action. Với Operator, mặc định là @rx
Cuối cùng, Actions (hành động) là một danh sách các hành
động được thực hiện nếu phù hợp (matching) rule. Action có thể là allow
(cho phép) hoặc deny (từ chối) các request; và quy định cụ thể các mã
trạng thái (status code) khi trả về (response) cho client. Nếu không có
action nào được quy định, các action mặc định của action
SecDefaultAction sẽ được sử dụng (rule chứa action này thường được khai
báo đầu tiên).
Để làm rõ hơn, chúng ta xem ví dụ. Giả sử chúng ta là một chủ doanh
nghiệp nhỏ bán sách dạy nấu ăn ở định dạng file PDF trên website. Để
lôi kéo khách hàng mua sách, chúng ta cung cấp một chương mẫu có chứa
các công thức nấu ăn ngon nhất trong cuốn sách, mà họ có thể tải về miễn
phí để xem trước khi quyết định mua.
Công việc kinh doanh đang ổn định, nhưng sau đó đột nhiên chúng ta
nhận được đơn khiếu nại qua email nói rằng trang web của chúng ta rất
chậm hoặc không truy cập được.
Khi nhìn vào log chúng ta nhận thấy rằng, một IP kết nối tới server
web tràn ngập với các request cho các chương mẫu. Các chuỗi user-agent
thấy được có tên Red Bullet Downloader . User-agent này của các chương trình Download nhanh.
Giải pháp đưa ra để giải quyết vấn đề này là dùng Mod Securiry để
ngăn chặn các user-agent này download. Rules được viết như sau.
Code:
SecRule REQUEST_HEADERS:User-Agent "Red Bullet" "deny,nolog"
Trong ví dụ trên, REQUEST_HEADERS là một Collection chứa tất
cả các trường trong thông điệp header (message header) được gởi đến
bởi client và trong header này chứa User-agent. Vì vậy, ta sử dụng từ
khoá cho user-agent là “Red Bullet” vì từ Red Bullet này thường xuyên
xuất hiện trong các header được gởi đển từ client. Và Action là deny –
là từ chối và nolog là không ghi lại log
2.4.1.1. Biến và bộ chọn lọc Collection
Hiện khoản hơn 70 biến có sẵn. ModSecurity sử dụng hai loại biến:
biến Standard, đơn giản chỉ chứa một giá trị duy nhất, và biến
Collection, có thể chứa nhiều hơn một giá trị. Một ví dụ về một
Collection là REQUEST_HEADERS, trong đó chứa tất cả các trường trong
thông điệp header mà Client gởi tới Server, chẳng hạn như User-agent
hoặc Referer.
Để truy cập vào một trường trong collection, chúng ta ghi tên
collection, tiếp theo là dấu hai chấm và sau đó là tên của trường hoặc
tuỳ chọn mà chúng ta muốn truy cập. Ví dụ:
Code:
SecRule REQUEST_HEADERS:Referer "bad-referer.com"
Trong trường hợp kiểm tra toàn bộ dữ liệu trên tất cả các
collection. Ví dụ, nếu chúng ta muốn kiểm tra sự hiện diện của chuỗi
script có thể sử dụng rules sau đây:
Code:
SecRule ARGS "script"
Nếu muốn kiểm tra thêm các chuỗi truy vấn được gửi là username=john&login=yes , chúng ta có thể mở rộng rule bằng cách.
Code:
SecRule ARGS:john|ARGS:login "script"
Các collection có sẵn trong ModSecutity 2.5
- ARGS
- ENV
- FILES
- FILES_NAMES
- FILES_SIZES
- FILES_TMPNAMES
- GEO
- IP
- REQUEST_COOKIES
- REQUEST_COOKIES_NAMES
- REQUEST_HEADERS
- REQUEST_HEADERS_NAMES
- RESPONSE_HEADERS
- RESPONSE_HEADERS_NAMES
- SESSION
- TX
- USER
2.4.1.2. Chuyển đổi giữa các Collection
TX Collection còn được gọi là các Transaction collection. Chúng ta có thể sử dụng nó để tạo ra các biến phục vụ riêng cho mình.
Code:
SecRule REQUEST_URI “passwd” “pass,setvar:tx.hackscore=+5”
SecRule TX:HACKSCORE “@gt 10” deny
Trong hai rule đầu tiên sử dụng action setvar để thiết lập các biến
collection. Thực hiện tạo biến hackscore và tăng giá trị lên 5 nếu rule
được thực thi (matching rule). Đến khi biến hackscore có giá trị bằng
10 thì thực thi rule thứ hai sẽ được thực thi với action là deny.
(Có thể loại bỏ biến bằng cách sử dụng setvar cú pháp setvar:!tx.hackscore)
2.4.1.3. Lưu trữ các Request
Có ba loại collection trong ModSecurity được sử dụng để lưu trữ
liên tục( persistent storage). Như phần trước đã trình bày, setvar giúp
tạo ra một biến và gán giá trị cho nó. Tuy nhiên, biến sẽ hết hạn và
không còn nữa khi các request hiện tại đã được xử lý. Trong một số
trường hợp chúng ta muốn lưu trữ giá trị biến và truy cập nó cho các
request sau này, có thể sử dụng kiểu lưu trữ này.
Có ba collection có thể được sử dụng cho mục đích này:
- IP
- SESSION
- USER
Collection IP được sử dụng để lưu trữ thông tin về IP của
người sử dụng. Nó có thể được sử dụng để lưu trữ IP ở các trường hợp
như: Số lần truy cập không thành công vào tài nguyên trên server, hoặc
số lượng các request của người dùng…
Trước khi sử dụng một trong các collection, chúng ta cần khởi tạo nó. Điều này được thực hiện bằng cách sử dụng các action initcol:
Code:
SecAction initcol:ip=%{REMOTE_ADDR},nolog,pass
Để thực hiện được rule trên, phải chắc chắn đã khai báo đường dẫn đến thư mục lưu trữ cho ModSecurity
Code:
SecDataDir /var/log/httpd/modsec_data
2.4.1.4. Kiểm tra nhiều biến
ModSecurity có thể kiểm tra nhiều biến cùng một lúc, mục đích để kết hợp so sánh (matching) một chuỗi.
Ví dụ:
Code:
SecRule ARGS|REQUEST_HEADERS "park" deny
Dấu (|) được sử dụng để tách các tên biến. Nó cũng có nhiều chức năng logic giống như “or” trong lập trình.
2.4.1.5. Sử dụng dấu “ khi viết rule
Chúng ta xem xét các rule sau
Code:
SecRule REQUEST_URI "secret" "deny"
SecRule REQUEST_URI secret deny
SecRule REQUEST_URI "secret place" deny
Hai rule đầu đều đúng và có tác dụng như nhau. Dấu (“) được sử dụng
để chứa các cụm từ cách nhau bởi có dấu space. Các đơn từ thì có thể
dùng hoặc không dùng.
Sử dụng (“) còn để nhóm các thông điệp ghi log.
Code:
SecRule REQUEST_URI "secret place" "deny,log,msg:'Someone tried to access the secret place!'"
Nếu chúng ta muốn đặt dấu (‘) trong thông điệp cần ghi log. Thực hiện chèn dấu (\) trước dấu (‘).
Code:
SecRule REQUEST_URI "secret place" "deny,log,msg:'Someone's trying to hack us!'"
2.4.1.6. Tạo rule kết chuỗi – chain
Để kết hợp nhiều rule hoạt động liên tiếp với nhau, ta sử dụng chain.
Ví dụ: Người quản trị web server muốn chặn một số người download
nhiều file gây ảnh hưởng đến web server, nhưng một số khách hàng khác
cũng download mà không gây ảnh hưởng đến webserver bởi họ chỉ download
vài file là xong và ta không chặn những người này. Và người quản trị
server quyết định chặn những người có user-agent có chứa “Red Bullet” và
IP của người này nằm trong dãy IP của một ISP xác định. Với từ chain
trong action. Sử dụng nó, chúng ta có thể tạo ra một chain rule mà nếu
phù hợp tất cả các rule trong chain thì action của chain sẽ được thực
hiện.
Ví dụ đây là rule cấm người dùng với user-agent có từ “Red Bullet”
Code:
SecRule REQUEST_HEADERS:User-agent “Red Bullet” deny
Rule thứ hai là chỉ những client nằm trong dãy IP 192.168.1.0-192.168.1.255:
Code:
SecRule REMOTE_ADDR “^192\.168\.1\.”
Để thoả mãn điều kiện đặt ra như trên, ta sử dụng rule chain để kết hợp hai rule trên:
Code:
SecRule REQUEST_HEADERS:User-agent “Red Bullet” “chain,deny” SecRule REMOTE_ADDR “^192\.168\.1\.”
Có thể thêm nhiều rule vào chain rule. Nếu chúng ta muốn thêm điều
kiện là các rule chỉ hoạt động trước 6:00 giờ tối, ta sẽ thêm một rule
thứ ba
Code:
SecRule REQUEST_HEADERS:User-agent “Red Bullet” “chain,deny”
SecRule REMOTE_ADDR “^192\.168\.1\.” “chain”
SecRule TIME_HOUR “@lt 18”
Từ @lt viết tắt của “less-than” là nhỏ hơn. Thuộc cú pháp so sánh số (matching number), sẽ được trình bày chi tiết ở phần 2.4.3.
2.4.1.7. Rule IDs
Chúng ta có thể quản lý các rule bằng cách đặt ID cho mỗi rule.
Code:
SecRule ARGS "login" "deny,id:1000"
Một số cú pháp thông thường
- SecRuleRemoveById:Gỡ bỏ rule có ID là
- SecRuleUpdateActionById: Cập nhật rule có ID là
2.1. GIỚI THIỆU MODSECURITY
ModSecurity là một Opensource web application firewall được Ivan
Ristic phát triển dành cho Web Server Apache. Ivan Ristic cũng là tác
giả quyển sách “Mod Security Handbook”. Ông là một người có rất nhiều
kinh nghiệm trong bảo vệ Web Server Apache. Ông đã có nhiều thời gian
nghiên cứu Web Application Security, Web Intrusion Detection, và
Security Patterns. Trước khi chuyển sang lĩnh vực security, Ivan đã có
nhiều năm làm việc như một Developer, System Architect, Technical
Director trong phát triển phần mềm. Ông là người sáng lập ra công ty
ThinkingStone làm các dịch vụ liên quan đến web application security.
Hiện tại ModSecurity sử dụng giấy phép GPL, hoàn toàn miễn phí
2.2. CÁC KHẢ NĂNG CỦA MODSECURITY
Hình 2.1 Mô hình tổng quan của ModSecurity
- Request filtering: Tất cả các request gửi đến web server
đều được phân tích và cản lọc (filter) trước khi chúng được đưa đến các
modules khác để xử lý
- Understanding of the HTTP protocol: ModSecurity là một
tường lửa ứng dụng nên nó có khả năng hiểu được giao thức HTTP.
ModSecurity có khả năng cản lọc dựa trên các thông tin ở HTTP Header hay
có thể xem xét đến từng thông số hay cookies của các request...vv
- POST payload analysis: Ngoài việc cản lọc dựa trên HTTP Header, ModSecurity có thể dựa trên nội dung (payload) của POST requests.
- Audit logging: Mọi requests đều có thể được ghi lại (bao gồm cả POST) để người quản trị có thể theo dõi nếu cần.
- HTTPS filtering: ModSecurity có thể phân tích HTTPS.
- Compressed content filtering: ModSecurity sẽ phân tích sau khi đã giải nén các các dữ liệu được yêu cầu.
Hình 2.2 Quá trình xử lý các request của Apache và ModSecurity
Modsecurity cho phép chúng ta đặt rule tại một trong năm thời điểm trong chu kỳ xử lý của Apache như sau:
1. Phase Request Header: Rule được đặt tại đây sẽ được thực hiện ngay say khi Apache đọc request header, lúc này phần request body vẫn chưa được đọc.
2. Phase Request Body: Đây là thời điểm các thông tin chức
năng chung đưa vào vào được phân tích và xem xét, các rule mang tính ứng
dụng hướng kết nối (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. Modsecurity hỗ trợ ba loại mã hoá request body
+ application/x-www-form-urlencoded: Dùng để truyền form dữ liệu
+ multipart/form-data: Dùng để truyền file
+ text/xml: Dùng để phân tích dữ liệu XML
3. Phase Response Header: Đây là thời điểm ngay sau khi phần
response header được gửi trả về cho client. Chúng ta đặt rule ở đây nếu
muốn giám sát quá trình sau khi phần response được gửi đi.
4. Phase Response Body: Đây là thời điểm chúng ta muốn kiểm tra những dữ liệu HTML gửi trả về.
5. Phase logging: Là thời điểm các hoạt động log được thực
hiện, các rules đặt ở đây sẽ định rõ việc log sẽ như thế nào, nó sẽ kiểm
tra các error message log của Apache. Đây cũng là thời điểm cuối cùng
để chúng ta chặn các kết nối không mong muốn, kiểm tra các response
header mà chúng ta không thể kiểm tra ở phase 3 và phase 4.
2.3. CÀI ĐẶT VÀ CẤU HÌNH
(phần cài đặt được tham khảo từ một bài viết của forum ceh.vn, có một số chỉnh sửa cho phù hợp...)
Trước khi cài đặt, chúng ta phải đảm bảo web server Apache đã hoạt
động tốt. Distro Linux sử dụng là CentOS5 và phiên bản ModSecurity sử
dụng là 2.5. Có thể thực hiện trên các Distro khác như Ubuntu, Fedora...
- Thực hiện tải mã nguồn về
Code:
wget http://www.modsecurity.org/download/modsecurity-apache_2.5.11.tar.gz
.......
01:52:06 (161 KB/s) - `modsecurity-apache_2.5.11.tar.gz' saved [1338425/1338425]
- Thực hiện tra tính toàn vẹn của mã nguồn (việc này không bắt buộc
nhưng chúng ta nên có thói quen kiểm tra để đảm bảo rằng mã nguồn đã
không bị can thiệp vào dưới bất kỳ hình thức nào). Có thể sử dụng MD5
hay PGP để làm việc này. Ở đây sử dụng PGP
+ Đầu tiên cần download chữ ký :
Code:
wget http://www.modsecurity.org/download/modsecurity-apache_2.5.11.tar.gz.asc
......
02:04:38 (14.8 MB/s) - `modsecurity-apache_2.5.11.tar.gz.asc' saved [189/189]
+ Download Publick Key:
Code:
gpg --keyserver pgp.mit.edu --recv-key E77B534D
.....
gpg: Total number processed: 1
gpg: imported: 1
+ Kiểm tra chữ ký:
Code:
gpg --verify modsecurity-apache_2.5.11.tar.gz.asc
......
gpg: Good signature from "Brian Rectanus (work)
gpg: aka "Brian Rectanus
gpg: aka "Brian Rectanus (personal)
- Kiểm tra thành công. Thực hiện giải nén mã nguồn:
Code:
tar xfvz modsecurity-apache_2.5.11.tar.gz
- Kiểm tra các gói thư viện cần thiết, ModSecurity yêu cầu có 4 thành phần sau trước khi biên dịch :
+ apxs : Kiểm tra bằng cách :
Code:
whereis -b apxs
......
apxs: /usr/sbin/apxs
Nếu chưa có, chúng ta phải cài thêm gói httpd-devel (hay apache2-dev đối với dòng debian,ubuntu.. )
Code:
yum install httpd-devel (hoặc apt-get install apache2-dev)
+ libxml2: Kiểm tra bằng cách :
Code:
whereis -b libxml2
......
libxml2: /usr/lib/libxml2.a /usr/lib/libxml2.so /usr/include/libxml2
Nếu chưa có, chúng ta phải cài thêm gói libxml2-devel (hay libxml2-dev đối với debian,ubuntu...)
Code:
yum install libxml2-devel (hoặc apt-get install libxml2-dev)
+ pcre: Kiểm tra bằng cách :
Code:
whereis pcre
......
pcre: /usr/include/pcre.h /usr/share/man/man3/pcre.3.gz
Nếu chưa có thì chúng ta phải cài thêm gói pcre-devel :
yum install pcre-devel (hoặc apt-get install pcre-dev)
+ mod_unique_id: Là mod thường đã được biên dịch cùng Apache. Có thể kiểm tra lại bằng cách tìm trong httpd.conf dòng:
Code:
LoadModule unique_id_module modules/mod_unique_id.so
Nếu chưa có, chúng ta phải thêm vào với nội dung như trên.
- Chuyển vào thư mục chứa mã nguồn và tiến hành biên dịch :
Code:
cd modsecurity-apache_2.5.11/apache2/
+ Tạo Make file :
Code:
./configure
......
configure: creating ./config.status
config.status: creating Makefile
config.status: creating build/apxs-wrapper
config.status: creating mlogc-src/mlogc-batch-load.pl
config.status: creating t/run-unit-tests.pl
config.status: creating t/run-regression-tests.pl
config.status: creating t/gen_rx-pm.pl
config.status: creating t/csv_rx-pm.pl
config.status: creating t/regression/server_root/conf/httpd.conf
config.status: creating ../tools/rules-updater.pl
config.status: creating mlogc-src/Makefile
config.status: creating mod_security2_config.h
+ Tiến hành biên dịch
Code:
make
Sau khi biên dịch thành công file mod_security2.so sẽ được tạo ra trong thư mục libs.
- Tích hợp ModSecurity vào Apache
Để Apache nhận ra sự tồn tại của ModSecurity chúng ta cần copy mod_security2.so đến thư mục chứa
modules của apache, đối với distro CentOS là /etc/httpd/modules
Code:
cp /libs/mod_security2.so /etc/httpd/modules/
Sửa lại file httpd.conf để thực hiện load module ModSecurity:
Code:
vi /etc/httpd/conf/httpd.conf
Thêm dòng
Code:
LoadModule security2_module modules/mod_security2.so
- Quy định file cấu hình ModSecurity
Chúng ta có thể cấu hình trực tiếp các thông số và rule của
ModSecurity vào file httpd.conf. Nhưng để cho rõ ràng và đảm bảo không
sai sót trong quá trình thực hiện - gây ảnh hưởng Apache, Chúng ta nên
tạo một file cấu hình riêng và sau đó include vào.
Trong CentOS các file cấu hình riêng mặc định chứa trong /etc/httpd/conf.d/
Code:
vi /etc/httpd/conf.d/modsecurity.conf
Thêm vào các thông số cấu hình cơ bản
Code:
# Bat che do loc cua Modsecurity
SecRuleEngine On
# Thiet lap action mac dinh
SecDefaultAction "phase:2,deny,log,status:404"
# rule thu nghiem block tat ca request co uri chua "hacker"
SecRule REQUEST_URI "hacker"
Thực hiện thử nghiệm để kiểm tra hoạt động của ModSecurity. Tiến
hành tạo 2 file trong thư mục web, hacker.html và index.html chẳng hạn.
Khi chúng ta truy cập vào file index.html thì trình duyệt trả về kết quả
bình thường
Còn khi truy cập vào hacker.html thì trình duyệt báo lỗi :
Code:
404 – Forbidden
Đó là kết quả do ModSecurity đã chặn những URI có chứa chuỗi hacker và cũng đồng nghĩa với việc ModSecurity đã hoạt động.
2.4. VIẾT RULES
2.4.1. Cú pháp SecRule
SecRule được sử dụng để tạo các rule cho ModSecurity . Cú pháp rất đơn giản
Code:
SecRule Target Operator [Actions]
Target (mục tiêu): Quy định cụ thể mục tiêu của request hoặc
response mà chúng ta muốn kiểm tra. Trong ví dụ kiểm cơ bản được đưa ra
trong phần trước, sử dụng biến có tên REQUEST_URI, trong đó có các URI được request trên server, để nhận diện và chặn bất cứ Client nào truy cập vào các vị trí /hacker.html. Hiện có hơn 70 biến có thể được sử dụng để tạo rule.
Ngoài ra còn có một loại biến đặc biệt được gọi là biến collection có thể chứa nhiều đối số. Một ví dụ về collection là ARGS, trong đó có chứa tất cả các đối số được truyền trong một chuỗi truy vấn hoặc thông qua một request POST.
Phần Operator xác định phương pháp và so sánh khớp dữ liệu để kích hoạt Action. Với Operator, mặc định là @rx
Cuối cùng, Actions (hành động) là một danh sách các hành
động được thực hiện nếu phù hợp (matching) rule. Action có thể là allow
(cho phép) hoặc deny (từ chối) các request; và quy định cụ thể các mã
trạng thái (status code) khi trả về (response) cho client. Nếu không có
action nào được quy định, các action mặc định của action
SecDefaultAction sẽ được sử dụng (rule chứa action này thường được khai
báo đầu tiên).
Để làm rõ hơn, chúng ta xem ví dụ. Giả sử chúng ta là một chủ doanh
nghiệp nhỏ bán sách dạy nấu ăn ở định dạng file PDF trên website. Để
lôi kéo khách hàng mua sách, chúng ta cung cấp một chương mẫu có chứa
các công thức nấu ăn ngon nhất trong cuốn sách, mà họ có thể tải về miễn
phí để xem trước khi quyết định mua.
Công việc kinh doanh đang ổn định, nhưng sau đó đột nhiên chúng ta
nhận được đơn khiếu nại qua email nói rằng trang web của chúng ta rất
chậm hoặc không truy cập được.
Khi nhìn vào log chúng ta nhận thấy rằng, một IP kết nối tới server
web tràn ngập với các request cho các chương mẫu. Các chuỗi user-agent
thấy được có tên Red Bullet Downloader . User-agent này của các chương trình Download nhanh.
Giải pháp đưa ra để giải quyết vấn đề này là dùng Mod Securiry để
ngăn chặn các user-agent này download. Rules được viết như sau.
Code:
SecRule REQUEST_HEADERS:User-Agent "Red Bullet" "deny,nolog"
Trong ví dụ trên, REQUEST_HEADERS là một Collection chứa tất
cả các trường trong thông điệp header (message header) được gởi đến
bởi client và trong header này chứa User-agent. Vì vậy, ta sử dụng từ
khoá cho user-agent là “Red Bullet” vì từ Red Bullet này thường xuyên
xuất hiện trong các header được gởi đển từ client. Và Action là deny –
là từ chối và nolog là không ghi lại log
2.4.1.1. Biến và bộ chọn lọc Collection
Hiện khoản hơn 70 biến có sẵn. ModSecurity sử dụng hai loại biến:
biến Standard, đơn giản chỉ chứa một giá trị duy nhất, và biến
Collection, có thể chứa nhiều hơn một giá trị. Một ví dụ về một
Collection là REQUEST_HEADERS, trong đó chứa tất cả các trường trong
thông điệp header mà Client gởi tới Server, chẳng hạn như User-agent
hoặc Referer.
Để truy cập vào một trường trong collection, chúng ta ghi tên
collection, tiếp theo là dấu hai chấm và sau đó là tên của trường hoặc
tuỳ chọn mà chúng ta muốn truy cập. Ví dụ:
Code:
SecRule REQUEST_HEADERS:Referer "bad-referer.com"
Trong trường hợp kiểm tra toàn bộ dữ liệu trên tất cả các
collection. Ví dụ, nếu chúng ta muốn kiểm tra sự hiện diện của chuỗi
script có thể sử dụng rules sau đây:
Code:
SecRule ARGS "script"
Nếu muốn kiểm tra thêm các chuỗi truy vấn được gửi là username=john&login=yes , chúng ta có thể mở rộng rule bằng cách.
Code:
SecRule ARGS:john|ARGS:login "script"
Các collection có sẵn trong ModSecutity 2.5
- ARGS
- ENV
- FILES
- FILES_NAMES
- FILES_SIZES
- FILES_TMPNAMES
- GEO
- IP
- REQUEST_COOKIES
- REQUEST_COOKIES_NAMES
- REQUEST_HEADERS
- REQUEST_HEADERS_NAMES
- RESPONSE_HEADERS
- RESPONSE_HEADERS_NAMES
- SESSION
- TX
- USER
2.4.1.2. Chuyển đổi giữa các Collection
TX Collection còn được gọi là các Transaction collection. Chúng ta có thể sử dụng nó để tạo ra các biến phục vụ riêng cho mình.
Code:
SecRule REQUEST_URI “passwd” “pass,setvar:tx.hackscore=+5”
SecRule TX:HACKSCORE “@gt 10” deny
Trong hai rule đầu tiên sử dụng action setvar để thiết lập các biến
collection. Thực hiện tạo biến hackscore và tăng giá trị lên 5 nếu rule
được thực thi (matching rule). Đến khi biến hackscore có giá trị bằng
10 thì thực thi rule thứ hai sẽ được thực thi với action là deny.
(Có thể loại bỏ biến bằng cách sử dụng setvar cú pháp setvar:!tx.hackscore)
2.4.1.3. Lưu trữ các Request
Có ba loại collection trong ModSecurity được sử dụng để lưu trữ
liên tục( persistent storage). Như phần trước đã trình bày, setvar giúp
tạo ra một biến và gán giá trị cho nó. Tuy nhiên, biến sẽ hết hạn và
không còn nữa khi các request hiện tại đã được xử lý. Trong một số
trường hợp chúng ta muốn lưu trữ giá trị biến và truy cập nó cho các
request sau này, có thể sử dụng kiểu lưu trữ này.
Có ba collection có thể được sử dụng cho mục đích này:
- IP
- SESSION
- USER
Collection IP được sử dụng để lưu trữ thông tin về IP của
người sử dụng. Nó có thể được sử dụng để lưu trữ IP ở các trường hợp
như: Số lần truy cập không thành công vào tài nguyên trên server, hoặc
số lượng các request của người dùng…
Trước khi sử dụng một trong các collection, chúng ta cần khởi tạo nó. Điều này được thực hiện bằng cách sử dụng các action initcol:
Code:
SecAction initcol:ip=%{REMOTE_ADDR},nolog,pass
Để thực hiện được rule trên, phải chắc chắn đã khai báo đường dẫn đến thư mục lưu trữ cho ModSecurity
Code:
SecDataDir /var/log/httpd/modsec_data
2.4.1.4. Kiểm tra nhiều biến
ModSecurity có thể kiểm tra nhiều biến cùng một lúc, mục đích để kết hợp so sánh (matching) một chuỗi.
Ví dụ:
Code:
SecRule ARGS|REQUEST_HEADERS "park" deny
Dấu (|) được sử dụng để tách các tên biến. Nó cũng có nhiều chức năng logic giống như “or” trong lập trình.
2.4.1.5. Sử dụng dấu “ khi viết rule
Chúng ta xem xét các rule sau
Code:
SecRule REQUEST_URI "secret" "deny"
SecRule REQUEST_URI secret deny
SecRule REQUEST_URI "secret place" deny
Hai rule đầu đều đúng và có tác dụng như nhau. Dấu (“) được sử dụng
để chứa các cụm từ cách nhau bởi có dấu space. Các đơn từ thì có thể
dùng hoặc không dùng.
Sử dụng (“) còn để nhóm các thông điệp ghi log.
Code:
SecRule REQUEST_URI "secret place" "deny,log,msg:'Someone tried to access the secret place!'"
Nếu chúng ta muốn đặt dấu (‘) trong thông điệp cần ghi log. Thực hiện chèn dấu (\) trước dấu (‘).
Code:
SecRule REQUEST_URI "secret place" "deny,log,msg:'Someone's trying to hack us!'"
2.4.1.6. Tạo rule kết chuỗi – chain
Để kết hợp nhiều rule hoạt động liên tiếp với nhau, ta sử dụng chain.
Ví dụ: Người quản trị web server muốn chặn một số người download
nhiều file gây ảnh hưởng đến web server, nhưng một số khách hàng khác
cũng download mà không gây ảnh hưởng đến webserver bởi họ chỉ download
vài file là xong và ta không chặn những người này. Và người quản trị
server quyết định chặn những người có user-agent có chứa “Red Bullet” và
IP của người này nằm trong dãy IP của một ISP xác định. Với từ chain
trong action. Sử dụng nó, chúng ta có thể tạo ra một chain rule mà nếu
phù hợp tất cả các rule trong chain thì action của chain sẽ được thực
hiện.
Ví dụ đây là rule cấm người dùng với user-agent có từ “Red Bullet”
Code:
SecRule REQUEST_HEADERS:User-agent “Red Bullet” deny
Rule thứ hai là chỉ những client nằm trong dãy IP 192.168.1.0-192.168.1.255:
Code:
SecRule REMOTE_ADDR “^192\.168\.1\.”
Để thoả mãn điều kiện đặt ra như trên, ta sử dụng rule chain để kết hợp hai rule trên:
Code:
SecRule REQUEST_HEADERS:User-agent “Red Bullet” “chain,deny” SecRule REMOTE_ADDR “^192\.168\.1\.”
Có thể thêm nhiều rule vào chain rule. Nếu chúng ta muốn thêm điều
kiện là các rule chỉ hoạt động trước 6:00 giờ tối, ta sẽ thêm một rule
thứ ba
Code:
SecRule REQUEST_HEADERS:User-agent “Red Bullet” “chain,deny”
SecRule REMOTE_ADDR “^192\.168\.1\.” “chain”
SecRule TIME_HOUR “@lt 18”
Từ @lt viết tắt của “less-than” là nhỏ hơn. Thuộc cú pháp so sánh số (matching number), sẽ được trình bày chi tiết ở phần 2.4.3.
2.4.1.7. Rule IDs
Chúng ta có thể quản lý các rule bằng cách đặt ID cho mỗi rule.
Code:
SecRule ARGS "login" "deny,id:1000"
Một số cú pháp thông thường
- SecRuleRemoveById:Gỡ bỏ rule có ID là
- SecRuleUpdateActionById: Cập nhật rule có ID là
