Hướng dẫn cài đặt mod_security cho Server Apache

[python]

ModSecurity 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 ModSecurity Hand Book. Ô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 ModSecurity 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 ônghttp://www.thinkingstone.com/

1. Các khả năng của ModSecurity:

• Lọc các request: 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ý.
• Chống các kỹ thuật tấn công: paths và parameters được chuẩn hoá trước khi phân tích để chống các cuộc tấn công. Kỹ thuật này sẽ được thảo luận ở phần sau.
• Hiểu giao thức HTTP: ModSecurity là application firewall nên nó có khả năng hiểu được HTTP protocol. 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 parameters hay cookies của các requests ...
• Phân tích nội dung của phương thức POST: 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.
• Tự động ghi log: 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.
• Lọc giao thức HTTPS: ModSecurity có thể phân tích HTTPS.
• Phân tích những yêu cầu được nén: ModSecurity sẽ phân tích sau khi đã decompress các request data.

Quá trình xử lý các request của Apache và ModSecurity:

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 (phase: 1): 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 (phase: 2): đâ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 (phase: 3): đâ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 (phase: 4): đây là thời điểm bạn muốn kiểm tra những dữ liệu HTML gửi trả về

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.

2. Cài đặt mod_security và cấu hình mod_security
mod_security có thể cài trên nhiều nền tảng để hoạt động cùng Apache như Windows, Linux, … Sau đây mình sẽ giới thiệu về cách cài đặt và cấu hình mod_security trên CentOS(5.6)
2.1 Cài đặt:

• Chuẩn bị những thư viện sau (nếu chưa có):

#yum install httpd-devel
#yum install libxml2

load mod_unique_id.so:
truy cập vào file httpd.conf( /etc/httpd/conf) và bỏ dấu '#' ở dòng sau:

LoadModule unique_id_module modules/mod_unique_id.so

• Download ModSecurity:

#wget http://www.ModSecurity.org/download/ModSecurity-apache_2.5.13.tar.gz

• Giải nén file vừa down:

#tar xzvf ModSecurity-apache_2.5.13.tar.gz

• Biên dịch mod_security:

cd modsecurity-apache_2.5.13
./configure
make install
cp modsecurity.conf-recommended /etc/httpd/conf.d/modsecurity.conf

• load mod_security

LoadModule security2_module modules/ModSecurity2.so

Restart Apache:

#service httpd restart

2.2 Cấu hình cơ bản:

• 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) để ModSecurity hoạt động. Các rules này được thể hiện dưới dạng các dẫn hướng (directive) 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)

• Tắt hoặc bật hoạt động của các Rule
  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
  Dẫn hướng 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"

  
  Giải thích:
  
  Phase:2:action này được xử lý ở phase thứ 2(Phase Request Body).
  Deny:Chặn request.
  Log: có ghi lại log
  Status:403:đặt status thông báo là 403.

3.Rules

• Cấu trúc cơ bản của một rules:
  

  SecRule VARIABLES OPERATOR [ACTIONS]

  Dưới đây là một ví dụ về các sử dụng biến ARGS
  

  SecRule ARGS dirty.

  (dirty chuỗi ký tự đại diện cho các giá trị mà ARGS có thể nhận)
  Có thể dùng 1 hay nhiều variables
  

  SecRule ARGS|REQUEST_HEADERS:User-Agent dirty

  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

Dưới dây là một HTTP request:

GET /documentation/index.html HTTP/1.1

Host: www.ModSecurity.org

User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.1)

ecko/20060124 Firefox/1.5.0.1

Accept:

text/xml,application/xml,application/xhtml+xml, text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
Accept-Language: en-us,en;q=0.5

Accept-Encoding: gzip,deflate

Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7

Keep-Alive: 300

Connection: keep-alive

Referer: http://www.ModSecurity.org/index.php

Cookie:__utmz=129890064.1139909500.1.1.utmccn=(direct)| utmcsr=(direct)|utmcmd=(none); __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ó để 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”

Toán tử (Operators)

Xác định phương pháp và so sánh khớp dữ liệu để kích hoạt Action.

SecRule ARGS "@rx dirty"

Sử dụng !@ để chỉ ra một phủ định của operator

SecRule &ARGS "!@rx ^0$"

