Latest posts for the topic "Bảo mật web server Apache với mod Security - Phần 2"

Bảo mật web server Apache với mod Security - Phần 2.1

tanviet12 — GMT

--------------------------------------------------------------------------------------------------------------------- Xem các phần khác tại Phần 1: /hvaonline/posts/list/38687.html Phần 3: /hvaonline/posts/list/38694.html --------------------------------------------------------------------------------------------------------------------- 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à

Bảo mật web server Apache với mod Security - Phần 2.2

tanviet12 — GMT

2.4.2. Giới thiệu về biểu thức chính quy – Regular expressions 2.4.2.1. Ví dụ về các biểu thức chính quy

Bảng 2.1 Các biểu thức chính quy Trong trường hợp muốn cả từ favorite và favourite đều đúng thì có thể dùng dấu chấm hỏi ?để quy định có thể có hoặc có thể không ký tự u. Cú pháp sẽ là favou?rite Trường hợp trên đối với một ký tự u, nếu có nhiều hơn một ký tự chúng ta có thể nhóm lại bởi hai dấu ngoặc đơn (). Ví dụ với hai từ previous và previously. Cú pháp sẽ là previous(ly)? 2.4.2.2. Các biểu thức chính quy khác

Bảng 2.2 Các biểu thức chính quy khác Vd: Code:

SecRule REMOTE_USER "@within tim,john,alice"

2.4.2.3. Sử dụng @ rx để chặn một server từ xa Ví dụ chúng ta có 2 rule như sau Code:

# Rule 1 
SecRule REMOTE_HOST "@rx \.microsoft\.com$" deny
# Rule 2 
SecRule REMOTE_HOST "\.microsoft\.com$" deny

Cả hai rule đề có tác dụng như sau là chặn các host truy cập từ xa từ tập đoàn Microsoft. Mục tiêu của @rx mà bỏ qua rule thứ hai bởi hai rule đều có mục đích như nhau. 2.4.3. So sánh số (matching number)

Bảng 2.3 So sánh số 2.4.4. Phases và sắp xếp rule Điều quan trọng là hiểu được việc sắp xếp rule của ModSecurity. Điều này tránh các tình huống mà mọi phương thức, hoạt động đều bất ngờ bị chặn(deny) hoặc cho phép (allow) trái với ý định. Có 5 giai đoạn (phase) 1. REQUEST_HEADERS (phase 1) 2. REQUEST_BODY (phase 2) 3. RESPONSE_HEADERS (phase 3) 4. RESPONSE_BODY (phase 4) 5. LOGGING (phase 5) Một rule được thực hiện đúng từng phase theo thứ tự . Điều này có nghĩa là ModSecurity duyệt tất cả các rule trong phase 1 ("REQUEST_HEADERS"). Sau đó, đến phase 2… Trong mỗi phase, rule được xử lý theo thứ tự mà chúng xuất hiện trong các tập tin cấu hình. Chúng ta có thể hiểu khi có action, ModSecurity sẽ duyệt các tập tin năm lần, một lần cho từng phase. Trong thời gian xử lý ModSecurity chỉ xem xét rule thuộc pha hiện đang xử lý, và những rule được áp dụng theo thứ tự chúng xuất hiện trong các tập tin cấu hình. Phase LOGGING đặc biệt ở chỗ nó luôn luôn được thực hiện cả khi request đã được cho phép hay từ chối trong các phase trước đó. Ngoài ra, một khi phase LOGGING bắt đầu, chúng ta không thể thực hiện bất kỳ action ngăn chặn nào vì response đã được gửi cho người truy cập. Vì vậy, chúng ta phải cẩn thận không để cho bất kỳ action nào trái quy định được truyền vào rule ở phase 5. Nếu không sẽ gây lỗi làm Apache không khởi động được. Nếu chúng ta đặt rule sau đây trước các rule thuộc phase 5 sẽ ngăn chặn được lỗi này xảy ra. (nhưng phải đặt sau các rule của phase trước đó). Code:

SecDefaultAction "phase:5,pass"

2.4.5. Chức năng chuyển đổi ModSecurity cung cấp một số chức năng chuyển đổi mà chúng ta có thể áp dụng cho các biến và các collection. Những biến đổi được thực hiện trên một bản sao của dữ liệu được kiểm tra, có nghĩa là các HTTP request hoặc response ban đầu vẫn được giữ nguyên, không thay đổi. Chức năng này rất quan trọng. Nếu chúng ta muốn phát hiện tấn công XSS (cross-site scripting), chúng ta phải phát hiện mã JavaScript bất kể trường hợp nó được viết in hay viết thường. Để làm điều này, chức năng chuyển đổi có thể được áp dụng để so sánh một chuỗi viết hoa với chuỗi viết thường. Code:

SecRule ARGS "

Rule trên sẽ chặn tất cả các URL chứa chuỗi >;<;script bất kể chữ hoa thường, vd sCript; >;<;scripT ..

Bảng 2.4 Một số chức năng chuyển đổi của ModSecurity 2.4.5.1. Thiết lập so sánh với @pm và @pmFromFile Vd: thay vì sử dụng red|blue|green ta có thể sử dụng Code:

SecRule ARGS "@pm red green blue" deny

Nếu có quá nhiều chuỗi muốn đặt vào, ta có thể liệt kê các chuỗi này vào một file và dùng @pmFromFile Vd: Trong file /usr/log/alo.txt chứa nội dung red green blue yellow magenta cyan orange maroon pink black white gray grey violet purple brown tan olive. Ta có rule: Code:

SecRule ARGS “@pmFromFile /usr/log/alo.txt”

2.4.6. Khoá một số request thông thường Giả sử một website khai báo thuế của chính phủ muốn tăng độ bảo mật, website này chỉ mở cửa vào ban ngày (từ 8 giờ sáng đến 5 giờ chiều). Chúng ta có thể sử dụng biến TIME_HOUR cùng với biểu thức chính quy để thực hiện rule này. Code:

SecRule TIME_HOUR !^(8|9|10|11|1213|14|15|16|17)$ deny

