ĐỀ TÀI : TÌM HIỂU MOD_SECURITY VÀ DEMO TÍNH NĂNG

Chia sẻ: Trần Công Chính | Ngày: | Loại File: DOC | Số trang:24

Thêm vào BST

Báo xấu

469
lượt xem 99
download

Download Vui lòng tải xuống để xem tài liệu đầy đủ

Tường lửa ứng dụng web không phổ biến như tường lửa mạng, nhưng nó đã được đề cập đến trong các tin tức, bài báo và hội thảo bảo mật hiện nay. Các doanh nghiệp đã chấp nhận sử dụng công nghệ này bởi vì nó nâng cao an toàn web một cách đáng kể. Nhưng cấu hình, triển khai và duy trì công nghệ mới này không hề đơn giản. Để triển khai chúng thành công, bạn cần phải hiểu rõ các hoạt động của ứng dụng một cách đầy đủ và cấu hình các quy tắc tường lửa...

Chủ đề:

Bình luận(0) Đăng nhập để gửi bình luận!

Lưu

Nội dung Text: ĐỀ TÀI : TÌM HIỂU MOD_SECURITY VÀ DEMO TÍNH NĂNG

Khoa CNTT – ĐH Công nghiệp thành phố Hồ Chí Minh Tìm hiểu Modsecurity & demo tính năng ĐỀ TÀI TÌM HIỂU MOD_SECURITY VÀ DEMO TÍNH NĂNG MSSV Họ Tên Lớp Nguyễn Đức Lợi 10348551 DHTH4ATLT Dương Hiễn Lãm 10321271 DHTH4BTLT Nguyễn Phạm Ho àng Duy 10356381 DHTH4BTLT Trịnh Minh Tiến 10244481 DHTH6C Trần Công Chính 09076271 DHTH5C Trần Anh Thiện 11234421 DHTH7B Từ Kỷ 11262121 DHTH7B 1
Khoa CNTT – ĐH Công nghiệp thành phố Hồ Chí Minh Tìm hiểu Modsecurity & demo tính năng Mục Lục Chương 1: Giới thiệu ......................................................................................................................... 3 Chương 2: Modsecurity ..................................................................................................................... 4 I. Các khả năng của mod_security................................ ................................ ...................................... 5 II. Cài đặt .......................................................................................................................................... 7 1. Download mod_security: ................................................................................................. 7 2. Trước khi cài đặt .............................................................................................................. 7 3. Giải nén ............................................................................................................................ 7 4. Biên dịch ................................ ................................ ................................ ........................... 8 5. Tích hợp modsecurity vào apache ................................................................................... 8 6. Khởi động lại apache........................................................................................................ 8 III. Cấu hình cơ bản ................................ ................................ ................................ ........................... 8 1. File cấu hình ..................................................................................................................... 8 2. Turning Rule on and off................................................................................................... 8 3. SecDefaultAction .............................................................................................................. 9 IV. Rules ........................................................................................................................................... 9 1. Xây dựng rules như thế nào? ................................ ................................ ........................... 9 2. Cấu trúc của rules .......................................................................................................... 11 2.1. Variables ................................................................ ................................ ..................... 11 2.2. Collections ................................................................................................................... 12 2.3. Operators ................................................................ ................................ ..................... 12 2.4. Actions................................ ................................ ................................ ......................... 13 V. Logging ...................................................................................................................................... 14 1. Debug Log ................................ ...................................................................................... 14 2. Audit logging ................................ ................................ ................................ .................. 15 3. Tuỳ biến thông tin log ................................ ................................ .................................... 16 VI. Xây dựng chính sách trên Modsecurity chống lại một số tấn công ................................ .............. 16 2
Khoa CNTT – ĐH Công nghiệp thành phố Hồ Chí Minh Tìm hiểu Modsecurity & demo tính năng 1. SQL Injection ................................................................................................................. 16 2. XSS Attack ................................................................ ................................ ..................... 17 3. Brute force attacks ......................................................................................................... 20 4. HTTP FingerPrinting..................................................................................................... 21 Chương 3: Kịch bản Demo ............................................................................................................. 22 Tài liệu tham khảo ........................................................................................................................... 24 3
Khoa CNTT – ĐH Công nghiệp thành phố Hồ Chí Minh Tìm hiểu Modsecurity & demo tính năng Chương 1: Giới thiệu Tường lửa ứng dụng web không phổ biến như tường lửa mạng, nhưng nó đã được đề cập đến trong các tin tức, bài báo và hội thảo bảo mật hiện nay. Các doanh nghiệp đ ã chấp nhận sử d ụng công nghệ này bởi vì nó nâng cao an toàn web mộ t cách đáng kể. Nhưng cấu hình, triển khai và duy trì công nghệ mới này không hề đ ơn giản. Để triển khai chúng thành công, bạn cần phải hiểu rõ các hoạt động của ứng dụng một cách đầy đủ và cấu hình các quy tắc tường lửa một cách cẩn thận. Hơn nữa, chi phí để mua được sản phẩm thương mại là rất đ ắt đỏ, chúng tôi khuyến khích bắt đầu sử dụng với các sản phẩm mã nguồn mở, chẳng hạn ModSecurity, do đó b ạn có thể đưa ra quyết định, nếu giải pháp này là thích hợp với ngân sách và môi trường mạng của bạn. Trong vài năm gần đây, các lỗ hổng ứng dụng web đã trở thành mố i đe dọa lớn nhất trong môi trường công nghệ thông tin. Theo cơ sở dữ liệu lổ hổng mã nguồ n mở (OSVDB), các mối đe dọa ứng dụng web chiếm hơn 50% tất cả các lỗ hổng trong năm 2010. Bạn không phải mộ t chuyên gia trong lĩnh vực IT để cấu hình các ứng dụng web đ ã trở nên sử dụng rộ ng rãi trong cuộc sống cũng như trong kinh doanh. Do đó, bảo mật các ứng dụng web đ ã trở thành một vấn đề quan trọng nhất mà bạn cần phải chú ý như người dùng cuố i hoặc một người kinh doanh. Tường lửa ứng dụng web (WAF) là một dạng tường lửa nhằm lọc các lưu lượng HTTP dựa trên một tập quy tắc. Nó kiểm tra ở mức ứng dụng vì vậy nó thường đi kèm như mộ t thiết b ị hoặc một mô đun trong máy chủ, có chức năng xác đ ịnh và ngăn chặn các tấn công web phổ biến như cross-site scritpting (XSS) và SQL injection bằng việc tùy chỉnh các quy tắc. Do đó, việc tùy chỉnh các quy tắc này là rất đáng quan tâm và yêu cầu bảo trì cao. Có nhiều cách để bảo vệ ứng d ụng web, chẳng hạn như thực hiện một đoạn mã an toàn, quản lý cấu hình an toàn, thực hiện đánh giá lỗ hổng và triển khai tường lửa ứng dụng web, nhưng không có mộ t giải pháp nào là hoàn hảo, việc sử dụng tường lửa ứng dụng web chỉ là một phương thức bảo mật ứng dụng. Kỹ thuật này tương đối mới so với các công nghệ khác, nhưng nó có thể trở thành một giải pháp hữu hiệu khi b ạn cấu hình và sử dụng nó đúng cách. 4
Khoa CNTT – ĐH Công nghiệp thành phố Hồ Chí Minh Tìm hiểu Modsecurity & demo tính năng Trong bài giới thiệu này, Modsecurity sẽ được sử dụng để minh hoạ làm thế nào bảo mật ứng dụng web sử dụng WAF. Modsecurity bảo vệ các ứng d ụng web từ nhiều cuộc tấn công và cho phép giám sát lưu lượng HTTP với sự can thiệp không nhiều của cơ sở hạ tầng hiện có. Nó là một mô đun mã nguồn m ở của ứng dụng máy chủ web Apache và nó đã được bảo trì bởi SpiderLabs, Trustwave. Từ khi nó là mộ t sản phẩm mã nguồn mở, nó mặc nhiên là miễn phí và nhiều người dùng sử dụng đã góp phần cải thiện và duy trì sản phẩm này. WAF không phải là m ột công cụ mà chỉ nhằm ngăn chặn các hoạt độ ng nguy hiểm tại lớp ứng dụng. Nó cũng có thể được sử dụng để p hân tích và phát hiện các lưu lượng nguy hiểm tấn công vào các ứng dụng. Do đó, phần sau của loạt bài viết này sẽ minh họ a làm thế nào phân tích các tấn công web phổ b iến sử dụng WAF đ ể phát hiện và ghi lại các khả năng cùng với nhật ký máy chủ Web Apache. Chương 2: Modsecurity Mod_security là một opensource web application firewall đ ược Ivan Ristic phát triển dành cho Apache Web Server. Ivan Ristic là tác giả quyển sách.Ông là mộ t người có rất nhiều kinh nghiệm trong bảo vệ Apache Web Server. Ô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 mod_security sử dụng giấy phép GPL, hoàn toàn miễn phí. Ngoài ra nếu muốn có sự hỗ trợ thì bạn có thể mua nó tại công ty ThinkingStone của ông (http://www.thinkingstone.com) 5
Khoa CNTT – ĐH Công nghiệp thành phố Hồ Chí Minh Tìm hiểu Modsecurity & demo tính năng I. 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. - 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 ở H TTP 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. Quá trình xử lý các request của Apache và mod_security 6
Khoa CNTT – ĐH Công nghiệp thành phố Hồ Chí Minh Tìm hiểu Modsecurity & demo tính năng Modsecurity cho phép bạn đặ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: rule được đặt tại đây sẽ được thực hiện ngay sau khi Apache đọc request header, lúc này phần request bod y vẫn chưa được đọc. 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 application- oriented thương được đặt ở đ ây. Ở thời điểm này bạn đã nhận đủ các request argument 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 tich dữ liệu XML 7
Khoa CNTT – ĐH Công nghiệp thành phố Hồ Chí Minh Tìm hiểu Modsecurity & demo tính năng Phase Response Header: đây là thời điểm ngay sau khi phần response header được gửi trả về cho client. Bạn đặt rule ở đ ây nếu muốn giám sát quá trình sau khi phần response được gửi đi. Phase Response Body: đ ây là thời điểm bạn muốn kiểm tra những dữ liệu HTML gửi trả về Phase logging: đây 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 cung là thời điểm cuối cùng để bạn chặn các connection không mong muố n, kiểm tra các response header mà bạn không thể kiểm tra ở phase 3 và phase 4. II. Cài đặt 1. Download mod_security: #wget http://www.modsecurity.org/download/modsecurity- apache_2.5.13.tar.gz 2. Trước khi cài đặt Cần các thư viện apxs, libxml2 và cần file mod_unique_id.so Cài đặt thư viện #yum install httpd -devel (cài apxs) #yum install libxml2-devel Thêm dòng sau vào file http.conf (file nằm trong /etc/httpd/conf) dòng sau LoadModule unique_id_module modules/mod_unique_id.so (Chú ý: thêm vào đoạn có nhiều LoadModule đầu dòng) 3. Giả i nén #tar xzvf modsecurity-apache_2.5.13.tar.gz 4. B iên dịch 8
Khoa CNTT – ĐH Công nghiệp thành phố Hồ Chí Minh Tìm hiểu Modsecurity & demo tính năng Tại thư mục apache2 gõ các lệnh sau #./configure #make #make install 5. Tích hợp modsecurity vào apache Thêm dòng sau vào file httpd.conf LoadModule security2_module modules/mod_security2.so 6. Khởi động lạ i apache #service httpd restart III. C ấu hình cơ bản 1. F ile cấu hình Modsecurity 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). 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 trong thư mục conf.d và sau đó chúng ta cần thêm vào httpd.conf Include conf.d/modsecurity.conf (mặc định trong httpd.conf đã có dòng include conf.d/*.conf với dòng này nó sẽ thực hiện tất cả các file có phần mở rộng là .conf) 2. Turning Rule on and off Theo mặc định thì rule engine bị d isable. Để kích hoạt modsecurity ta cần thêm chỉ thị sau vào file cấu hình SecRuleEngine On Directive này dùng để điều khiển rule engine, chúng ta có thể sử dụng các tuỳ chọ n là On, Off hoặc DynamicOnly. 9
Khoa CNTT – ĐH Công nghiệp thành phố Hồ Chí Minh Tìm hiểu Modsecurity & demo tính năng Off : Vô hiệu hoá modsecurity DetectionOnly : K hi nó phù hợp một luật nào đó thì nó cũng không thực hiện bất kì action nào. (nó rất có ích trong trường hợp muốn test một luật nào đó mà không muố n nó block bất kì request nào có vấn đề với luật) On : Các rules của modsecurity được áp dụng cho tất cả các nội dung 3. SecDefaultAction Dùng để tạo các action mặc định. Khi tạo 1 luật mà không chỉ rõ hành động cho luật đó nó sẽ thực hiện hành động mặc đ ịnh Ví dụ: SecDefaultAction "phase:2,deny,log,status:403" IV. Rules 1. Xây dựng rules như thế nào? HTTP request 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) ecko/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); 10
Khoa CNTT – ĐH Công nghiệp thành phố Hồ Chí Minh Tìm hiểu Modsecurity & demo tính năng __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 : GET – Đây là request method Host User-Agent Accept Accept-Language Accept-Encoding Accept-Encoding Keep-Alive Connection Referer Modsecurity sẽ sử dụng thông tin này trong các rules của nó để cản lọc các requests. Và không chỉ trong header, modsecurity cũng có thể xem xét cả POST payload như đã nhắc tới ở trên, ... Chẳng hạn ta có cấm request có Referer là www.abc.com ta có rule sau: SecRule HTTP_Referer “www\.abc\.com” Không cho phép User-Agent có từ HotBar: SecRule HTTP_User-Agent “HotBar” 2. Cấu trúc của rules SecRule VARIABLES OPERATOR [ACTIONS] 2.1. Variables SecRule ARGS dirty Có thể dùng 1 hay nhiều variables SecRule ARGS|REQUEST_HEADERS:User-Agent dirty REMOTE_ADDR : Đ ịa chỉ IP của client 11
Khoa CNTT – ĐH Công nghiệp thành phố Hồ Chí Minh Tìm hiểu Modsecurity & demo tính năng 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 được 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 ụ H TTP/1.1) SERVER_SOFTWARE : Apache version TIME_YEAR : Năm hiện tại (2006) TIME_MON : Tháng hiện tại (2) 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 ụ: 20060220144530 : 20/02/2006 14h 45' 30'' API_VERSION THE_REQUEST : dòng đầu tiên của request. vd: GET / HTTP/1.1 12
Khoa CNTT – ĐH Công nghiệp thành phố Hồ Chí Minh Tìm hiểu Modsecurity & demo tính năng REQUEST_URI : Request URI REQUEST_FILENAME : Tên file được yêu cầu đến. IS_SUBREQ 2.2. Collections Một variables có thể bao gồm 1 hay nhiều phần dữ liệu. K hi variable có nhiều hơn 1 giá trị thì ta gọ i nó là collection Ví dụ: với variable ARGS ta có 2 thông số p, và q SecRule ARGS:p dirty SecRule ARGS:q dirty 2.3. Operators Sử dụng @ đ ể chỉ ra đây là mộ t operation SecRule ARGS "@rx dirty" Sử dụng !@ để chỉ ra một operation negation SecRule &ARGS "!@rx ^0$" Ở đây chúng ta đề cập đến một operation là rx (regular expression). RX quy định các thể hiện [Jj]oy : thể hiện mọi chuỗi có chứa Joy hoặc joy [0-9] : mọi số từ 0 tới 9 [a-zA-Z] : mọi chữ từ a đ ến z cả chũ thường lẫn in hoa ^ : bắt đầu một chuỗ i $ : kết thúc chuỗi ^abc$ : chuỗi chỉ bao gồm từ abc . :mọi kĩ tự p.t : ví dụ như pat,pet, pzt…. 2.4. 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 : 13
Khoa CNTT – ĐH Công nghiệp thành phố Hồ Chí Minh Tìm hiểu Modsecurity & demo tính năng P rimary 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ó 5 primary actions : deny : Request sẽ b ị ngắt, mod_security sẽ trả về H TTP status code 500 hoặc là status code của bạn thiết lập trong chỉ thị status: pass : Cho phép request tiếp tục được xử lý ở các rules tiếp theo Allow: Cho phép truy cập ngay lập tức và bỏ qua các phases khác (trừ phases 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 phases sau. Chỉ cho phép truy cập tới các request phases: allow:request, nó sẽ cho qua phase 1,2 và vẫn kiểm tra ở phase 3 trở đ i redirect : Redirect một request đ ến một url nào đó. Secondary Actions Secondary actions sẽ b ổ sung cho Primary actions, một rule có thể có nhiều Secondary actions 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. exec : thực thi mộ t lệnh nào đó nếu một request vi phạm 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ả. F low Actions chain: kết nối 2 hay nhiều rules lại với nhau skipnext:n mod_security sẽ bỏ q ua n rules theo sau nó Default Action 14
Khoa CNTT – ĐH Công nghiệp thành phố Hồ Chí Minh Tìm hiểu Modsecurity & demo tính năng Khi một rule không chỉ rõ action thì rule đó sẽ dùng default action được thiết lập trong SecDefaultAction. Ví dụ : S ecDefaultAction "phase:2,deny,log,status:403" V. Logging 1. Debug Log Sử dụng SecDebugLog directive lựa chọn file để ghi lại các thông tin debug SecDebugLog logs/modsec-debug.log Bạn có thể thay đổ i m ức độ chi tiết các thông tin được log thông qua directive : SecDebugLogLevel 4 Giá trị log có thể thay đổi từ 0 -9 : 0 - no logging. 1 - errors (intercepted requests) only. 2 - warnings. 3 - notices. 4 - d etails of how transactions are handled. 5 - as above, but including information about each piece of information handled. 9 - log everything, including very detailed debugging information 2. 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 loging 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ó 2 directives: SecAuditEngine On : bật audit log lên SecAuditLog logs/audit.log : chỉ ra file lưu trữ log chính 15
Khoa CNTT – ĐH Công nghiệp thành phố Hồ Chí Minh Tìm hiểu Modsecurity & demo tính năng Ngoài ra còn có SecAuditLog2 logs/audit2.log :chỉ ra file lưu trữ log phụ Đây là một ví dụ của audit log : ==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— 3. Tuỳ biến thông tin log SecAuditEngine chấp nhận 3 giá trị sau : 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 bộ lọ c rules 16
Khoa CNTT – ĐH Công nghiệp thành phố Hồ Chí Minh Tìm hiểu Modsecurity & demo tính năng 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 : SecAuditLogRelevantStatus ^5 VI. Xây d ựng chính sách trên Modsecurity chống lại một số tấn công 1. SQL Injection Các từ khóa chính thường sử dụng trong tấn công SQL Injection và các regular expressions tương ứng 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 * select\s+* \s : được định nghĩa trong PCRE là m ột regular expression cho phép phát hiện mọ i khoảng trắng và cả các mã thay thế (%20) Để chống lại tấn công SQL Injection, ta dựa vào các đặc điểm trên từ đó đưa ra rule sau: SecRule ARGS "union\s+select" "t:lowercase,deny,msg:'SQL Injection'" SecRule ARGS "union\s+all\s+select" "t:lowercase,deny,msg:'SQL Injection'" SecRule ARGS "into\s+outfile" "t:lowercase,deny,msg:'SQL Injection'" SecRule ARGS "drop\s+table" "t:lowercase,deny,msg:'SQL Injection'" SecRule ARGS "alter\s+table" "t:lowercase,deny,msg:'SQL Injection'" SecRule ARGS "load_file" "t:lowercase,deny,msg:'SQL Injection'" SecRule ARGS "select\s+from " "t:lowercase,deny,msg:'SQL Injection'" 2. XSS Attack 17
Khoa CNTT – ĐH Công nghiệp thành phố Hồ Chí Minh Tìm hiểu Modsecurity & demo tính năng 2.1 Định nghĩa Cross-Site Scripting hay còn đ ược gọi tắt là XSS (thay vì gọ i tắt là CSS để tránh nhầm lẫn với CSS-Cascading Style Sheet của HTML) là một kĩ thuật tấn công b ằng cách chèn vào các website động (ASP, PHP, CGI, JSP ...) những thẻ HTML hay những đo ạn mã script nguy hiểm có thể gây nguy hại cho những người sử dụng khác. Trong đó, những đoạn mã nguy hiểm được chèn vào hầu hết được viết bằng các Client-Site Script như JavaScript, JScript, DHTML và cũng có thể là cả các thẻ HTML. K ĩ thuật tấn công XSS đã nhanh chóng trở thành một trong những lỗi phổ biến nhất của Web Applications và mố i đe doạ của chúng đối với người sử dụng ngày càng lớn. 2.2 Hoạt động của XSS V ề cơ bản XSS cũng như SQL Injection hay Source Injection (sẽ đ ược giới thiệu ở phần sau), nó cũng 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ụ: http://www.example.com/search.cgi?query=alert('XSS was found !'); N ếu truy cập vào địa chỉ trên, rất có thể trình duyệt sẽ hiện lên một thông báo X SS was found !. Các đo ạn mã trong thẻ không hề bị giới hạn bởi chúng hoàn toàn có thể thay thế bằng một file nguồn trên một server khác thông qua thuộc tính src của thẻ . Cũng chính vì lẽ đó mà chúng ta chưa thể lường hết được độ nguy hiểm của các lỗi XSS. N hưng nếu như các kĩ thuật tấn công khác có thể làm thay đổi được dữ liệu nguồn của web server (mã nguồn, cấu trúc, cơ sở dữ liệu) thì 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 hacker 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. Thật vậy, 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 đó X SS không làm ảnh hưởng đến hệ thống website nằm trên server. 18
Khoa CNTT – ĐH Công nghiệp thành phố Hồ Chí Minh Tìm hiểu Modsecurity & demo tính năng Mục tiêu tấn công của XSS không ai khác chính là những 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 hacker đ ể lại, họ có thể b ị chuyển tới các website khác, đặt lại homepage, 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 .. 2.3 Ngăn chặn tấn công XSS Đ ề ngăn chặn tấn công XSS, chúng 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 dùng trong tấn công XSS như đấu ngo ặc góc (< và >), script... D ưới đây là danh sách các ký tự nên mã hoá khi được client cung cấp đ ể lưu vào cơ sở d ữ liệu. Bảng 3.1 Các ký tự nên mã hoá để ngăn chặn tấn công XSS N ếu chúng ta muốn ngăn chặn tấn công với ModSecurity, dưới đây là các đoạn script XSS phổ b iến và các biểu thức chính quy để ngăn chặn người dùng request chứa các chuỗi này. 19
Khoa CNTT – ĐH Công nghiệp thành phố Hồ Chí Minh Tìm hiểu Modsecurity & demo tính năng Bảng 3.2 Các script XSS và biểu thức chính quy Sau đây là rule thực hiện: SecRule ARGS "alert\s+*\(" "t:lowercase,deny,msg:'XSS'" SecRule ARGS "&\{.+\}" "t:lowercase,deny,msg:'XSS'" SecRule ARGS "" "t:lowercase,deny,msg:'XSS'" SecRule ARGS "javascript:" "t:lowercase,deny,msg:'XSS'" SecRule ARGS "vbscript:" "t:lowercase,deny,msg:'XSS'" 3. Tấn công BRUTE FORCE V ới tấn công Brute Force, hacker 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… và thực hiện đăng nhập liên tục đế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. Cách tốt nhất để ngăn chặn hình thức tấn công này 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, thực hiện khoá đăng nhập của người này trong 5 phút. D ưới đây là các rule của ModSecurity cho phép chúng ta thực hiện điều này: # K hoa dang nhap sau 3 lan dang nhap khong thanh cong # # K hoi tao collection ip SecAction "initcol:ip=%{REMOTE_ADDR},pass,nolog" # Phat hien dang nhap khong thanh cong SecRule RESPONSE_BODY "Username does not exist" "phase:4,pass,setvar: ip.failed_logins=+1,expirevar:ip.failed_logins=300" # K hoa dang nhap khi so lan dang nhap khong thanh cong bang 3 SecRule IP:FAILED_LOGINS "@gt 3" deny 20