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

Một phần của tài liệu Xây dựng hệ thống bảo vệ ứng dụng web dựa trên tường lửa modsecurity và iptables (Trang 61)

- 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.

- 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 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.

ModSecurity hoạt động dựa trên 4 nguyên tắc:

- Flexibility (tính linh hoạt): ModSecurity có thể dễ dàng cho chúng ta xây dựng cho các nhân hay một tổ chức có nhu cầu chặn, đánh giá và phân tích lưu lượng HTTP. ModSecurity đạt được sự linh hoạt là ở chỗ cung cấp một luật mạnh về ngôn ngữ, cái cho phép một các chính xác những hành động kết hợp với những tính năng đặc biệt để áp dụng những luật cần thiết.

- Passiveness (tính thụ động): ModSecurity hạn chế những tương tác không cần thiết đến những hoạt động của hệ thống đến khi xấy dựng các luật cho ModSecurity.

- Predictability (tính có thể đoán trước)

- Feature quality over quantity (Tính năng chất lượng hơn số lượng)

Thành phần chính của ModSecurity là rule engine, nó được thiết kế để làm việc với giao thức HTTP một cách linh hoạt và mềm dẻo, dễ dàng sử dụng cho người quản trị.

Ngoài ra với những người mới bắt đầu, chưa quen với việc tạo rule, Breach Security cung cấp một tập hợp các core rule đáp ứng cho những chức năng bảo vệ chung như:

- HTTP protection – Phát hiện các hành vi vi phạm đối với giao thức HTTP và cách sử dụng các chính sách cục bộ.

- Common Web Attacks Protection – Phát hiện và phòng chống lại các cuộc tấn công phổ biến.

- Automation detection – Phát hiện và phòng chống các chương trình bots, quét cổng, và một số các hành động có hại khác.

- Trojan Protection – Phát hiện sự truy cập vào của Trojan - Error Hiding – Che dấu các lỗi đã được gửi đến máy chủ.

3.4.2.3. Quá trình xử lý

Hình 3.6: Quá trình xử lý của ModSecurity

Modsecurity cho phép ta đặt rule tại một trong năm thời điểm trong chu kỳ xử lý của Apache như sau:

- Phase Request Header: 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 đượ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 ta đã nhận đủ các request argument và phần request body đã được đọc. ModSecurity hỗ trợ ba loại mã hoá request body:

-- 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 phần response header được gửi trả về cho client. Ta đặ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 ta 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 cũng là thời điểm cuối cùng để ta chặn các kết nối không mong muốn, kiểm tra các response header mà ta không thể kiểm tra ở phase 3 và phase 4.

3.4.2.4. File cấu hình

Mod_security là tường lửa ứng dụng web 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:

<IfModule>

#Modsecurity configuration #...

</IfModule>

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:

3.4.2.5. Ghi nhật ký (Logging) a. Nhật ký gỡ rối(Debug Loging)

Sử dụng SecFilterDebugLog directive lựa chọn file để ghi lại các thông tin debug

SecFilterDebugLog logs/modsec_debug_log

Ta có thể thay đổi mức độ chi tiết các thông tin được log thông qua directive:

SecFilterDebugLevel 4

Giá trị log có thể thay đổi từ 0-9 :

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 ...