2.4.7. Khoá một số request không thông thường Ba phương thức (method) HTTP thường được sử dụng cho request là GET, POST và HEAD. Chúng ta có thể ngạc nhiên khi biết rằng HTTP thực sự thực có rất nhiều phương thức, nếu một web server hỗ trợ WebDAV (Web-based Distributed Authoring và Versioning), tổng số method trở nên gần như 30. Ví dụ, ở đây là những phương thức request thực hiện bởi phiên bản mới nhất của Apache:

Bảng 2.5 Các phương thức request của Apache Trừ khi chúng ta có một lý do nào đó để cho phép một số phương thức không phổ biến được vận hành. Các phương thức không phổ biến còn lại nên ngăn chặn để đề phòng các lỗ hổng trong Apache gây ra bở các phương thức này. Ví dụ: về ngăn chặn tất cả phương thức request không thông thường, chỉ để lại GET, POST, HEAD. Code:

SecRule REQUEST_METHOD “!^(GET|POST|HEAD)” “deny,status:405”

2.4.8. Phát hiện rò rỉ thẻ tín dụng 2.4.8.1. Phát hiện rò rỉ thẻ tín dụng Giả sử website bán hàng của chúng ta có chứa thông tin nhạy cảm của khách hàng như địa chỉ, số thẻ tín dụng… mà họ cung cấp khi mua hàng. Sẽ rất nguy hiểm nếu hacker có thể khai thác các lỗ hổng của website và xem được những thông tin này. Cụ thể, một số lỗi như SQL injection, hacker có thể làm cho các thông tin này hiển thị trên website. Rất may mắn, ModSecurity có thể giải quyết vấn đề trên. Ý tưởng là viết rule để kiểm tra HTTP response. ModSecurity có chứa một toán tử gọi là @verifiCC dùng để kiểm tra một chuỗi số có phải là số thẻ tín dụng hay không. Nếu toán tử trả về true, chúng ta có thể chặn các response không cho gởi đến hacker, bởi vì nó có thể chứa số thẻ tín dụng. Ví dụ một rule như sau Code:

SecResponseBodyAccess On
SecRule RESPONSE_BODY "@verifyCC \d{13,16}" "phase:4,deny,t:removeWhitespace,log,msg:'Possible  credit card number leak detected'"

Chú thích: {13,16} nghĩa là kiểm tra các dãy số từ 13 đến 16 chữ số (số thẻ tín dụng từ 13 đến 16 số) 2.4.8.2. Thuật toán Luhn – Kiểm tra số thẻ tín dụng ModSecurity sử dụng thuật toán Luhn để kiểm tra một dãy số liệu có phải là số thẻ tín dụng hay không Thuật toán này rất đơn giản. Chúng ta có một dãy số được xem xét có phải là số thẻ tín dụng hay không. Thực hiện đảo ngược dãy số, rồi lần lượt nhân số thứ nhất với 1, số thứ hai với 2, số thứ ba với 1, số thứ tư với 2…. Nhân đến khi hết dãy số. Sau đó tách các kết quả thu được thành các số riêng biệt có một chữ số. Rồi cộng các số này lại. Nếu kết quả đạt được chia hết cho 10 thì dãy số đó là số thẻ tín dụng. Để rõ hơn chúng ta xem một ví dụ. Xét số thẻ tín dụng 4012888888881881. Thực hiện đảo ngược dãy số thành 1 8 8 1 8 8 8 8 8 8 8 8 2 1 0 4

Kết quả đạt được là chuỗi 116828168168168162208. Cộng từng chữ số lại ta được kết quả 90 1+1+6+8+2+8+1+6+8+1+6+8+1+6+8+1+6+2+2+0+8 = 90 Kết quả 90 chia hết cho 10, vì vậy dãy số 4012888888881881 là số thẻ tín dụng. 2.4.9. Theo dõi vị trí địa lý của khách truy cập Một địa chỉ IP có thể cung cấp thông tin về địa điểm của người truy cập vào web server trên bản đồ thế giới. Với phiên bản 2.5, ModSecurity hỗ trợ kiểm tra vị trí địa lý của khách truy cập bằng cách tham chiếu đến một cơ sở dữ liệu địa lý (cụ thể là quốc gia). Điều này rất hữu ích cho nhiều ứng dụng. Nếu như chúng ta xử lý thanh toán thẻ tín dụng và muốn vị trí người truy cập phải phù hợp với vị trí địa lý (các quốc gia) mà thẻ tín dụng đã được ban hành. Nếu một thẻ tín dụng Việt Nam đột nhiên được sử dụng tại Đài Loan, chúng ta có thể nghi ngờ và từ chối đơn đặt hàng này. ModSecurity sử dụng GEO collection để lưu trữ thông tin địa lý. Chúng ta hãy xem xét kỹ hơn collection này và các trường mà nó hỗ trợ. 2.4.9.1. Các trường trong collection GEO - COUNTRY_CODE - COUNTRY_CODE3 - COUNTRY_NAME - COUNTRY_CONTINEN - REGION - CITY - POSTAL_CODE - LATITUDE - LONGITUDE - DMA_CODE (US only) - AREA_CODE (US only) Trường COUNTRY_CODE là mã quốc gia gồm hai chữ cái theo tiêu chuẩn ISO 3166. Ví dụ, mã quốc gia của Hoa Kỳ là US. COUNTRY_CODE3 chứa mã quốc gia ba ký tự, ví dụ Hoa Kỳ là USA. Trường COUNTRY_CONTINENT chứa châu lục, ví dụ như EU cho người sử dụng từ châu Âu và AS cho châu Á. 2.4.9.2. Cấm các người dùng từ các quốc gia được chỉ định Đầu tiên, chúng ta cần download GEO database. Thực hiện theo các bước 1. Truy cập vào http://www.maxmind.com và click vào GeoLocation Technology. 2. Click vào GeoLite Country, với phiên bản miễn phí của database. 3. Copy link các phiên bản nhị phân (binary)của GeoLite database. Sử dụng wget để download về, Code:

wget  http://geolite.maxmind.com/download/geoip/database/GeoLiteCountry/GeoIP.dat.gz
 gunzip GeoIP.dat.gz
 mkdir /usr/local/geoip
 mv GeoIP.dat /usr/local/geoip

Ví dụ. Viết rule để chặn các khách truy cập từ Nga(RU) Pakistan(PK) và Trung Quốc(TQ) Code:

SecGeoLookupDb "/usr/local/geoip/GeoIP.dat"
SecRule REMOTE_ADDR “@geoLookup” “deny,nolog,chain,status:500”
SecRule GEO:COUNTRY_CODE “@pm RU PK CN”

Để chặn nhiểu quốc gia hơn, có thể dùng @pmFromFile thay cho @pm 2.4.9.3. Cân bằng tải giữa các server trên các châu lục khác nhau Nếu chúng ta đang cung cấp dữ liệu cho khách truy cập download, chúng ta sẽ tính đến bài toán để người truy cập có được tốc độ download tốt nhất có thể. Giả sử chúng ta có một Server ở Mỹ và một Server ở châu Âu. Bằng cách sử dụng ModSecurity với operator là @geoLookup, ta có thể xác định nơi khách truy cập và chuyển vị trí download đến server gần nhất, vì vậy tốc độ download sẽ cải thiện cũng như cân bằng tải cho Server. Rule trong trường hợp này được viết như sau: Code:

SecRule REQUEST_URI “^/download/(.*)$” “phase:1,capture,chain, wwwect:http://sveu.example.com/download/%{TX.1}”
SecRule REMOTE_ADDR “@geoLookup” “chain”
SecRule GEO:COUNTRY_CONTINENT “@streq EU”

Rule đầu tiên sẽ phù hợp với bất kỳ request nào đến thư mục /download/. Sử dụng dấu chấm(.) và dấu sao(*) để đại diện cho tất cả các file có trong thư mục. ModSecurity sẽ nắm bắt tất cả các giá trị này và lưu nó vào trong biến TX:1. Nếu người truy cập từ Châu Âu, ModSecurity sẽ chuyển hướng request đến server sveu.example.com với đường dẫn thư mục và file request như REQUEST _URI ở rule đầu tiên. 2.4.10. Thực hiện các shell scripts với ModSecurity ModSecurity có thể thực thi một shell scripts khi khớp (math) với một rule. Điều này được thực hiện thông qua actions exec() . Đây là một kỹ thuật rất mạnh cho phép chúng ta sử dụng toàn bộ sức mạnh của shell scripts khi một rules được kích hoạt. Các file shell scripts phải được thực thi bởi user Apache, vì vậy phải chắc chắn rằng user Apache có quyền thực thi scripts. Nếu thực hiện shell scripts không thành công, ModSecurity sẽ ghi lỗi vào file log lỗi của Apache. Dưới đây là một số ứng dụng thông thường khi sử dụng Modsecurity thực hiện Shell scripts. 2.4.10.1. Giởi email cảnh báo Ví dụ, giả sử rằng chúng ta muốn thực hiện một script để gởi cho người quản trị web server email cảnh báo ModSecurity phát hiện hacker đang khai thác lỗi SQL injection. Để làm điều này, chúng ta cần hai bước: 1. Viết một file script có khả năng gởi email cảnh báo đến một địa chỉ email chỉ định. 2. Một rule có tác dụng sẽ gọi script khi phát hiện tấn công. Đối với script, chúng ta có thể sử dụng một standard shell script gọi /bin/sh, (có thể sử dụng Perl script hoặc bất kỳ ngôn ngữ khác). Vd ở đây sử dụng standard shell script và gửi email thông báo cho tanviet12@example.com Tạo một file có tên email.sh trong thư mục /usr/local/bin có nội dung Code:

#!/bin/sh
echo "Mot cuoc tan cong sql injection da bi chan"|mail –s "ModSecurity Alert" tanviet12@example.com
echo Done.

Nếu được kích hoạt, script sẽ gởi email đến địa chỉ tanviet@example.com với tiêu đề ModSecurity Alert. Cuối script là chuỗi Done để ModSecurity nhận biết đã thực thi script thành công. Tiếp theo, viết rule để kích hoạt script khi có tấn công sql injection Code:

SecRule ARGS “drop table” “deny,exec:/usr/local/bin/email.sh”

Bây giờ chúng ta có thể thử nghiệm rule bằng cách truy cập vào đường dẫn http://example.com/test=drop%20table. 2.4.10.2. Gởi nhiều thông tin hơn đến email Email cảnh báo có thể rất hữu ích cho người quản trị web server để nhanh chóng khắc phục được sự cố khi gặp tấn công…Tuy nhiên, chúng ta có thể làm cho các email được gởi chứa nhiều thông tin hơn về cuộc tấn công (các thông tin như IP, request URI,..). ModSecurity cho phép chúng ta thiết lập các biến môi trường thông qua action setenv. Giả sử chúng ta muốn thu thập các thông tin sau khi phát hiện tấn công SQL injection: - Tên máy của server nơi xảy ra cảnh báo - Địa chỉ IP và tên máy của hacker - Các request URI - Các giá trị của tất cả các đối số, cho dù được gửi bằng phương thức GET hay POST - Các ID của request để chúng ta dễ dàng tìm thấy đoạn request trong file log, Đặt các thông tin trên vào sáu biến môi trường riêng biệt: HOSTNAME, REMOTEIP, REMOTEHOST, REQUESTURI, ARGS, và UNIQUEID. Rule được viết như sau: Code:

SecRule ARGS "drop table"  "deny,t:lowercase,setenv:HOSTNAME=%{SERVER_NAME},   setenv:REMOTEIP=%{REMOTE_ADDR},setenv:REQUESTURI=%{REQUEST_URI},setenv:ARGS=%{ARGS}, setenv:UNIQUEID={%UNIQUE_ID},exec:/usr/local/bin/email.sh"

File shell script được viết lại như sau Code:

