1.8.Tường lửa cho ứng dụng Mod_Security
ModSecurity 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ặc 1 web application firewall). Hoạt động như một module của máy chủ web Apache, mục đích của ModSecurity là tăng cường bảo mật cho các ứng dụng web, bảo vệ chúng khỏi các loại tấn công đã biết và chưa biết.
Hình 3.23. Hình minh họa tường lửa Mod_Security
Sau khi cài đặt Apache mặc định sẽ không có mod_security. Ta phải download mod_security từ http://www.modsecurity.org về và cài đặt.
1.8.1.Các khả năng của mod_security
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ý. Anti-evasion techniques : paths và parameters được chuẩn hoá trước khi phân tích để chống evasion techniques. Kỹ thuật này sẽ được thảo luận ở phần sau.
Hình 3.24. Quy trình xử lý các request của Apache và Mod_Security
Understanding of the HTTP protocol: mod_security là web application firewall nên nó có khả năng hiểu được HTTP protocol. Mod_security 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 parameters hay cookies của các requests ...vv.
POST payload analysis: ngoài việc cản lọc dựa trên HTTP Header, mod_security 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 ) để chúng ta có thể xem xét sau nếu cần.
HTTPS filtering: mod_security có thể phân tích HTTPS.
Compressed content filtering: mod_security sẽ phân tích sau khi đã decompress các request data.
1.8.2.Cấu hình cơ bản -
File cấu hình
Mod_security là application firewall thuộc loại rules-based, nghĩa chúng ta cần thiết lập các luật (rules) để mod_security hoạt động. Các rules này được thể hiện dưới dạng các chỉ thị (directives) và có thể đặt trực tiếp trong file cấu hình Apache (thông thường là httpd.conf).Khi chúng ta không biết chắc chắn mod_security đã được kích hoạt hay chưa thì có thể đặt các cấu hình.
Code:
#Modsecurity configuration
#.....
Ngoài ra có thể đặt các cấu hình này vào một file riêng, chẳng hạn modsecurity.conf và sau đó chúng ta cần thêm vào httpd.conf:
Code:
Include conf/modsecurity.conf
-
Turning Filtering on and off
Mặc định mod_security sẽ không kiểm tra các POST payload (nội dung của POST), để kiểm tra cả POST payload tả sẽ sử dụng.
SecFilterScanPOST On
mod_security hỗ trợ 2 loại encoding:
-
application/x-www-form-urlencoded - used to transfer form data
-
multipart/form-data – used for file transfers
1.8.3.Rules
Rules là phần quan trọng nhất đối với một rule-based firewall và cũng là phần dễ nhàm chán nhất. Ở phần này thay vì liệt kê các rules có thể của mod_security, chúng tôi đề cập tới cách viết một rule thế nào.
Trước hết là ta phải hiểu về:
Cơ bản về giao thức http: Trong phạm vi của đề tài này chúng tôi không giới thiệu về giao thức này một cách căn kẽ.
Có thể sử dụng Regular Expression: tạm dịch là biểu thức chính quy, đây 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ự . Regular Expression được viết tắt là regex. Tham khảo quyển sách “Mastering Regular Expression” của NXB O'reilly hoặc nhờ Google với từ khoá “regular expression”.
-
Xây dựng rules
Hãy bật browse lên và vào site modsecurity.org, dùng một chương trình nào đó để capture lại các gói tin, chẳng hạn ethereal, chúng ta sẽ thu được:
Code:
GET /documentation/index.html HTTP/1.1
Host: www.modsecurity.org
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.1) Gecko/20060124 Firefox/1.5.0.1
Accept:
text/xml,application/xml,application/xhtml+xml, text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive
Referer: http://www.modsecurity.org/index.php
Cookie:__utmz=129890064.1139909500.1.1.utmccn=(direct)| utmcsr=(direct)|utmcmd=(none); __utma=129890064.347942152.1139909500. 1140275483.1140425527.13; __utmb=129890064; __utmc=129890064
Xem xét request ở trên chúng ta có thể thấy các HTTP Header sau :
Code:
GET – Đây là request method
Host
User-Agent
Accept
Accept-Language
Accept-Encoding
Accept-Encoding
Keep-Alive
Connection
Referer
Mod_security sẽ sử dụng thông tin này trong các rules của nó để cản lọc các requests, tất cả các thông tin trong header đều được sử dụng để viết các rules. Và không chỉ trong header, mod_security cũng có thể xem xét cả POST payload như đã nhắc tới ở trên, ...
Hãyxem xét ví dụ sau đây :
-
Không cho phép các request có Referer là www.abc.com thì sẽ dùng rule sau: SecFilterSelective HTTP_Referer “www\.abc\.com”
-
Không cho phép User-Agent có từ HotBar: SecFilterSelective HTTP_User-Agent “HotBar”
Qua 2 ví dụ này ta thấy được cách thức làm việc với các HTTP header, và không chỉ dừng lại ở đó mod_security thậm chí còn có thể hiểu được những header khác không được đề cập ở trong RFC. Chẳng hạn tôi có một header có tên là Conmaz thì tôi có thể viết rule là:
Code:
SecFilterSelective HTTP_Conmaz “^$”
Ngoài SecFilterSelective ra mod_security còn có một directive nữa cũng dùng với mục đích cản lọc đó là SecFilter. SecFilter được dùng rất đơn giản, nếu chúng ta muốn cản lọc một từ khoá nào đó ở bất cứ vị trí nào trong gói tin HTTP thì chỉ cần : SecFilter keyword
Code:
SecFilter /bin/sh
-
Cấu trúc của Filtering Rules
Chúng ta hãy xem xét cấu trúc chi tiết của các filtering rules
Code:
SecFilter KEYWORD [ACTIONS]
SecFilterSelective LOCATION KEYWORD [ACTIONS]
Locations
Như các bạn đã thấy ở các ví dụ trên LOCATION ở đây có thể là tất cả các field trong HTTP Header. Dưới đây là liệt kê những LOCATION mà bạn có thể sử dụng trong SecFilterSelective
Code:
REMOTE_ADDR: Địa chỉ IP của client
REMOTE_HOST: hostname của client (nếu tồn tại)
REMOTE_USER : Authenticated username (nếu tồn tại)
REMOTE_IDENT : Remote Username (lấy từ inetd, ít dùng)
REQUEST_METHOD : Request Method (GET, HEAD, POST..)
SCRIPT_FILENAME : Đường dẫn đầy đủ của script thực thi
PATH_INFO : Phần mở rộng của URI phía sau tên của một script, ví dụ /archive.php/5 thì PATH_INFO là /5
QUERY_STRING : URI phía sau dấu ?. Ví dụ /index.php?i=1 thì QUERY_STRING là i=1
AUTH_TYPE : Basic hoặc Digest Authentication
DOCUMENT_ROOT : đường dẫn đến documentroot
SERVER_ADMIN : email của Server Administrator
SERVER_NAME : hostname của Server
SERVER_ADDR : Địa chỉ IP của Server
SERVER_PORT : Server port
SERVER_PROTOCOL : protocol, (ví dụ HTTP/1.1)
SERVER_SOFTWARE : Apache version
TIME_YEAR : Năm hiện tại (2010)
TIME_MON : Tháng hiện tại (11)
TIME_DAY : Ngày
TIME_HOUR : Giờ
TIME_MIN : Phút
TIME_SEC : Giây
TIME_WDAY : Thứ tự ngày trong tuần (ví dụ 4 - Thursday)
TIME : Thời điểm hiện tại được viết theo cấu trúc : YmdHMS ví dụ 20101112144530 : 12/11/2010 14h 45' 30''
API_VERSION
THE_REQUEST : dòng đầu tiên của request. vd: GET / HTTP/1.1
REQUEST_URI : Request URI
REQUEST_FILENAME : Tên file được yêu cầu đến.
IS_SUBREQ
Một vài LOCATION đặc biệt :
Code :
POST_PAYLOAD – POST payload (nội dung của POST hay POST body)
ARGS - filter arguments,giống như QUERY_STRING|POST_PAYLOAD
ARGS_NAMES – variable/parameter names only
ARGS_VALUES – variable/parameter values only
COOKIES_NAMES - cookie names only
COOKIES_VALUES - cookie values only
SCRIPT_UID
SCRIPT_GID
SCRIPT_USERNAME
SCRIPT_GROUPNAME
SCRIPT_MODE
ARGS_COUNT
COOKIES_COUNT
HEADERS
HEADERS_COUNT
HEADERS_NAMES
HEADERS_VALUES
FILES_COUNTHTTP_header – search request header "header"
ENV_variable – search environment variable variable
ARG_variable – search request variable/parameter variable
COOKIE_name - search cookie with name name
FILE_NAME_variable - search the filename of the file uploaded under the name variable.
FILE_SIZE_variable - search the size of the file uploaded under the name variable
FILES_NAMES
FILES_SIZES
Thậm chí còn có vài LOCATION đặc biệt hơn:
Code:
HTTP_header – search request header "header"
ENV_variable – search environment variable variable
ARG_variable – search request variable/parameter variable
COOKIE_name - search cookie with name name
FILE_NAME_variable - search the filename of the file uploaded under the name variable.
FILE_SIZE_variable - search the size of the file uploaded under the name variable
LOCATION có thể bao gồm hai hoặc nhiều các location đã được liệt kê
Code:
SecFilterSelective "REMOTE_ADDR|REMOTE_HOST" KEYWORD
Actions
Khi request vi phạm một rule nào đó thì mod_security sẽ thực thi một hành động (action). Khi action không được chỉ rõ trong rule thì rule đó 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 rule chỉ có một primary action. Có 4 primary actions :
deny : Request sẽ bị ngắt, mod_security sẽ trả về HTTP status code 500 hoặc là status code của bạn thiết lập trong chỉ thị status:
SecFilter xxx "deny,status:403"
pass : Cho phép request tiếp tục được xử lý ở các rules tiếp theo
SecFilter secret "log,pass"
allow : Giống Pass tuy nhiên Request sẽ được cho phép và không bị kiểm tra ở các rules tiếp theo
SecFilterSelective REMOTE_ADDR "^192\.168\.2\.99$" allow
redirect : Redirect một request đến một url nào đó.
SecFilter /bin/sh "redirect:http://www.conmaz.com"
Secondary Actions
Secondary actions sẽ bổ sung cho Primary actions, một rule có thể có nhiều Secondary actions
Code:
status : n khi một Request vi phạm một rule nào đó thì mod_security có thể trả về các HTTP status code n thay vì status code 500 mặc định.
SecFilterSelective “HTTP_Referer” “xxx.com” “deny,status:403”
exec : thực thi một lệnh nào đó nếu một request vi phạm
SecFilter /etc/passwd "exec:/usr/local/bin/report-attack.pl"
log : ghi log những request vi phạm rule
nolog : không ghi log
pause : n mod_security sẽ đợi một thời gian n ms rồi mới trả về kết quả.
Flow Actions:
Code:
chain: kết nối 2 hay nhiều rules lại với nhau
Ví dụ: chúng ta sẽ redirect một GET request về (conmaz.com/index.html) nếu không đúng Referer và không có cookie có tên là rocker
Code:
SecFilterSelective “REQUEST_METHOD” “^GET$”
SecFilterSelective “HTTP_REFERER” “!(www\.conmaz\.com|^$)” chain
SecFilterSelective “COOKIE_rocker” “^$” “redirect:http://www.conmaz.com/index.html”
skipnext:n mod_security sẽ bỏ qua n rules theo sau nó
SecFilterSelective ARG_p value1 skipnext:2
SecFilterSelective ARG_p value2
SecFilterSelective ARG_p value3
Default Action
Khi một rule không chỉ rõ action thì rule đó sẽ dùng default action được thiết lập trong SecFilterDefaultAction.
SecFilterDefaultAction “deny,log,status:403”
Filter inheritance
Các rules thiết lập ở ngữ cảnh cha (parent context) sẽ được thừa kế ở ngữ cảnh con (child context) , đây là điều chấp nhận được. Tuy nhiên có nhiều trường hợp chúng ta không muốn thừa kế các Rules đó thì có thể sử dụng SecFilterInheritance directive. Ví dụ:
Code:
SecFilterInheritance Off
#......
Khi SecFilterInheritance off ở ngữ cảnh (context) nào đó (ví dụ trên là file view.php) thì chúng ta phải viết rules từ đầu tại ngữ cảnh đó. Thỉnh thoảng chúng ta chỉ muốn một vài thay đổi nhỏ và nếu sử dụng SecFilterInheritance thì phải viết lại rules từ đầu khá mất công, chính vì thế mod_security cung cấp thêm 2 directives để giảm thiểu số lượng rules phải viết:
Code:
SecFilterImport – Import một rule ở parent context.
SecFilterRemove – Remove một rule ở parent context
Ta sẽ sử dụng id vào cuối mỗi rule để định danh và sẽ được sử dụng trong 2 directives trên:
Code: (Ví dụ 1)
SecFilter XXX id:1001
SecFilter YYY id:1002
SecFilter ZZZ id:1003
SecFilterInheritance Off
SecFilterImport 1003
Code: (Ví dụ 2)
SecFilter XXX id:1001
SecFilter YYY id:1002
SecFilter ZZZ id:1003
SecFilterRemove 1001 1002
1.8.4.Logging -
Debug Log
Sử dụng SecFilterDebugLog directive lựa chọn file để ghi lại các thông tin debug
Code:
SecFilterDebugLog logs/modsec_debug_log
Có thể thay đổi mức độ chi tiết các thông tin được log thông qua directive:
Code:
SecFilterDebugLevel 4
Giá trị log có thể thay đổi từ 0-9 :
Code:
0 - none (this value should always be used on production systems)
1 - significant events (these will also be reported in the error_log)
2 - info messages
3 - more detailed info messages
....
-
-
Audit logging
Apache log ít thông tin vì thế nó không cho phép chúng ta có thể lần ngược các bước của kẻ tấn công. Mod_security 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 rules cho hợp lý tránh bị “false positive”. Có hai directives:
Code:
SecAuditEngine On
SecAuditLog logs/audit_log
Đây là một ví dụ của audit log:
Code :
==378bfd37==============================
Request: conmaz.com 203.160.1.170 - - [20/Feb/2006:02:21:52 --0600] "GET /favicon.ico HTTP/1.1" 403 285 "-" "-" - "-"
----------------------------------------
GET /favicon.ico HTTP/1.1
Cookie: rocker=r0xker
Host: conmaz.com
Connection: Keep-Alive
mod_security-message: Access denied with code 403. Pattern match "^$" at HEADER("User-Agent")
mod_security-action: 403
HTTP/1.1 403 Forbidden
Content-Length: 285
Keep-Alive: timeout=5, max=29
Connection: Keep-Alive
Content-Type: text/html; charset=iso-8859-1
--378bfd37—
Khi SecFilterScanPOST on thì POST payload sẽ luôn được kèm theo trong audit log
-
Tùy biến thông tin log
SecAuditEngine chấp nhận 4 giá trị sau :
Code:
On – log tất cả các requests
Off – không log
RelevantOnly – chỉ log những gì được sinh ra bởi các filtering rules
DynamicOrRelevant – log những request tạo ra nội dung động hoặc những requests được sinh ra bởi các filtering rules.
Ngoài ra mod_security còn hỗ trợ log dựa vào status code , ví dụ bạn cần log lại những requests gây ra lỗi 5xx :
Code:
SecAuditLogRelevantStatus ^5
CHƯƠNG 4: XÂY DỰNG MÔ HÌNH THỬ NGHIỆM ÁP DỤNG MÃ NGUỒN MỞ VÀO TĂNG CƯỜNG BẢO MẬT HỆ THỐNG 1.9.Thực tế tại Bộ Kế hoạch và Đầu tư
Trên thực tế tại Bộ Kế hoạch và Đầu tư đã ứng dụng phương thức dựng một máy chủ chắn trước máy chủ dịch vụ HTTP từ năm 2003. Do những lý do về bảo mật nên trong phạm vi của đề tài này chúng tôi chỉ đề cập đến mô hình trên một hệ điều hành linux cụ thể hoàn toàn có thể áp dụng cho mọi hệ thống dịch vụ HTTP chứ không riêng MPIPortal. Mô hình hệ thống chắn trước chúng tôi đã áp dụng không phân biệt hệ thống dịch vụ HTTP đứng phía sau được xây dựng trên nền tảng ngôn ngữ lập trình nào, không phân biệt công nghệ Portal của hãng nào,…
Trong phần mô hình thử nghiệm chúng tôi xây dựng một hệ thống đề mô để bảo vệ MPIPortal trên máy ảo. Hệ thống này ứng dụng các phần mềm nguồn mở đã được giới thiệu và phân tích ở trên và được ứng dụng vào việc bảo mật hệ thống MPIPortal được cài đặt, cấu hình trong mô hình mạng thực tế năm 2009 của Bộ kế hoạch và Đầu tư như đã giới thiệu, phân tích ở các phần trước. Chúng tôi không đưa ra toàn bộ các cấu hình và trù bị bảo mật thực sự của MPIPortal vì lý do bảo mật.
1.10.Yêu cầu khi cài đặt hệ thống
Thực tế khi triển khai trên hệ thống bảo mật sử dụng phần mềm Mã nguồn mở sẽ được xây dựng trên máy tính cá nhân. Trong đó những phần mềm không thể thiếu khi xây dựng hệ thống này bao gồm:
1.10.1.Sử dụng chương trình máy ảo VMWare
Để thuận tiện cho việc xây dựng hệ thống bảo mật. Toàn bộ mô hình bảo mật sẽ được xây dựng trên máy ảo VMWare phiên bản 7.1.
1.10.2.Sử dụng hệ điều hành mã nguồn mở Centos
Phiên bản hệ điều hành sử dụng cho hệ thống sẽ là Centos 5.5
1.10.3.Sử dụng Snort -
Sniffer mode: đọc toàn bộ các gói tin qua card mạng và hiển thị trên màn hình quản trị.
-
Packet Logger mode: ghi log toàn bộ gói tin lên ổ đĩa.
-
Network Intrustion Detection (NIDS) mode: Cho phép Snort phân tích traffic dựa trên các tập luật được định nghĩa và thực hiện các hành động dựa trên kết quả phân tích.
1.10.4.Sử dụng Iptables -
Để ngăn chặn truy cập không hợp lệ dựa vào trạng thái của gói tin
-
Hạn chế truy cập khi máy chủ hứng chịu lượng lớn truy cập tại cùng một thời điểm.
-
Ghi log để phân tích.
1.10.5.Sử dụng Mod_security
Là một Firewall cho ứng dụng web, có khả năng ghi lại dấu vết traffic cho phép giảm sát, phát hiện và chống các cuộc tấn công vào ứng dụng web.
CHƯƠNG 5: KẾT LUẬN 1.11.Mở đầu
Sau khoảng thời gian là hai tháng, nhờ sự hướng dẫn tận tình của thầy giáo Thái Thanh Tùng, em đã hoàn thành được đồ án Ứng dụng mã nguồn mở vào bảo mật hệ thống của Bộ Kế hoạch và đầu tư. Trong quá trình từ tìm hiểu đến khi hoàn thành đồ án, em đã trải qua tất cả quá trình khi xây dựng một hệ thống bảo mật. Qua quá trình phát triển đề tài em đã rút ra được một số ưu điểm cũng như hạn chế của đề tài.
Ưu điểm:
Đề tài đã xây dựng được hệ thống bảo mật hoàn chỉnh. Các phần mềm của hệ thống như Snort, Iptables, và Mod_security được cài đặt vào hệ thống tạo nên một hệ thống ưu việt. Hệ thống này có khả năng chống được tấn công cơ bản như DOS. Hệ thống này sẽ rất hữu ích cho những hệ thống mạng theo mô hình Server – Client
Nhược điểm:
Hiện nay đề tài mới chỉ được xây dựng thử nghiệm trên máy ảo VMWare. Do đó yêu cầu cần có một hệ thống mạng thực sự để có thể thể hiện rõ khả năng bảo mật đối với một hệ thống lớn. Đồng thời việc xây dựng thử nghiệm trên máy ảo và trên hệ thống thật có thể sẽ khác nhau nên có thể sẽ xảy ra nhiều sự cố chưa lường trước được.
1.12.Hướng phát triển của hệ thống
Với những gì đã làm được trong đề tài, em sẽ phát triển đề tài để có thể triển khai được đề tài này trên hệ thống lớn. Đồng thời khắc phục được sự cố những phát sinh khi triển khai hệ thống này.
1.13.Kết Luận
Khi hoàn thiện đề tài không thể tránh khỏi có những sai sót. Em rất mong nhận được sự góp ý của thầy cô và bạn bè để đề tài ngày càng hoàn thiện hơn.
DANH MỤC TÀI LIỆU THAM KHẢO
[1] Patrick S. Harper, Oinkmaster Installation and Configuration Guide
[2] Andy Firman, Debian, Snort, Barnyard, BASE, & Oinkmaster Setup Guide
[3] Mark Cooper, Stephen Northcutt, Matt Fearnow, Karen Frederick, Intrusion
Signatures and Analysis
[4] Angela D. Orebaugh, Simon Biles, Jacob Babbin, “Snort Cookbook “
[5] Roman Danyliw, “ACID: Installation and Configuration”
[6] Chris Vespermann, “Snort, MySQL 5, Apache, and BASE for Gentoo Linux”
[7] Brian Laing, ISS, “How To Guide: Intrusion Detection Systems”
[8]Richard Bejtlich, “Extrusion Detection: Security Monitoring for Internal
Intrusions”
Chia sẻ với bạn bè của bạn: |