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, redirect: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:'>alert("Hoc di dung hack nua!"); ',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
Đầ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
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, redirect: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:'>
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
Đầ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