#!/bin/sh
echo "Mot cuoc tan cong sql injection da bi chan:
Server: $HOSTNAME
Attacking IP: $REMOTEIP
Attacking host: $REMOTEHOST
Request URI: $REQUESTURI
Arguments: $ARGS
Unique ID: $UNIQUEID
Time: `date '+%D %H:%M'`
"|mail –s 'ModSecurity Alert' tanviet12@example.com
echo Done.

2.4.10.3. Chặn tấn công đoán mật khẩu – brute-force Bây giờ chúng ta sẽ dùng collection IP để chặn tấn công brute-force. Dưới đây là một rule viết để chặn tấn công brute-fore. Code:

# Khoi tao ip collection
SecAction "initcol:ip=%{REMOTE_ADDR},pass,phase:1"
# kiem tra truy cap den thu muc administrator
SecRule REQUEST_URI "^/administrator/" "pass,phase:1,setvar:ip.attempts=+1,expirevar:ip.attempts=600"
# Da duoc xac thuc hay chua?
SecRule REQUEST_URI "^/administrator/" "chain,pass,phase:3"
# Neu da duoc xac thu, set counter to 0  
SecRule RESPONSE_STATUS "^2..$" "setvar:ip.attempts=0"
# Deny neu 5 lan xac thuc khong thanh cong
SecRule IP:ATTEMPTS "@gt 5" "phase:1,deny"

2.4.11. Chèn dữ liệu vào response ModSecurity cho phép chúng ta đưa dữ liệu vào response gửi lại cho client nếu SecContentInjection được thiết lập On. Được sử dụng để đưa ra một lời cảnh báo cho hacker khi hành động tấn công được phát hiện. Với ví dụ dưới đây, chúng ta sẽ đưa ra thông báo “Hoc di dung hack nua!” khi ModSecurity phát hiện tấn công XSS. Code:

SecContentInjection  On
SecRule ARGS:username "%" "phase:1,allow,t:urlDecode,append:'>',log,msg:'phat hien tan cong'"

Hình 2.3 Ví dụ về chèn dữ liệu vào Response 2.4.12. Kiểm tra các tập tin được upload lên Một tính năng rất hữu ích ModSecurity là khả năng kiểm tra các file đã được upload lên thông qua một POST request. Vì vậy, chỉ cần thiết lập RequestBodyBuffering On là chúng ta có thể kiểm tra chúng bằng cách sử dụng toán tử @inspectFile. Cần viết một shell script chặn các file được upload lên và quét chúng bằng ClamAV. ClamAV là một antivirus được sử dụng rất phổ biến trên môi trường Unix http://clamav.net) Khi ClamAV đã được cài đặt, sử dụng lệnh clamscan để quét file. Đầu tiên cần thiết lập vị trí thư mục lưu file tạm Code:

SecUploadDir “/tmp/mosecurity”
SecTmpDir “/tmp/mosecurity”

Lưu ý: User apache phải có quyền read và write trên thư mục trên Tiếp theo viết script /usr/local/bin/filescan.sh để thực hiện quét mã độc khi có file upload lên server. Code:

#!/bin/sh
/usr/bin/clamscan $1 > /dev/null 2>&1
if [ "$?" -eq "1" ]; then
  echo "An infected file was found!"
fi

Dòng đầu tiên của script để kích hoạt ClamAV quét thư mục /tmp/ModSecurity. Câu lệnh tiếp theo sẽ kiểm tra giá trị trả về của lệnh thực hiện trước. ClamAV sẽ trả về 1 nếu virus được tìm thấy và 0 nếu ngược lại. Dưới đây là Rule để chặn các file được upload lên và kích hoạt script quét virus. Code:

SecRule  FILES_TMPNAMES “@inspectFile /usr/local/bin/filescan.sh” “phase:2,deny,status:418”

Kết thúc Phần 2

Bảo mật web server Apache với mod Security - Phần 2

xlove — GMT

Bài viết của bạn rất hay - Mình là người mới bắt đầu vọc linux - Mình cài đặt mod_secuurity theo bạn thì gặp một số vấn đề xảy ra mà chưa biết cách giải quyết ra sao. - Mình cài mod_secuurity trên VPS linux CentOS - Mình đã cài xong nhưng khi test thì không cấm được. Khi truy cập vào file hacker.html thì vẫn truy cập được.Không hiểu sao nữa - Mình thử reboot server thì lại gặp rắc rối khi khởi động apache khi dùng lệnh /etc/init.d/httpd start thì báo là failed - Mình thử xem log thì thấy như sau : "Name or Service not know: mod_unique_id: unable to find IPv4 address of "machinename" - Search thì thấy bảo là bạn chưa gán IP cho card mạng trong /etc/host - Mình không biết phải cấu hình card mạng đó như thế nào nữa mong mọi người giúp đỡ Thank all !!!

Bảo mật web server Apache với mod Security - Phần 2

tanviet12 — GMT

Theo mình vấn đề nằm ở hostname và file hosts của bạn. Bạn nên xem lại thử hostname của máy bạn là gì. Và file hosts nội dung ra sao. - Hostname: Để kiểm tra có thể gõ lệnh hostname hoặc vào file cấu hình /etc/sysconfig/network - File hosts: /etc/hosts VD: Nếu hostname của máy bạn là localhost.localdomain thì nội dung file /etc/sysconfig/network thông thường sẽ là Code:

NETWORKING=yes
HOSTNAME=localhost.localdomain

Và file hosts thường sẽ là Code:

# Do not remove the following line, or various programs
# that require network functionality will fail.
127.0.0.1       localhost.localdomain   localhost

Bảo mật web server Apache với mod Security - Phần 2

xlove — GMT

Cảm ơn bạn. Vấn đề của mình đã được giải quyết. Mình đã cài được mod_security thành công. Mình đổi hostname thành localhost thì start được apache Nhưng mỗi lần viết rule thì mình lại phải reboot lại server. Ai có cách nào nhanh hơn không :)

Bảo mật web server Apache với mod Security - Phần 2