Ở đây chúng ta đề cập đến một operator 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ặcjoy
[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ì ModSecurity 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: 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
  
  deny: Request sẽ bị ngắt, ModSecurity 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õ allowhase 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 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ì ModSecurity 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 ModSecurity sẽ đợi một thời gian n ms rồi mới trả về kết quả.
  
  Flow action ảnh hưởng tới thứ tự các rule được xử lý
  
  chain: kết nối 2 hay nhiều rules lại với nhau
  
  ví dụ:
  
  

  SecRule REQUEST_HEADERS:User-agent “Red Bullet”“chain,deny”
  
  SecRule REMOTE_ADDR “^192\.168\.1\.” Bullet” “chain,deny” SecRule REMOTE_ADDR “^192\.168\.1\.”

  
  skipnext:n ModSecurity sẽ bỏ qua n rules theo sau nó
  
  ví dụ:
  
  

  SecRule REQUEST_HEADERS:User-agent“Red Bullet”“deny” skipnext:3

  
  Việc thực hiện các action hoàn toàn không phụ thuộc vào thứ tự viết, ta xét ví dụ sau:
  
  Đăt vấn đề ta cần chặn một trang web có URI là Hack, nhưng chỉ cần chặn lỗi SQL injection xuất phát từ URI trên.
  
  Ta xây dựng hai rule như sau:
  
  

  SecRule REQUEST_URI "HackMe" "deny,status:403,phase:2,chain"
  
  SecRule REQUEST_URI "SQLinjection"

  
  
  Rule này sẽ xử lý ở phase 2 khi đó nó sẽ match với
  
  

  SecRule REQUEST_URI "SQLinjection"

  
  Và deny URL SQLinjection.
  
  

4.Logging
4.1 Debug Log
Sử dụng SecDebugLog Dẫn hướng 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 Dẫn hướng:

SecDebugLogLevel  4

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

• 0 – không ghi log.
• 1 –Chỉ liệt kê các request bị chặn.
• 2 –Cảnh báo.
• 3 – Thông báo cho admin
• 4 – Chi tiết về các transaction được xử lý.
• 5 – Cũng như số 4 như thêm những thông tin chi tiết hơn đã được xử lý
• 9 – Ghi lại mọi thứ, rất chi tiết và đầy đủ về toàn bộ thông tin.

4.2 Audit logging
ModSecurity 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”:

SecAuditEngine On  //bật audit log lên
SecAuditLog logs/audit.log   //chỉ ra file lưu trữ log chính
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

ModSecurity-message: Access denied with code 403. Pattern match

"^$" at HEADER("User-Agent")

ModSecurity-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—

4.3 Tuỳ biến thông tin log:
SecAuditEngine chấp nhận 3 giá trị sau:

• On – log tất cả các requests
• Off – không log
• RelevantOnly – chỉ log những gì được sinh ra bởi các bộ lọc rules

Ngoài ra ModSecurity 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

5.Core Rule Set và một số cách phòng chống một số lỗi thường có trên apache:
5.1 Core Rule Set (CRS):
CRS là một hệ thống bao gồm các tập luận đã được xây dựng sẵn dựa trên các lỗi thường có trên ứng dụng Web như XSS, SQL injection…

Việc dùng core ruset sẽ làm cho người quản trị đơn giản hơn trong việc xây dựng các rules , vì core rule set đã được xây dựng theo một chuẩn chung dựa trên các lỗi thường có đối với server Apache.

Sử dụng những kỹ thuật sau:

• HTTP Protection - nhận diện những lỗ hổng của giao thức HTTP và khai báo những chính sách hữu dụng.
• Real-time Blacklist Lookups – sử dụng Party IP Reputation thứ 3.
• Web-based Malware Detection- nhận diện những trang web có nội dung độc hại bằng việc kiểm tra lại Google Safe Browsing API.
• HTTP Denial of Service Protections-Phòng chống tắc nghẽ trong giao thức HTTP và làm chậm tấn công DDOS.
• Common Web Attacks Protection-nhận diện những tấn công an ninh vào những ứng dụng web nói chung.
• Automation Detection-nhận diện những máy tự động,thu thập thông tin, quét và những hoạt động bề ngoài độc hại.
• Integration with AV Scanning for File Uploads-nhận diễn những file độc hại được tải lên thông qua ứng dụng web.
• Tracking Sensitive Data- Theo dõi Credit Card hữu dụng và khóa những Credit Card bị lộ.
• Trojan Protection –nhận diện những truy cập tới Trojan.
• Identification of Application Defects- cảnh báo những ứng dụng bị cấu hình lỗi
• Error Detection and Hiding – che giấu những thông tin lỗi được gửi bởi server.

Cách cài đặt:

Ta cần phải dowload Core Rule tại địa chỉ sau:http://sourceforge.net/projects/mod-security/files/ModSecurity-crs/0-CURRENT/

Giải nén file ModSecurity-crs_2.2.4.zip vừa download được. Bên trong ModSecurity-crs_2.2.4 có các thư mục chưa các rule như sau:

• activated_rules.
• base_rules.
• experimental_rules.
• experimental_rules.cc
• slr_rules

Copy toàn bộ các như mục trên vào trong apache và mở file httpd.conf và thêm dòng sau:

Với module base_rule

Include conf/ModSecurity_crs/*.conf
Include conf/ModSecurity_crs/base_rules/*.conf

Các module khác chúng ta làm tương tự

5.2 Thiết lập chống một số lỗi cơ bản:

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

• XSS Attack

SecRule ARGS "alert\s+*\("t:lowercase,deny,msg:'XSS'"

SecRule ARGS "&\{.+\}" "t:lowchimercase,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'"

• Website defacement
  Đây là kiểu tấn công dựa trên việc làm thay đổi nội dung web site theo ý muốn của hacker ví dụ:

Cơ chế của việc phòng chống lỗi này ta tiến hành như sau: đầu tiên ta tạo một token bằng việc mã hóa md5 ip của những người đã truy cập vào web site (minh họa bằng mã JSP)

Khi bắt đầu có request tới thì token của client sẽ được tính toán MD5 dựa trên IP của người sử dụng. Token này sẽ được đặt vào trong web site có màu trắng để làm cho người duyệt web không thể nhìn thấy nó.

Tại thời điểm response body chúng ta sẽ tiến hành so sánh giữa ip client mã hóa MD5 và token đã được tính toán và gán vào trong page ở quá trình response body.Nếu không giống nhau thì ta nhận diện ip đó là defaced , tiến hành block và báo lại cho người quản trị qua email

Chúng ta sử dụng rule sau để phòng tránh:

SecRule REMOTE_ADDR ".*"  "phase:4,deny,chain,t:md5,t:hexEncode,

exec:/usr/bin/emailadmin.sh"

SecRule RESPONSE_BODY "!@contains %{MATCHED_VAR}"

• Directory indexing
  
  Khi một web site không có file index thì danh sách toàn bộ file cũng như thư mục sẽ được liệt kê khi chung ta truy nhập vào địa chỉ chưa web site đó
  
  Dựa vào điều này hacker có thể truy cập hoặc tải về một số file đặc biệt ,qua đó sẽ tiến hành phân tích và tìm ra cách để tân công website.
  ví dụ:
  
  

Ở hình trên ctfDB.sql là file chưa cơ sở dữ liệu của web site ,hacker có thể dow về để biết được tên các bảng ,các trường qua đó có thể tiến hành khai SQL injection.
Từ đó có cách phòng chống với ModSecurity như sau:

# Prevent directory listings from accidentally being returned

SecRule REQUEST_URI "/$" "phase:4,deny,chain,log,msg:'Directory index returned'"

SecRule RESPONSE_BODY "Index of /"

• Chống DDos

Như các bạn điều biết DDoS(Viết tắt của Distributed Denial of Service) :là kiểu tấn công làm cho hệ thống máy tính hay hệ thống mạng quá tải, không thể cung cấp dịch vụ hoặc phải dừng hoạt động. Trong các cuộc tấn công DDoS, máy chủ dịch vụ sẽ bị "ngập" bởi hàng loạt các lệnh truy cập từ lượng kết nối khổng lồ. Khi số lệnh truy cập quá lớn, máy chủ sẽ quá tải và không còn khả năng xử lý các yêu cầu. Hậu quả là người dùng không thể truy cập vào các dịch vụ trên các trang web bị tấn công DDoS.
Tấn công từ chối dịch vụ có thẻ được thực hiện theo một số cách nhất định. Có năm kiểu tấn công cơ bản sau đây:

• Nhằm tiêu tốn tài nguyên tính toán như băng thông, dung lượng đĩa cứng hoặc thời gian xử lý
• Phá vỡ các thông tin cấu hình như thông tin định tuyến
• Phá vỡ các trạng thái thông tin như việc tự động reset lại các phiên TCP.
• Phá vỡ các thành phần vật lý của mạng máy tính
• Làm tắc nghẽn thông tin liên lạc có chủ đích giữa các người dùng và nạn nhân dẫn đến việc liên lạc giữa hai bên không được thông suốt.

Một cuộc tấn công từ chối dịch vụ có thể bao gồm cả việc thực thi malware nhằm:

• Làm quá tải năng lực xử lý, dẫn đến hệ thống không thể thực thi bất kì một công việc nào khác.
• Những lỗi gọi tức thì trong microcode của máy tính.
• Những lỗi gọi tức thì trong chuỗi chỉ thị, dẫn đến máy tính rơi vào trạng thái hoạt động không ổn định hoặc bị đơ.
• Những lỗi có thể khai thác được ở hệ điều hành dẫn đến việc thiếu thốn tài nguyên hoặc bị thrashing. VD: như sử dụng tất cả các năng lực có sẵn dẫn đến không một công việc thực tế nào có thể hoàn thành được.
• Gây crash hệ thống.
• Tấn công từ chối dịch vụ iFrame: trong một trang HTML có thể gọi đến một trang web nào đó với rất nhiều yêu cầu và trong rất nhiều lần cho đến khi băng thông của trang web đó bị quá hạn.

Do đó chúng ta có thể thấy được sự cần thiết của việc giảm thiểu tới mức tối đa tác các cuộc tấn công DDoS. Vậy ModSecurity có thể làm được nhưng gì ?

Như đã trình bày ở trên ta nhận thấy rằng DDoS có thể xẩy ra ở tầng 3(Tầng mạng) và tầng 7(Tầng ứng dụng) theo mô hình OSI.Do MosSecurity hoạt động trên tầng 7 nên nó chỉ có khả năng ngăn chặn DDoS theo giao thức HTTP .

Việc phòng chông này thực ra vô cùng đơn giản ta chỉ cần tao ra một Rule nhận diện số lượng request từ một địa chỉ IP nào đó tới Server . Nếu số lượng request quá lớn trong một khoảng thời gian nhất định nào đó thì ta sẽ tiến hành block IP đó.

Do vậy chúng ta cần làm bước đầu tiên đó là tính xem con số maximum request của một trang web là bao nhiêu để có thể load thành công toàn bộ website đó về . Ta sẽ sử dụng Paros để đếm được số lượng request tối đã để load hoàn chỉnh một website nào đó

Giả sử muốn load thành công trang chủ http://www.bkav.com.vn/ ta cần khoảng 35 lần gửi request lên server thời gian load còn phải tùy thuộc vào tốc độ mạng nhưng trong một giây một địa chỉ IP không thể gửi quá 35 request tới server để load http://www.bkav.com.vn/,Do đó ta chỉ cần lọc xem từ một địa chỉ IP cụ thể nếu số request trong một giây mà vượt quá 35 lần thì ta tiến hành Drop toàn bộ request tới từ IP này

Sau đây là rules:

SecAction initcol:ip=%{REMOTE_ADDR},nolog 

SecRule REQUEST_LINE "^GET (?:/|.+\.html|.+\.php|.+\.cgi|.+\.pl) HTTP" " nolog,setvar:ip.ddos=+1,deprecatevar:ip.ddos=100/10"

SecRule IP:DDOS "@gt 35" "phase:1,id:'981052',t:none,log,drop,msg:'Client Connection Dropped due to high # of slow DoS alerts'"

Ta cũng có thể kiêm tra xem số lần mà trạng thái Server trả về là 408(HTTP Error 408 Request timeout) nếu con số này vượt quá một số nào đó giả sử là 5 lần trong một giây thì ta cũng tiến hàng Drop toàn bộ request

SecRule RESPONSE_STATUS "@streq 408" "phase:5,id:'981051',t:none,nolog,pass,setvar:ip.slow_dos_counter=+1,expirevar:ip.slow_dos_counter=60"

SecRule IP:SLOW_DOS_COUNTER "@gt 5" "phase:1,id:'981052',t:none,log,drop,msg:'Client Connection Dropped due to high # of slow DoS alerts'"

Đến đây mình xin được kết thúc bài viết. Cảm ơn các bạn đã theo dõi mọi thắc mắc các bạn có thể liên lạc qua yahoo của mình sevenup111_pu để trao đổi thêm nhé

 

Re: Hướng dẫn cài đặt mod_security cho Server Apache

Thấy bạn viết bài này rất có ích. Tiện đây mình muốn hỏi hiện tại bên mình có một website. Mình bảo vệ website sử dung Nginx với Modsecurity. Mình có một vấn đề là hiện tại mình chưa add một rule nào của Mod_security nhưng website của mình bị lỗi font chữ. Refresh lại thì lại được. Không biết bạn có kinh nghiệm về vấn đề này không. Bạn chỉ giáo giúp mình với.
Trân trọng cám ơn