b. Ghi nhật ký giám sát (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

Dưới đâ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--

Khi SecFilterScanPOST on thì POST payload sẽ luôn được kèm theo trong audit log

c. Tuỳ biến thông tin nhật ký

SecAuditEngine chấp nhận 4 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 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ụ ta cần log lại những requests gây ra lỗi 5xx :

SecAuditLogRelevantStatus ^5

3.5. Triển khai phần mềm tường lửa ModSecurity kết hợp với Iptables để bảo vệ hệ thống Web

Các nguy cơ có thể đến với hệ thống máy chủ Web là:

• Các lỗi Zero-day tồn tại trong các phiên bản Apache, MySQL mà hệ thống đang chạy.

• Các nguy cơ tồn tại trong mã nguồn của WebSite dễ gây ra các tấn công vào các lỗ hổng đó như SQL Injection, Command Injection, Cookies Injection dẫn đến thông tin tài khoản quản trị, tài khoản của người sử dụng bị lộ dẫn đến kẻ tấn công có thể sửa đổi nội dung làm sai lệch thông tin.

• Đồng thời đối với tổ chức xã hội, hệ thống Web luôn cập nhật các bản tin, do đó các nguy cơ tấn công từ bên trong (từ vùng Internal, vùng VPN) là cũng có thể xảy ra.

• Nguy cơ bị tấn công từ chối dịch vụ (DoS, DdoS) làm cho hệ thống không còn khả năng phục vụ các yêu cầu chính đáng.

• Tấn công vào các dịch vụ khác trong hệ thống để tấn công vào máy chủ Web.

Trong quá trình triển khai, ta sẽ xây dựng trực tiếp tường lửa IPtables và tường lửa ModSecurity lên máy chủ web, nhiệm vụ của hai phần mềm tường lửa như sau nhằm ngăn chặn một số dạng tấn công cơ bản:

• Xây dựng Chroot Jail để giới hạn phạm vi của website

• Giới hạn các cổng dịch vụ được mở

• Giới hạn số icmp đến máy chủ web

• Giới hạn số yêu cầu HTTP trong một thời điểm

• Ngăn chặn tấn công SQL Injection

• Ngăn chặn tấn công XSS

• Chặn một số mã trả lời

• Chặn tấn công Directory Traversal

• Chặn tấn công PHP Code Injection

• Chặn tấn công Web Leacher

• Chặn tấn công dò quét điểm yếu.

Tất cả việc cài đặt và cấu hình được sử dụng hoàn toàn trên hệ điều hành Centos 5.4

3.5.1. Cài đặt ModSecurity và Iptables trực tiếp trên máy chủ Web

Công việc đầu tiên là ta tiến hành cài đặt các dịch vụ Web, MySQL, PHP:

# wget http://download.fedora.redhat.com/pub/epel/5/i386/epel- release-5-3.noarch.rpm

# wget http://rpms.famillecollet.com/el5.i386/remi-release-5- 6.el5.remi.noarch.rpm

# rpm -Uvh epel-release-5* remi-release-5*

# wget http://dag.wieers.com/rpm/packages/rpmforge- release/rpmforge-release-0.3.6-1.el5.rf.i386.rpm # rpm -Uvh rpmforge-release-0.3.6-1.el5.rf.i386.rpm # Yum install httpd

# yum --enablerepo=remi,epel,rpmforge update php* mysql*

# yum --enablerepo=remi,epel,rpmforge install php php-gd php- mbstring php-mysql php-odbc php-pdo php-pear mysql-server mysql-bench

# yum --enablerepo=remi,epel,rpmforge install phpMyAdmin

Tiếp theo là cài ModSecurity, đối với trường hợp này ta có thể cài đặt gói trực tiếp ở trên Ports mà không cần phải biên dịch lại:

#yum install mod_security

Đối với Iptables, ta chỉ cần khởi động là Iptables có thể hoạt động được: #services iptable start

3.5.2. Xây dựng tập luật đối với ModSecurity

Tập luật của ModSecurity sẽ chạy độc lập trong cả 2 trường hợp là nhúng trực tiếp hay sử dụng qua một Reverse Proxy.

Ta tạo một thư mục modsecurity trong thư mục /etc/httpd/conf là nơi chứa các tập luật cho ModSecurity, đồng thời với mỗi dạng tấn công ta cũng tạo các file luật riêng ví dụ như sqlinjection.rules để quản lý một các dễ dàng hơn. Sau đó ta thêm dòng gọi các luật đó vào trong file httpd.conf tại thư mục /etc/httpd.conf như hình phía dưới:

Hình 3.7: Cấu hình modsecurity trong httpd.conf

Đầu tiên ta sẽ xây dựng một Chroot Jail để giam apache trong đó, tiến hành sao chép dữ liệu vào trong /chroot để ngăn chặn việc tấn công vào các thành phần khác trong hệ thống. Chuyển quyền sở hữu /chroot cho tài khoản apache, và sau đó tiến hành sao chép dữ liệu từ /var/www vào trong /chroot. C

#mkdir –p /chroot/var/run #mkdir –p /chroot/var/www

#chown -R apache:apache /chroot #cp –R /var/www /chroot/var/www SecChrootDir /chroot

Tiếp theo ta sẽ xây dựng tập luật để chống việc tìm thông tin của hệ thống máy chủ web bằng cách chuyển thông tin của máy chủ Apache thành máy chủ Microsoft IIS/6.0, chạy asp.net. Đồng thời các thuộc tính yêu cầu chỉ cho phép GET. HEAD, POST, chặn các yêu cầu không có tiêu để chủ, không có tiêu đề đồng ý, chỉ hỗ trợ giao thức HTTP 1.0 và 1.1

#

#Defeat HTTP fingerprinting #

#change server signature

SecServerSignature "Microsoft-IIS/6.0" #Deny requests without a host header

SecRule &REQUEST_HEADERS:Host "@eq 0" "phase:1,deny" #Deny requests without an accept header

SecRule &REQUEST_HEADERS:Accept "@eq 0" "phase:1,deny" # Deny request that don't use GET, HEAD or POST

SecRule REQUEST_METHOD !^(get|head|post)$ "phase:1,t:lowerCase,deny"

# Only allow HTTP version 1.0 and 1.1

SecRule REQUEST_PROTOCOL !^http/1\.(0|1)$ "phase:1,t:lowercase,deny"

# Add X-Powered-By header to mimic IIS #Header set X-Powered-By "ASP.NET 2.0" # Remove the ETag header

<Ifmodule mod_headers.c> Header unset ETag

</Ifmodule>

Tiếp theo ta sẽ xây dựng tập luật để chống tấn công SQL Injection: <Location /login.php>

SecRule ARGS:username "!^[-a-zA-Z0-9_]+$" deny </Location>

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+*" "t:lowercase,deny,msg:'SQL Injection'"

Xây dựng tập luật chống tấn công Brute Force: #

# Throttle login attempts after 3 failed attempts #

<LocationMatch ^/login>

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" </LocationMatch>

Xây dựng tập luật chống việc khám phá mã nguồn và truy cập vào các thư mục khác:

# Prevent PHP source code from being disclosed

SecRule RESPONSE_BODY "<?" "deny,msg:'PHP source code disclosure blocked'"

SecRule REQUEST_URI "../" "t:urlDecode,deny" Xây dựng tập luật chống tấn công từ chối dịch vụ: SecAction phase:1,nolog,pass,setvar:IP.counter=+1

SecRule IP:UPDATE_RATE "@gt 10" "phase:1,block,msg:'Request rate too high for IP address: %{IP.UPDATE_RATE}'"

# Block the IP addresses that use too # much of the web server's time

SecRule IP.load "@gt 10000" "phase:1,t:none,block,msg:'IP address load too high: %{IP.load}'"

# Keep track of how much web server # time is consumed by each IP address

SecAction "phase:5,nolog,pass,setvar:IP.load=+%{DURATION}, deprecatevar:IP.load=250/1"

3.5.3. Xây dựng tập luật đối với tường lửa Iptables

Ta có thể sửa tập luật của Iptables trong tập tin /etc/sysconfig/iptables. Mỗi lần khởi động hệ thống, các luật trong tập tin này sẽ được gọi. Trong hai trường hợp triển khai đối với tưởng lửa Iptables có đôi chút khác biệt. Trong trường hợp xây dựng Proxy riêng, ta cần cấu hình để Iptables chuyển dịch địa chỉ (NAT) từ card trong ra card ngoài và ngược lại.

Đối với tưởng lửa này, ta sẽ thực hiện:

- Mở các cồng dịch vụ cho Web và SSH (80, 443, 22) - Giới hạn số ICMP trong 1 thời điểm

- Giới hạn số yêu cầu HTTP trong 1 thời gian để hạn chế tấn công DoS

Đầu tiên ta xây dựng tập luật cho phép lệnh ping và echo-request trong 1s chỉ được 1 echo:

#iptables -A OUTPUT -p icmp --icmp-type echo-request -j ACCEPT #iptables -A INPUT -p icmp --icmp-type echo-reply -j ACCEPT #iptables -A INPUT -p icmp --icmp-type echo-request -m limit \ –limit 1/s -i eth0 -j ACCEPT

Tập luật giới hạn ports và số kết nối đến máy chủ web trong 1s:

# iptables -A INPUT -p tcp --syn -m limit --limit 5/s -i eth0 -j ACCEPT

#iptables -A INPUT -s 0/0 -i eth0 -p TCP --sport 1024:65535 -m multiport --dports 80,443,22 -j ACCEPT

#iptables -A INPUT -p tcp -i eth0 --dport 22 –sport 1024:65535 -m state --state NEW -j ACCEPT

#iptables –A INPUT –p tcp –dport 80 –m state –state NEW –m recent –set --name apache

#iptables –A INPUT –p tcp –dport 80 –m state –state NEW –m recent –update –seconds 60 –hitcout 8 –rttl –name apache –j DROP

#iptables –A INPUT –p tcp –dport 443 –m state –state NEW –m recent –set --name apache

#iptables –A INPUT –p tcp –dport 443 –m state –state NEW –m recent –update –seconds 60 –hitcout 8 –rttl –name apache –j DROP

Chương 4: KẾT LUẬN, ĐÁNH GIÁ VÀ ĐỊNH HƯỚNG PHÁT TRIỂN

Cùng với việc xây dựng tường lửa kết hợp giữa hai tường lửa mã nguồn mở và không mất phí mà các tính năng rất tốt đã bảo vệ được máy chủ web bằng việc xây dựng thực hiện những công việc:

• Xây dựng Chroot Jail để giới hạn phạm vi của website

• Giới hạn các cổng dịch vụ được mở

• Giới hạn số icmp đến máy chủ web

• Giới hạn số yêu cầu HTTP trong một thời điểm

• Ngăn chặn tấn công HTTP fingerprinting

• Ngăn chặn tấn công SQL Injection

• Ngăn chặn tấn công XSS

• Chặn một số mã trả lời

• Chặn tấn công PHP Code Injection

• Chặn tấn công Web Leacher

• Chặn tấn công dò quét điểm yếu.

Do đó hệ thống máy chủ web có thể ngăn chặn được các hình thức tấn công cơ bản như SQL Injection, XSS, HTTP fingerprinting, Directory Traversal, PHP Code Injection, các cuộc tấn công dò quét điểm yếu, hạn chế cuộc tấn công từ chối dịch vụ.

Việc triển khai tường lửa này được triển khai trên hệ thống Linux để tận dụng được tường lửa Iptables, còn đối với những hệ điều hành khác như Unix, thì trên đó cũng tích hợp một tường lửa lọc gói khá mạnh pf (packet filter). Còn ModSecurity khi cài đặt ra được tích hợp trực tiếp với Apache dưới dạng một module do đó không làm giảm hiệu năng của máy chủ web.

Về dịch vụ, tường lửa Iptables là dịch vụ riêng, ta có thể bật tắt, cập nhật luật

Một phần của tài liệu Xây dựng hệ thống bảo vệ ứng dụng web dựa trên tường lửa modsecurity và iptables (Trang 61)

Tải bản đầy đủ (DOC)

(85 trang)
w