tanviet12 — GMT

xlove wrote:

Cảm ơn bạn. Vấn đề của mình đã được giải quyết. Mình đã cài được mod_security thành công. Mình đổi hostname thành localhost thì start được apache Nhưng mỗi lần viết rule thì mình lại phải reboot lại server. Ai có cách nào nhanh hơn không :)

Không phải reboot server đâu bạn. Chỉ cần khởi động lại dịch vụ Code:

/etc/init.d/httpd restart

Bảo mật web server Apache với mod Security - Phần 2

duonglongvinh — GMT

Chào anh cho e hỏi. E đang cài thằng wampsever e đã add mod security vào rồi nhưng sao e file hacker.html của e vẫn chạy bình thường. Không biết là cài trên wampserver có khác gì không, mong anh giúp đỡ

Bảo mật web server Apache với mod Security - Phần 2

conmale — GMT

duonglongvinh wrote:

Chào anh cho e hỏi. E đang cài thằng wampsever e đã add mod security vào rồi nhưng sao e file hacker.html của e vẫn chạy bình thường. Không biết là cài trên wampserver có khác gì không, mong anh giúp đỡ

Đây là một điển hình của loại hỏi mà sẽ không có câu trả lời.

Bảo mật web server Apache với mod Security - Phần 2

cacthanh123 — GMT

Bài viết của bạn rất hay .... Có 1 điều mình muốn bạn giúp ... Mình có 1 forum, nó thường xuyên attack vào register.php, calendar.php, index.php, forum.php, content.php .... Mình có set rule như thế này : SecRule IP:DDOS "@gt 5" "nolog,drop" SecRule REQUEST_URI "^/calendar\.php" "nolog,phase:1,setvar:ip.ddos=+1,deprecatevar:ip.ddos=5/60,expirevar:ip.ddos=600" SecRule REQUEST_URI "^/calendar\*" "nolog,phase:1,setvar:ip.ddos=+1,deprecatevar:ip.ddos=5/60,expirevar:ip.ddos=600" SecRule REQUEST_URI "^/register\.php" "nolog,phase:1,setvar:ip.ddos=+1,deprecatevar:ip.ddos=5/60,expirevar:ip.ddos=600" SecRule REQUEST_URI "^/register\*" "nolog,phase:1,setvar:ip.ddos=+1,deprecatevar:ip.ddos=5/60,expirevar:ip.ddos=600" SecRule REQUEST_URI "^/index\.php" "nolog,phase:1,setvar:ip.ddos=+1,deprecatevar:ip.ddos=5/60,expirevar:ip.ddos=600" SecRule REQUEST_URI "^/index\.html" "nolog,phase:1,setvar:ip.ddos=+1,deprecatevar:ip.ddos=5/60,expirevar:ip.ddos=600" SecRule REQUEST_URI "^/login\.php" "nolog,phase:1,setvar:ip.ddos=+1,deprecatevar:ip.ddos=5/60,expirevar:ip.ddos=600" SecRule REQUEST_URI "^/content\.php" "nolog,phase:1,setvar:ip.ddos=+1,deprecatevar:ip.ddos=5/60,expirevar:ip.ddos=600" SecRule REQUEST_URI "^/blog\.php" "nolog,phase:1,setvar:ip.ddos=+1,deprecatevar:ip.ddos=5/60,expirevar:ip.ddos=600" SecRule REQUEST_URI "^/forum\.php" "nolog,phase:1,setvar:ip.ddos=+1,deprecatevar:ip.ddos=5/60,expirevar:ip.ddos=600" SecRule REQUEST_URI "^/forumdisplay\.php" "nolog,phase:1,setvar:ip.ddos=+1,deprecatevar:ip.ddos=5/60,expirevar:ip.ddos=600" SecRule REQUEST_URI "^/forumdisplay\*" "nolog,phase:1,setvar:ip.ddos=+1,deprecatevar:ip.ddos=5/60,expirevar:ip.ddos=600" SecRule REQUEST_URI "^/showthread\.php" "nolog,phase:1,setvar:ip.ddos=+1,deprecatevar:ip.ddos=5/60,expirevar:ip.ddos=600" SecRule REQUEST_URI "^/showthread\*" "nolog,phase:1,setvar:ip.ddos=+1,deprecatevar:ip.ddos=5/60,expirevar:ip.ddos=600" Liệu có chống đc ddos không ? Hiện tại mình dùng JANIDOS tools khi ddos thì các request bị trả về, nhưng với cái này : DDos Attack site down = HTML tool share by HiSoKa Download : http://www.mediafire.com/?uv62arviphu8zj8 Chỉ là 1 file html bình thường, bấm nút thì ram của server tụt hẳn và 5p sau die liền .... Bạn có thể giúp mình một số rules để bảo đảm ddos + flood khó thể xâm hại đc ko ? Cảm ơn nhiều nhé ....

Bảo mật web server Apache với mod Security - Phần 2

conmale — GMT

cacthanh123 wrote:

Bài viết của bạn rất hay .... Có 1 điều mình muốn bạn giúp ... Mình có 1 forum, nó thường xuyên attack vào register.php, calendar.php, index.php, forum.php, content.php .... Mình có set rule như thế này : SecRule IP:DDOS "@gt 5" "nolog,drop" SecRule REQUEST_URI "^/calendar\.php" "nolog,phase:1,setvar:ip.ddos=+1,deprecatevar:ip.ddos=5/60,expirevar:ip.ddos=600" SecRule REQUEST_URI "^/calendar\*" "nolog,phase:1,setvar:ip.ddos=+1,deprecatevar:ip.ddos=5/60,expirevar:ip.ddos=600" SecRule REQUEST_URI "^/register\.php" "nolog,phase:1,setvar:ip.ddos=+1,deprecatevar:ip.ddos=5/60,expirevar:ip.ddos=600" SecRule REQUEST_URI "^/register\*" "nolog,phase:1,setvar:ip.ddos=+1,deprecatevar:ip.ddos=5/60,expirevar:ip.ddos=600" SecRule REQUEST_URI "^/index\.php" "nolog,phase:1,setvar:ip.ddos=+1,deprecatevar:ip.ddos=5/60,expirevar:ip.ddos=600" SecRule REQUEST_URI "^/index\.html" "nolog,phase:1,setvar:ip.ddos=+1,deprecatevar:ip.ddos=5/60,expirevar:ip.ddos=600" SecRule REQUEST_URI "^/login\.php" "nolog,phase:1,setvar:ip.ddos=+1,deprecatevar:ip.ddos=5/60,expirevar:ip.ddos=600" SecRule REQUEST_URI "^/content\.php" "nolog,phase:1,setvar:ip.ddos=+1,deprecatevar:ip.ddos=5/60,expirevar:ip.ddos=600" SecRule REQUEST_URI "^/blog\.php" "nolog,phase:1,setvar:ip.ddos=+1,deprecatevar:ip.ddos=5/60,expirevar:ip.ddos=600" SecRule REQUEST_URI "^/forum\.php" "nolog,phase:1,setvar:ip.ddos=+1,deprecatevar:ip.ddos=5/60,expirevar:ip.ddos=600" SecRule REQUEST_URI "^/forumdisplay\.php" "nolog,phase:1,setvar:ip.ddos=+1,deprecatevar:ip.ddos=5/60,expirevar:ip.ddos=600" SecRule REQUEST_URI "^/forumdisplay\*" "nolog,phase:1,setvar:ip.ddos=+1,deprecatevar:ip.ddos=5/60,expirevar:ip.ddos=600" SecRule REQUEST_URI "^/showthread\.php" "nolog,phase:1,setvar:ip.ddos=+1,deprecatevar:ip.ddos=5/60,expirevar:ip.ddos=600" SecRule REQUEST_URI "^/showthread\*" "nolog,phase:1,setvar:ip.ddos=+1,deprecatevar:ip.ddos=5/60,expirevar:ip.ddos=600" Liệu có chống đc ddos không ? Hiện tại mình dùng JANIDOS tools khi ddos thì các request bị trả về, nhưng với cái này : DDos Attack site down = HTML tool share by HiSoKa Download : http://www.mediafire.com/?uv62arviphu8zj8 Chỉ là 1 file html bình thường, bấm nút thì ram của server tụt hẳn và 5p sau die liền .... Bạn có thể giúp mình một số rules để bảo đảm ddos + flood khó thể xâm hại đc ko ? Cảm ơn nhiều nhé ....

Phải nắm rõ "HTML tool share by HiSoKa" gởi cái gì, gởi bao nhiêu trong vòng một khoảng thời gian để mà điều chỉnh các thông số deprecatevar, expirevar cho thích hợp. Bồ cần chạy tcpdump để capture các gói tin trong khi dùng "HTML tool share by HiSoKa" để tấn công rồi mới phân tích mớ gói tin ấy. Khi có kết quả rồi thì mới dùng nó mà áp dụng cho nhóm luật. Không bao giờ có những "luật" nào có thể đáp ứng hết tất cả các dạng DDoS + flood cả. Nên nhớ, những thứ tool lặt vặt mà bồ nêu ra không phải là DDoS.

Bảo mật web server Apache với mod Security - Phần 2

cacthanh123 — GMT

Thứ 1 mình muốn hỏi : Các rules trên có chống đc khi bọn chúng dùng tools ddos treo trên VPS, request liên tục vào các file trên. Liệu rules đó mình ghi có đúng không ???? Có rules nào mà khi gặp request trái phép thì deny liền không ? Thứ 2 mình muốn hỏi : Như HVA đã nói, dùng Rule : SecRule REQUEST_URI "../" "t:urlDecode,deny" để deta61tshell thì ok, hấu hết các shell sau khi thực thi, link sẽ có dạng %2%2 ... Nhưng nếu chạy rules nó, thì không thể load ảnh của website lên được, nó sẽ chặn toàn bộ images trên host của khách, các images đó sẽ thành forbidden Thứ 3 mình muốn hỏi : Có thể cho mình xin cái rules chung, chi attacker gởi các packet bất hợp pháp thì deny liền và chặn IP đó, save vào log, unban sau 1 thời gian hoặc có thể cấm luôn nếu tiếp tục request ! Có cách nào giảm tải cho server không ? các process httpd chiếm quá nhiều bộ nhớ ram. Tối nay check cái HTML tool share by HiSoKa coi nó gởi các gói tin như thế nào thì HVA giúp mình deny nó nhé. ============================ Cảm ơn ADMIN HVA nhiều ạ !

Bảo mật web server Apache với mod Security - Phần 2

conmale — GMT

Không có cái rule chung nào hết. Bảo mật không phải là dùng rules của thiên hạ để áp dụng cho mình mà phải hiểu rõ mình bị tấn công như thế nào để điều chỉnh cho hợp lý.

Bảo mật web server Apache với mod Security - Phần 2

chiro8x — GMT

cacthanh123 wrote:

Thứ 1 mình muốn hỏi : Các rules trên có chống đc khi bọn chúng dùng tools ddos treo trên VPS, request liên tục vào các file trên. Liệu rules đó mình ghi có đúng không ???? Có rules nào mà khi gặp request trái phép thì deny liền không ? Thứ 2 mình muốn hỏi : Như HVA đã nói, dùng Rule : SecRule REQUEST_URI "../" "t:urlDecode,deny" để deta61tshell thì ok, hấu hết các shell sau khi thực thi, link sẽ có dạng %2%2 ... Nhưng nếu chạy rules nó, thì không thể load ảnh của website lên được, nó sẽ chặn toàn bộ images trên host của khách, các images đó sẽ thành forbidden Thứ 3 mình muốn hỏi : Có thể cho mình xin cái rules chung, chi attacker gởi các packet bất hợp pháp thì deny liền và chặn IP đó, save vào log, unban sau 1 thời gian hoặc có thể cấm luôn nếu tiếp tục request ! Có cách nào giảm tải cho server không ? các process httpd chiếm quá nhiều bộ nhớ ram. Tối nay check cái HTML tool share by HiSoKa coi nó gởi các gói tin như thế nào thì HVA giúp mình deny nó nhé. ============================ Cảm ơn ADMIN HVA nhiều ạ !

