Đề tài Tìm hiểu mod_security và 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 10348551 Nguyễn Đức Lợi DHTH4ATLT 10321271 Dương Hiễn Lãm DHTH4BTLT 10356381 Nguyễn Phạm Hoàng Duy DHTH4BTLT 10244481 Trịnh Minh Tiến DHTH6C 09076271 Trần Công Chính DHTH5C 11234421 Trần Anh Thiện DHTH7B 11262121 Từ Kỷ DHTH7B  Mục Lục 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. 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 để phâ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ổ biế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 ( 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 ở 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. Quá trình xử lý các request của Apache và mod_security 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 body 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 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 Download mod_security: #wget 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) Giải nén #tar xzvf modsecurity-apache_2.5.13.tar.gz Biên dịch Tại thư mục apache2 gõ các lệnh sau #./configure #make #make install 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 Khởi động lại apache #service httpd restart III. Cấu hình cơ bản File 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) Turning Rule on and off Theo mặc định thì rule engine bị disable. Để kích hoạt modsecurity ta cần thêm chỉ thị sau vào file cấu hình SecRuleEngine On 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. Off : Vô hiệu hoá modsecurity DetectionOnly : Khi 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 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 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.5Accept-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: 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 : 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” Cấu trúc của rules SecRule VARIABLES OPERATOR [ACTIONS] 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 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ụ HTTP/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 REQUEST_URI : Request URI REQUEST_FILENAME : Tên file được yêu cầu đến. IS_SUBREQ Collections Một variables có thể bao gồm 1 hay nhiều phần dữ liệu. Khi 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 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…. 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ó 5 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: 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ả. Flow Actions chain: kết nối 2 hay nhiều rules lại với nhau skipnext:n mod_security sẽ bỏ qua n rules theo sau nó Default Action 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ụ : SecDefaultAction "phase:2,deny,log,status:403" V. Logging 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 - details 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 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 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— 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 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 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'" XSS Attack 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ụ:  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 XSS 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.  Như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 đó XSS không làm ảnh hưởng đến hệ thống website nằm trên server. Mục tiêu tấn công của XSS 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 (), 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ổ biế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. 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'" 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: # Khoa dang nhap sau 3 lan dang nhap khong thanh cong # # Khoi 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" # Khoa dang nhap khi so lan dang nhap khong thanh cong bang 3 SecRule IP:FAILED_LOGINS "@gt 3" deny Các rule trên dựa vào đặt điểm trả về của website khi người truy cập đăng nhập không thành công: Username does not exist. Các rule trên sẽ khởi tạo collection IP và tăng giá trị biến ip.failed_login lên một đơn vị sau mỗi lần đăng nhập không thành công. Action expirevar sẽ thiết lập biến ip.failed_login về 0 sau 5 phút. Vì vậy, khi biến ip.failed lớn hơn hoặc bằng 3, rule cuối sẽ khoá đăng nhập của người dùng trong 5 phút.  Hoặc chúng ta có thể thực hiện trì hoãn (hay dừng) request của người dùng khi số lần đăng nhập sai vượt quá quy định. Do đó, không cần phải từ chối truy cập như các rule được nêu ở trên. Sau đây là rule thực hiện điều trên:  # tri hoan request 3 giay sau 3 lan dang nhap khong thanh cong SecAction "initcol:ip=%{REMOTE_ADDR},pass,nolog" SecRule RESPONSE_BODY "Username does not exist" "phase:4,pass,setvar: ip.failed_logins=+1,expirevar:ip.failed_logins=10" SecRule IP:FAILED_LOGINS "@gt 3" "phase:4,allow,pause:3000" Thời gian trì hoãn được tính bằng mili giây, các rule trên sẽ trì hoãn response trong 3 giây khi số lần truy cập không thành công lớn hơn hoặc bằng 3. HTTP FINGERPRINTING Chỉ có những hacker nghiệp dư mới thực hiện tấn công một server mà không biết server đó có hoạt động hay không. Phức tạp hơn, hacker sẽ thu thập càng nhiều thông tin càng tốt về kiến trúc mạng và phần mềm đang chạy trên server. Cụ thể với web server, phương thức tìm kiếm thông tin này gọi là HTTP Fingerprinting (dấu vân tay HTTP).  HTTP Fingerprinting hoạt động bằng cách kiểm tra các đặc tính riêng của web server bằng các response khi được thăm dò và lấy “dấu vân tay” của server từ những thông tin thu thập được. Sau đó dấu vân tay này được so sánh với một cơ sở dữ liệu về “dấu vân tay” cho các web server được biết đến để xác định tên web server và phiên bản mà nó đang chạy. Sử dụng ModSecurity để ngăn chặn HTTP Fingerprinting  Chúng ta sẽ cung cấp đầy đủ các thông tin cho hacker tìm hiểu, nhưng không phải là thông tin chính xác. ModSecurity cho phép chúng ta tuỳ chỉnh và đánh lừa các công cụ HTTP Fingerprinting. Ví dụ:  - Chặn các request không chứa Host header - Đặt chữ ký là Microsoft-IIS/6.0. - Thêm X-Powered-By: ASP.NET 2.0 header. - Gỡ bỏ Etag header. Dưới đây là các rule để thực hiện: # Thay doi chu ky server SecServerSignature "Microsoft-IIS/6.0" # Them X-Powered-By header Header set X-Powered-By "ASP.NET 2.0" # Go bo ETag header Header unset ETag Chương 3: Kịch bản demo Centos 5.0 (Victim) Windows 7 (attacker) Thông tin cấu hình demo và phiên bản phần mềm: Victim: + Network interface: VirtualBox Host-only Ethernet Adapter IP: 192.168.56.101 + Open port 80 + Disable firewall + OS: Centos 5.0 + Webserver: Apache 2 + WAF(Web Application Firewall): mod_security 2.5.13 + php version 5.1.6 + DBMS: MySQL + Damn Vulnerable Web App (DVWA) 1.0.7 Attacker: + OS: Windows 7 Ultimate + Network interface: Virtual Host-only network IP: 192.168.56.1 ***Kịch bản tấn công: Attaker sẽ dùng công cụ SuperScan4 để thực hiện HTTP FingerPrinting nhằm khai thác thông tin về web server sau đó Attacker sẽ thực hiện phân tích các lỗ hổng có thể có trên website DVWA (website này được viết với mục đích để lộ ra các lỗ hổng để tiến hành demo), attacker thực hiện các cuộc tấn công SQL injection, XSS, Burte Force. Victim khi phát hiện website đặt trên web server củng mình bị tấn công liền cài đặt mod_security và tiến hành thiết lập các Rule như đã trình bày ở trên nhằm ngăn chặn các cuộc tấn công tương tự có thể xảy ra sau này. Tài liệu tham khảo [1] ModSecurity for Apache User Guide [2] ModSecurity Rules Project [3] Gotroot mod_security rules [4] Ivan Ristic, Apache Security – O'reilly 2005 , ISBN 0-596-00724-8 [5] Ryan C. Barnett, Preventing Web Attack with Apache , Addison Wesley Professional 2006, ISBN 0-321-32128-2 [6] Magnus Mischel, Modsecurity 2.5, 2009 Packt Publishing [7] ModSecurity® Reference Manual, Version 2.5.12 (Feb 3, 2010) Copyright © 2004-2010 Breach Security, Inc. (