Một đống hổ lốn ! pha tạp các kiểu "hiểu biết".

Bảo mật web server Apache với mod Security - Phần 2

cacthanh123 — GMT

Bạn vẫn chưa phúc đáp giúp mình các vấn đề mình nêu ra :( Thank bạn nhiều lắm !

Bảo mật web server Apache với mod Security - Phần 2

chiro8x — GMT

cacthanh123 wrote:

Các rules trên có chống đc khi bọn chúng dùng tools ddos treo trên VPS, request liên tục vào các file trên. Liệu rules đó mình ghi có đúng không ????

Tôi chưa tài về dùng thử cái tool của bạn (tôi cũng không có ý định làm thế), đây rất có thể một tool HTTP FLood sử dụng các anonymous proxy thực hiện các request, luật của bạn đưa ra rất lõng lẻo vì, người tấn công có thể thay đổi tần số và thời gian thực hiện truy vấn, cũng như tập tin truy vấn.

cacthanh123 wrote:

Như HVA đã nói, dùng Rule : SecRule REQUEST_URI "../" "t:urlDecode,deny" để deta61tshell thì ok, hấu hết các shell sau khi thực thi, link sẽ có dạng %2%2 ... Nhưng nếu chạy rules nó, thì không thể load ảnh của website lên được, nó sẽ chặn toàn bộ images trên host của khách, các images đó sẽ thành forbidden

%2 là cái gì ? bạn biết đích xác mình nói đúng chứ ?. Bạn nên hiểu ascii table sẽ hiểu vì sao các images của bạn không hiển thị được.

cacthanh123 wrote:

Có thể cho mình xin cái rules chung, chi attacker gởi các packet bất hợp pháp thì deny liền và chặn IP đó, save vào log, unban sau 1 thời gian hoặc có thể cấm luôn nếu tiếp tục request ! Có cách nào giảm tải cho server không ? các process httpd chiếm quá nhiều bộ nhớ ram. Tối nay check cái HTML tool share by HiSoKa coi nó gởi các gói tin như thế nào thì HVA giúp mình deny nó nhé.

Cái này anh conmale nói quá rõ rồi. Mình nói thêm về packet và request, bạn đang nhầm lẫn hai thứ này, khi một ứng dụng ở application layer, sẽ rất khó khăn để can thiệp sâu transport layer, và kết quả là các biện pháp phòng tránh trở nên không phù hợp thậm chí còn phản tác dụng. P/S: Nói thêm là thằng Hisoka trong bộ manga Hunter X Hunter bá đạo lắm, mình sợ mấy anh vô đối lắm.

Bảo mật web server Apache với mod Security - Phần 2

vd_ — GMT

modsec output log -> ossec/fail2ban -> iptables/snortsam để chặn sẽ giảm tải. Dùng rule deny của modsec không đủ vì khi request đến cửa modsec thì server đã phải tốn khá khá cpu rồi.

Bảo mật web server Apache với mod Security - Phần 2

tnt.ad — GMT

Chào bạn, Mình đang tìm hiểu về mod_security, mình xin hỏi một chút: Mình đã làm đến đoạn copy file mod_security2.so vào thư mục /etc/httpd/modules Nhưng trong /etc/httpd/ không thấy có thư mục modules mà chỉ có các thư mục và file sau: build conf lib man modules (file modules được tạo ra có lẽ do mình dùng câu lệnh cp mod_security2.so /etc/httpd/modules trước đó) Vì vậy mình đã copy file mod_security2.so vào thư mục /usr/lib/apache/ và LoadModule từ đó. Như trên, mình không tìm thấy thư mục conf.d (nơi chưa các file cấu hình riêng của apache) trong /etc/httpd/ và mình thấy có thư mục là /etc/httpd/conf/extra, nên mình đã tạo file cấu hình cho Mod Security (httpd-modsec.conf) với nội dung mà bạn đã đưa ra ở trê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"

Sau đó mình restart lại apache, module được load, xong ko có tác dụng, mình thử mở bằng trình duyệt 1 file hacker.txt nhưng vẫn xem được bình thường mà ko thấy báo lỗi 404. Vậy mình xin hỏi quá trình làm của mình sai ở bước nào? Mong được chỉ giáo!

Bảo mật web server Apache với mod Security - Phần 2

conmale — GMT

tnt.ad wrote:

Chào bạn, Mình đang tìm hiểu về mod_security, mình xin hỏi một chút: Mình đã làm đến đoạn copy file mod_security2.so vào thư mục /etc/httpd/modules Nhưng trong /etc/httpd/ không thấy có thư mục modules mà chỉ có các thư mục và file sau: build conf lib man modules (file modules được tạo ra có lẽ do mình dùng câu lệnh cp mod_security2.so /etc/httpd/modules trước đó) Vì vậy mình đã copy file mod_security2.so vào thư mục /usr/lib/apache/ và LoadModule từ đó. Như trên, mình không tìm thấy thư mục conf.d (nơi chưa các file cấu hình riêng của apache) trong /etc/httpd/ và mình thấy có thư mục là /etc/httpd/conf/extra, nên mình đã tạo file cấu hình cho Mod Security (httpd-modsec.conf) với nội dung mà bạn đã đưa ra ở trê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"
 
Sau đó mình restart lại apache, module được load, xong ko có tác dụng, mình thử mở bằng trình duyệt 1 file hacker.txt nhưng vẫn xem được bình thường mà ko thấy báo lỗi 404. Vậy mình xin hỏi quá trình làm của mình sai ở bước nào? Mong được chỉ giáo!

---> đừng đọc và làm theo hướng dẫn một cách cứng nhắc như vậy. Apache có nhiều dạng layout khác nhau tuỳ distro, tuỳ cách cài (xuyên qua gói có sẵn hay compile). Bởi vậy, tuỳ layout mình hiện có mà xác định vị trí của "modules" nằm ở đâu thay vì làm theo chính xác như hướng dẫn.

Bảo mật web server Apache với mod Security - Phần 2

tnt.ad — GMT

Chào anh conmale, Hôm qua em đã xử lý được vấn đề này, do em chưa load file cấu hình của Mod security trong httpd.conf. Hiện MS đã được kích hoạt, em sẽ nghiên cứu để viết rule cho vụ DDOS mà hôm trước em có hỏi và được anh trả lời tại www.hvaonline.net/hvaonline/posts/list/43012.html Trước khi em gặp phải vụ DDOS này, Linux và VPS manager đối với em hoàn toàn mới mẻ (vì em ko làm chuyên về kỹ thuật), mỗi trải nghiệm đều rất lý thú tuy có phải mất chút thời gian và sức khoẻ. Hy vọng nhận được nhiều sự giúp đỡ từ anh và mọi người. Chúc anh sức khoẻ!

Bảo mật web server Apache với mod Security - Phần 2

localroot — GMT

Chào mọi người, hiện tại em cũng gặp trường hợp khó với mod_secu 2 này là apache ko start đc, yum-updatesd faild. Mong giúp đỡ. VPS -Centos 5.8/ Cài cpanel 11 Sau đây là tiến trình em làm theo hướng dẫn, để mọi người cùng nắm bắt : Tại /root : B1 : wget B2 : tar B3 : Yum : apxs,libxml2,pcre B4 : mod_unique_id Code: LoadModule unique_id_module modules/mod_unique_id.so Vì check chưa có nên em thêm vào file httpd.conf trong /usr/local/apache/conf B5 : cd modsecurity-apache_2.6.7/apache2/ ./configure thì không được : -bash: ./configure: No such file or directory, nhưng cd modsecurity-apache_2.6.7 ./configure thì lại được : configure: using curl v7.15.5 configure: creating ./config.status config.status: creating Makefile config.status: creating tools/Makefile config.status: creating apache2/Makefile config.status: creating build/apxs-wrapper config.status: creating mlogc/mlogc-batch-load.pl config.status: creating tests/run-unit-tests.pl config.status: creating tests/run-regression-tests.pl config.status: creating tests/gen_rx-pm.pl config.status: creating tests/csv_rx-pm.pl config.status: creating tests/regression/server_root/conf/httpd.conf config.status: creating tools/rules-updater.pl config.status: creating mlogc/Makefile config.status: creating tests/Makefile config.status: creating apache2/modsecurity_config_auto.h config.status: apache2/modsecurity_config_auto.h is unchanged config.status: executing depfiles commands config.status: executing libtool commands , sau đó em tiến hành make make[2]: Leaving directory `/root/modsecurity-apache_2.6.7/apache2' make[1]: Leaving directory `/root/modsecurity-apache_2.6.7/apache2' Making all in mlogc make[1]: Entering directory `/root/modsecurity-apache_2.6.7/mlogc' make[1]: Nothing to be done for `all'. make[1]: Leaving directory `/root/modsecurity-apache_2.6.7/mlogc' Making all in tests make[1]: Entering directory `/root/modsecurity-apache_2.6.7/tests' make[1]: Nothing to be done for `all'. make[1]: Leaving directory `/root/modsecurity-apache_2.6.7/tests' make[1]: Entering directory `/root/modsecurity-apache_2.6.7' make[1]: Nothing to be done for `all-am'. make[1]: Leaving directory `/root/modsecurity-apache_2.6.7' , Sau đó em copy mod_security2.so vào /usr/local/apache/modules Như vậy là hoàn thành...Restart lại vps thì như trên đầu đề e nói, bỏ LoadModule unique_id_module modules/mod_unique_id.so thì lại bình thường. Có điều mod_secu không hoạt động, thêm nữa là edit file php.ini safe mode off nhưng khi up shell để view thì safe mode vẫn là On Em bó tay. Mong mọi người chỉ giúp em phần nào còn thiếu sót. File host em : IP(Địa chỉ Ip của vps) host.domain.com host

Bảo mật web server Apache với mod Security - Phần 2

buiduongthe — GMT

Xin chào các anh trong HVA lần đầu tiên hỏi có gì sai xót mong các anh bỏ qua +Em đã cài mod_security + Trong phpinfo thấy đã load mod_security2 + em test abc.com/hacker.html kết quả như sau Not Found The requested URL /hacker.html was not found on this server. Additionally, a 404 Not Found error was encountered while trying to use an ErrorDocument to handle the request. Apache/2.2.0 (Fedora) Server at abc.com Port 80 Không biết đã đúng chưa? em tắt mod_security thì chạy được file hacker.html + Em chặn khách từ Trung Quoc, test bằng cách em dùng proxy Trung Quoc, nhưng chăn không được, thấy truy cập bình thường + Chăn đăng nhập administrator sai 5 lần là khóa, kết quả vẫn không được Các anh HVA hướng dẫn em test, em đang bị Trung Quoc Spam nhiều quá! Cảm ơn HVA

Bảo mật web server Apache với mod Security - Phần 2

xwm — GMT

1. Nếu bạn dùng rule : SecDefaultAction "phase:2,deny,log,status:404" thì tất nhiên xảy ra lỗi 404 NOT FOUND thì đúng rồi, để chắc chắn mod_sec hoạt động bạn thay thành :SecDefaultAction "phase:2,deny,log,status:406", nếu truy cập xuất liện lỗi: 406 not acceptable thì mod_sec của cậu đã hoạt động. (Khuyên bạn nên dùng HTTP status codes: 406 để dễ quản lý và tránh nhầm lẫn) 2. Deny ip Trung Quốc thì bạn nên dùng iptables deny theo range cho nó nhẹ. 3. Để tránh brute force các link login admin bạn có thể dùng các plugin đính kèm của joomla, wp, vbulletin... Nếu dùng mod_sec bạn có thể tham khảo link này: http://halfelf.org/2013/wp-login-protection-modsec/