<style>body {text-align: justify}</style>
# 1. Xây dựng tiêu chuẩn ATTT cho Hệ thống.
*Hardening "Làm cứng"* hệ thống là 1 thuật ngữ, cũng là 1 công việc căn bản nhất mà System Admin cần phải làm ngay sau khi đã cài xong 1 thành phần nào đó. Thành phần đó có thể là Hệ điều hành, dịch vụ máy chủ. Hệ điều hành thì thường là Linux Server, Window Server; dịch vụ máy chủ thì có thể là Apache, NginX.
Đây là 1 giai đoạn công việc trong chuỗi các công việc nhằm mục đích bảo vệ hệ thống. Nếu làm tốt giai đoạn này, tỷ lệ hệ thống của bạn gặp sự cố (cả từ bên ngoài hay bên trong gây ra) sẽ được giảm thiểu xuống mức rất thấp. Các dịch vụ/ứng dụng nội bộ hoạt động ko xung đột; tin tặc bên ngoài cũng ko dễ dàng tìm thấy "attack surface" (tạm dịch là "bề mặt tấn công") để mà khai thác. Trong trường hợp có sự cố xảy ra, bạn sẽ nhanh chóng tìm ra nguyên nhân và cách ngăn chặn/khắc phục tạm thời; từ đó chuyên tâm cho việc khắc phục hoàn toàn sự cố và khôi phục hệ thống trở lại bình thường.
## 1.1. Tìm hiểu các chuẩn trên thế giới về Cấu hình ATTT cho OS.
IT security standards là các tiêu chuẩn và hướng dẫn được thiết lập và công nhận rộng rãi trong lĩnh vực an ninh thông tin để hỗ trợ việc bảo mật hệ thống, mạng, dữ liệu và các tài nguyên thông tin trong một tổ chức hoặc môi trường công nghệ thông tin.
Các tiêu chuẩn này được phát triển bởi các tổ chức, cơ quan, hoặc các nhóm chuyên gia với mục tiêu đảm bảo tính bảo mật và an toàn của hệ thống thông tin. Các tiêu chuẩn IT security bao gồm một loạt các quy định, nguyên tắc, và phương pháp bảo mật cụ thể để giúp tổ chức bảo vệ chống lại các mối đe dọa và rủi ro an ninh thông tin.
Một số ví dụ về các tiêu chuẩn an ninh thông tin phổ biến bao gồm:
ISO/IEC 27001: Là tiêu chuẩn quốc tế về an ninh thông tin, quy định các yêu cầu để thành lập, triển khai, duy trì và cải tiến hệ thống quản lý an ninh thông tin trong một tổ chức.
NIST SP 800-53: Là tiêu chuẩn bảo mật thông tin do Cơ quan Tiêu chuẩn và Công nghệ Quốc gia (NIST) của Hoa Kỳ phát triển, đưa ra các hướng dẫn bảo mật cho các hệ thống và cơ sở dữ liệu liên quan đến Chính phủ Hoa Kỳ.
PCI DSS (Payment Card Industry Data Security Standard): Là tiêu chuẩn bảo mật thông tin đối với các doanh nghiệp chấp nhận, xử lý hoặc lưu trữ thông tin thẻ thanh toán.
HIPAA (Health Insurance Portability and Accountability Act): Là tiêu chuẩn an ninh thông tin trong lĩnh vực y tế tại Hoa Kỳ, đảm bảo bảo mật và bảo vệ thông tin cá nhân của bệnh nhân.
CIS Controls: Là một tập hợp các hướng dẫn bảo mật do CIS (Center for Internet Security) đưa ra để hỗ trợ tổ chức trong việc bảo vệ hệ thống và dữ liệu của họ khỏi các mối đe dọa thông tin.
CIS Benchmarks: Là một tập hợp các tiêu chuẩn bảo mật do Trung tâm Bảo mật Internet (Center for Internet Security - CIS) phát triển. CIS Benchmark định nghĩa các hướng dẫn chi tiết và các quy định bảo mật cụ thể cho các hệ điều hành, ứng dụng và các sản phẩm phần mềm khác.
## 1.2. Đề xuất 1 tiêu chuẩn Hardening cho OS Linux (Ubuntu 20.04) phù hợp với tổ chức khoảng 50.000 máy chủ (lựa chọn 10 tiêu chí quan trọng nhất). Từ đó cấu hình Hardenning cho 1 máy chủ Linux Ubuntu 20.04 dựa trên tiêu chuẩn đề xuất.
Trong phần này, CIS Benchmarks được sử dụng làm tiêu chuẩn Hardening cho Ubuntu 20.04 LTS. Có thể download tiêu chuẩn trên tại https://downloads.cisecurity.org/#/. Trong đó, 10 tiêu chí quan trọng nhất được liệt kê như sau:
### 1. Kiểm tra các bảng cập nhật, vá lỗi và các phần mềm bảo mật.
Điều này hầu như không nằm trong bất kỳ hướng dẫn bảo mật chính quy nào. Nhưng theo mình cách bảo mật tốt nhất cho hệ thống Linux là chăm chỉ update nó thường xuyên. Các bản update sẽ bổ sung các chức năng mới, cập nhập các bản vá tự động , nâng cao hiệu suất sử dụng và luôn mang lại cảm giác dễ chịu lớn.
**Hardening:**
```
sudo apt-get update
```
### 2. Cấu hình Filesystem
Có hai công việc chính trong phần này:
- Vô hiệu hóa các filesystems không sử dụng
- Cấu hình `/tmp`, `/var`, `/var/tmp`, `/var/log`, `/var/log/audit`, `/home`, `/dev/shm`
#### **2.1. Vô hiệu hóa các filesystems không sử dụng**
Có một số loại filesystem không phổ biến được hỗ trợ trong Linux. Nếu một loại filesystem không cần thiết, nó nên được vô hiệu hóa. Việc vô hiệu hóa này sẽ giúp giảm "attack surface" cho hệ thống. Một số filesystems cần được vô hiệu hóa như: `cramfs, freevxfs, iffs2, hfs, hfsplus, squashsf, udf, FAT`.
Ví dụ sử dụng script sau để vô hiệu hóa cramfs filesystem (Nguồn: Page 26 - CIS Benchmarks):
```bash
#!/usr/bin/env bash
{
l_mname = "cramfs"
#set module name
l_mtype = "fs"
#set module type
l_mpath = "/lib/modules/**/kernel/$l_mtype"
l_mpname = "$(tr '-' '_' <<< " $l_mname ")"
l_mndir = "$(tr '-' '/' <<< " $l_mname ")" module_loadable_fix ()
{
#If the module is currently loadable, add "install {MODULE_NAME} /bin/false" to a file in
"/etc/modprobe.d"
l_loadable = "$(modprobe -n -v " $l_mname ")"
["$(wc -l <<< " $l_loadable ")" - gt "1"] && l_loadable = "$(grep -P --
" (^\h * install | \b$l_mname) \ b " <<< " $l_loadable ")" if !grep
-Pq-- '^\h*install \/bin\/(true|false)' <<< "$l_loadable";
then
echo - e "\n - setting module: \"$l_mname\" to be not loadable"
echo -
e "install $l_mname /bin/false" >> /etc / modprobe.d /
"$l_mpname".conf fi}
module_loaded_fix ()
{
#If the module is currently loaded, unload the module
if lsmod
|grep "$l_mname" > /dev / null 2 > &1;
then
echo - e "\n - unloading module \"$l_mname\""
modprobe - r "$l_mname" fi}
module_deny_fix ()
{
#If the module isn't deny listed, denylist the module
if !modprobe
--showconfig | grep - Pq-- "^\h*blacklist\h+$l_mpname\b";
then
echo - e "\n - deny listing \"$l_mname\""
echo - e "blacklist $l_mname" >> /etc / modprobe.d / "$l_mpname".conf
fi}
#Check if the module exists on the system
for l_mdir
in $l_mpath;
do
if[-d "$l_mdir/$l_mndir"]
&&[-n "$(ls -A $l_mdir/$l_mndir)"];
then
echo -
e
"\n - module: \"$l_mname\" exists in \"$l_mdir\"\n - checking if disabled..."
module_deny_fix if["$l_mdir" =
"/lib/modules/$(uname -r)/kernel/$l_mtype"];
then module_loadable_fix module_loaded_fix fi
else
echo - e "\n - module: \"$l_mname\" doesn't exist in \"$l_mdir\"\n"
fi done echo - e "\n - remediation of module: \"$l_mname\" complete\n"
}
```
*Note:* Xem các filesystem có sẵn trong hệ thống bằng lệnh:
```
ls /usr/lib/modules/$(uname -r)/kernel/fs
```
#### **2.2. Cấu hình `/tmp`**
`/tmp` thư mục lưu trữ tạm thời của người sử dụng. Do đặc thù cho phép bất kỳ người dùng nào có thể tạo file. Vì vậy đây là thư mục Hacker luôn nhắm tới trong quá trình tấn công hệ thống - leo thang đặc quyền.
- Tạo phân vùng riêng cho `/tmp`
- Đối với hệ thống cài đặt mới, thiết lập một phân vùng dành riêng cho `/tmp`
- Đối với hệ thống đang chạy, sử dụng Logical Volume Manager (LVM) để tạo phân vùng `/tmp`
- Set `nodev`, `noexec`, `nosuid` option cho phân vùng `/tmp`:
- Tùy chọn `nodev` quy định rằng hệ thống tệp tin không thể chứa các thiết bị cụ thể.
- Tùy chọn `noexec` quy định rằng hệ thống tệp tin không thể chứa các file thực thi.
- Tùy chọn `nosuid` quy định rằng hệ thống tệp tin không thể chứa các file chứa suid.
**Hardening:**
```
grep /tmp /etc/fstab | grep "nodev\|noexec\|nosuid"
mount | grep /tmp | grep "nodev\|noexec\|nosuid"
```
Nếu các lệnh trên không cho ra kết quả thì hệ thống chưa cấu hình nội dung này.
- Sửa file `/etc/fstab` và thêm `nosuid,nodev,noexec` vào dòng thứ 4 (mounting options) có dạng như sau:
```
<device> /tmp <fstype> defaults,rw,nosuid,nodev,noexec,relatime 0 0
```
- Sau đó thực hiện lệnh:
```
mount -o remount /tmp
```
### 3. Cấu hình Secure Boot
#### **3.1. Đảm bảo bootloader password đã thiết lập**
Thiết lập này bắt buộc mọi người dùng muốn khởi động lại hệ thống phải nhập mật khẩu trước khi thực hiện lệnh khởi động lại.
**Audit:**
```
grep "^set superusers" /boot/grub/grub.cfg
set superusers="<user-list>"
grep "^password" /boot/grub/grub.cfg
password_pbkdf2 <user> <encrypted password>
```
**Hardening:**
Tạo mật khẩu với mã hóa md5
```
grub-mkpasswd-pbkdf2
Enter password: <password>
Reenter password: <password>
Your PBKDF2 is <encrypted-password>
```
Thêm dòng sau vào /etc/grub.d/00_header
```
cat <<EOF
set superusers="<user-list>"
password_pbkdf2 <user> <encrypted-password>
EOF
```
Thực hiện cập nhật grub
```
update-grub
```
#### **3.2. Đảm bảo phân quyền ở cấu hình bootloader**
Thiết lập chỉ cho phép root cấu hình bootloader. Kiểm tra quyền của tệp tin `grub.cfg`.
```
stat -L -c "%a" /boot/grub/grub.cfg | egrep ".00"
```
**Hardening:**
```
chmod og-rwx /boot/grub/grub.cfg
```
#### **3.3. Yêu cầu Authentication cho Single-User Mode**
Thiết lập mật khẩu cho tài khoản root, sẽ bắt buộc phải xác thực trong chế độ single user mode.
Thực hiện lệnh:
```
grep ^root:[*\!]: /etc/shadow
```
Nếu không có kết quả trả về thì tài khoản root đã được đặt mật khẩu.
**Hardening:**
```
passwd root
```
### 4. Dịch vụ (Services)
Tắt các services không cần thiết trong quá trình vận hành hệ thống bình thường. Điều này giúp làm giảm attack sufface vì service không thể bị khai thác khi nó bị disabled.
#### **4.1. Cấu hình đồng bộ thời gian (Time Synchronization)**
Nên cấu hình các hệ thống vật lý và máy ảo không có truy cập trực tiếp vào đồng hồ của máy chủ vật lý để đồng bộ thời gian của chúng bằng cách sử dụng một dịch vụ như systemd-timesyncd, chrony hoặc ntp.
**Hardening:** Đảm bảo dịch vụ `ntp` đang chạy
```
systemctl unmask ntp.service
systemctl --now enable ntp.service
```
#### **4.2. Special purpose services**
#### **4.3. Cấu hình các service clients**
### 5. Cấu hình mạng
#### **5.1. Vô hiệu hóa các giao thức và thiết bị mạng không sử dụng**
- Vô hiệu hóa wireless interface nếu máy chủ/thiết bị không sử dụng mạng wireless.
- Vô hiệu hóa bluetooth
- Vô hiệu hóa giao thức Datagram Congestion Control Protocol (DCCP) nếu không có tác vụ streaming media và telephony.
- v.v
#### **5.2. Cấu hình Firewall**
Cấu hình ufw, nftables, iptables phù hợp để kiểm soát, giám sát các lưu lượng mạng.
**Hardening:** Đảm bảo ufw đã được cài đặt và chạy
```
sudo apt install ufw
systemctl --now enable ufw.service
```
#### **5.3. Modify Network Parameters (Host Only)**
**Disable IP Forwarding**
Flag `net.ipv4.ip_forward` được sử dụng để báo cho máy chủ có thể chuyển tiếp gói tin hay không. Nếu máy chủ không dùng để định tuyến thì nên thiết lập giá trị cờ này là 0.
Kiểm tra giá trị của flag `net.ipv4.ip_forward`:
```
/sbin/sysctl net.ipv4.ip_forward
net.ipv4.ip_forward = 0
```
**Hardening:**
Thiết lập thông số cờ `net.ipv4.ip_forward` trong `/etc/sysctl.conf`
```
net.ipv4.ip_forward=0
```
Sửa đổi thông số cho phù hợp với Kernel:
```
/sbin/sysctl -w net.ipv4.ip_forward=0
/sbin/sysctl -w net.ipv4.route.flush=1
```
### 6. Modify Network Parameters (Host and Router)
#### **6.1. Vô hiệu hóa IPv6**
IPv6 có nhiều ưu điểm so với IPv4. Nếu IPv6 chưa được sử dụng tại tổ chức, tắt chúng đi để giảm thiểu việc bị tấn công vào bề mặt hệ thống.
Kiểm tra IPv6 có được bật
```
ip addr | grep inet6
```
Nếu không có kết quả trả về, ipv6 đã tắt.
**Hardening:** Để tắt IPv6, sửa tệp tin `/etc/sysclt.conf`
```
net.ipv6.conf.all.disable_ipv6=1
net.ipv6.conf.default.disable_ipv6=1
net.ipv6.conf.lo.disable_ipv6=1
```
Chạy lệnh sau để áp dụng thay đổi:
```
sysctl -p
```
#### **6.2. Enable Ignore Broadcast Requests**
Việc chấp nhận ICMP echo và yêu cầu timestamp với đích đến là broadcast hoặc multicast cho mạng của bạn có thể sử dụng để đánh lừa máy chủ tham gia một cuộc tấn công Smurf.
Với cuộc tấn công Smurf, kẻ tấn công sẽ gửi một lượng lớn gói tin ICMP tới địa chỉ nguồn giả mạo, các host nhận được, sẽ gửi lại echo-reply cho địa chỉ giả mạo, làm lưu lượng mạng tăng lên dẫn tới nghẽn hệ thống.
Kiểm tra giá trị flags:
```
/sbin/sysctl net.ipv4.icmp_echo_ignore_broadcasts
net.ipv4.icmp_echo_ignore_broadcasts = 1
```
Nếu kết quả trả về bằng 1 thì flag đã được bật.
**Hardening:** Nếu flag khác 1, sửa đổi thông số trong tệp tin sau `/etc/syscrl.conf`
```
net.ipv4.icmp_echo_ignore_broadcasts=1
```
Sửa đổi thông số phù hợp với Kernel:
```
/sbin/sysctl -w net.ipv4.icmp_echo_ignore_broadcasts=1
/sbin/sysctl -w net.ipv4.route.flush=1
```
### 7. Access, Authentication and Authorization
#### **7.1. Cấu hình chế độ lập lịch**
**Hardening:** Đảm bảo dịch vụ `cron` đang được chạy
```
systemctl unmask cron
systemctl --now enable cron
```
v.v.
#### **7.2. Cấu hình privilege escalation**
**Hardening:**
- Đảm bảo `sudo` đã được cài đặt
```
apt install sudo
```
- Đảm bảo yêu cầu password khi leo quyền
Kiểm tra cấu hình của các tệp `/etc/sudoers` và `/etc/sudoers.d/*` bằng lệnh sau đây:
```
grep -r "^[^#].*NOPASSWD" /etc/sudoers*
```
Nếu dòng nào có `NOPASSWD` thì xóa nó đi.
#### **7.3. Cấu hình PAM**
**Hardening:** Đảm bảo strong password requirement, ví dụ đảm bảo độ dài tối thiểu của password là 14. Cài đặt `pam_pwquality` module, và sửa file `/etc/security/pwquality.conf`
```
minlen = 14
```
### 8. Configure SSH
#### **8.1. Set Permissions on /etc/ssh/sshd_config**
Tệp tin `/etc/ssh/sshd_config` chứa cấu hình cho sshd. Tệp này cần được bảo vệ khỏi người dùng không có đặc quyền, nhưng cần cho phép đọc vì nó được sử dụng với nhiều chương trình không có đặc quyền.
Thực hiện lệnh sau để xác định người sử dụng và chủ sở hữu tệp tin `sshd_config`
```
/bin/ls -l /etc/ssh/sshd_config
-rw------- 1 root root 762 Sep 23 002 /etc/ssh/sshd_config
```
**Hardening:** Nếu người sử dụng và chủ sở hữu không phải root, thực hiện lệnh sau:
```
chown root:root /etc/ssh/sshd_config
```
Thiết lập lại quyền:
```
chmod 600 /etc/ssh/sshd_config
```
#### **8.2. Set SSH MaxAuthTries to 4 or Less**
Tham số `MaxAuthTries` xác định số lần được phép xác thực không thành công cho một kết nối. Đặt tham số `MaxAuthTries` thấp để giảm thiểu tấn công brute-force vào máy chủ SSH. Khuyến nghị cho tham số `MaxAuthTries` là 4.
Kiểm tra tham số:
```
grep "^MaxAuthTries" /etc/ssh/sshd_config
```
**Hardening:**
Sửa tệp tin `/etc/ssh/sshd_config` và thiết lập tham số: `MaxAuthTries 4`
v.v.
### 9. Logging and Auditing
#### **9.1. Cấu hình Logging**
Tổng hợp logs phục vụ quá trình giám sát, phát hiện, phân tích event.
**Hardening:** Ví dụ như đảm bảo dịch vụ journald được cài đặt để thu thập log events
```
apt install systemd-journal-remote
```
#### **9.2. Cấu hình Auditing**
Việc ghi lại các sự kiện hệ thống cung cấp cho các quản trị viên hệ thống thông tin để giúp họ xác định xem có xảy ra truy cập trái phép vào hệ thống của họ hay không.
**Hardening:** Ví dụ như đảm bảo dịch vụ auditd được cài đặt để thu thập log events
```
apt install auditd
```
### 10. Bảo trì hệ thống
Kiểm tra các cấu hình về phân quyền các file hệ thống, local user và group.
- Đảm bảo quyền hạn ở các file `/etc/passwd`, `etc/shadow`, `/etc/opasswd`, `/etc/group`.
- Đảm bảo không lặp lại các UIDs, GID, user name, group name, ...
# 2. Tìm hiểu Web Application Firewall
## 2.1. Tìm hiểu ít nhất 3 trong số các giải pháp WAF phổ biến trên thế giới: cloudflare, naxsi, modsecurity, citrix, imperva, bitninja, big ip f5,....
### 2.1.1 Cloudflare
Giải pháp WAF của Cloudflare là một dịch vụ bảo mật ứng dụng web cloud-based được cung cấp bởi Cloudflare, một công ty cung cấp dịch vụ CDN (Content Delivery Network), DDoS protection và bảo mật ứng dụng web. WAF của Cloudflare được thiết kế để bảo vệ các ứng dụng web khỏi các cuộc tấn công và lỗ hổng bảo mật thông qua việc giám sát và lọc lưu lượng truy cập đến ứng dụng.
Một số đặc điểm và ưu điểm của giải pháp WAF của Cloudflare:
- *Dễ dàng triển khai và cấu hình*: Cloudflare cung cấp giao diện quản lý dễ sử dụng cho việc triển khai và cấu hình WAF cho các ứng dụng web.
- *Hỗ trợ CDN và DDoS protection*: Cloudflare cung cấp dịch vụ CDN để tối ưu hóa tải trang và giảm thời gian phản hồi, cũng như cung cấp bảo vệ DDoS để chống lại các cuộc tấn công từ chối dịch vụ.
- *Giám sát và báo cáo chi tiết*: Cloudflare cung cấp các công cụ giám sát và báo cáo chi tiết về hoạt động của WAF, giúp người quản trị theo dõi và phản ứng kịp thời đối với các cuộc tấn công.
- *Bảo mật cho ứng dụng web*: WAF của Cloudflare giám sát và chặn các cuộc tấn công như SQL injection, cross-site scripting (XSS), và các lỗ hổng bảo mật khác trước khi chúng có thể tác động đến ứng dụng.
- *Khả năng chống giả mạo thông tin*: WAF của Cloudflare cung cấp khả năng chống giả mạo thông tin nhằm bảo vệ ứng dụng web khỏi các cuộc tấn công giả mạo thông tin và ăn cắp thông tin người dùng.
- *Quản lý chính sách an toàn dễ dàng*: Cloudflare cho phép người quản trị tùy chỉnh chính sách bảo mật và quản lý các luật để đáp ứng các yêu cầu cụ thể của ứng dụng.
- *Hỗ trợ cộng đồng và tài liệu phong phú*: Cloudflare có một cộng đồng sử dụng rộng lớn và cung cấp tài liệu hướng dẫn chi tiết giúp người dùng sử dụng hiệu quả WAF.
Tuy nhiên, cần lưu ý rằng WAF của Cloudflare vẫn có một số hạn chế, như phụ thuộc vào dịch vụ của Cloudflare và có thể gặp giới hạn trong việc hỗ trợ phức tạp và giải đoạn. Ngoài ra, việc sử dụng WAF cần xem xét kỹ lưỡng và hiểu rõ yêu cầu của ứng dụng để đảm bảo tính hiệu quả và an toàn của giải pháp.
Về cách triển khai sử dụng WAF Cloudflare cho Wordpress, có thể tham khảo bài blog sau: https://gridpane.com/blog/cloudflare-firewall-rules-for-securing-wordpress-websites/
### 2.1.2 Citrix
Citrix Web Application Firewall (WAF) là một giải pháp bảo mật ứng dụng web được cung cấp bởi Citrix Systems, một công ty chuyên cung cấp các giải pháp ảo hóa, điều khiển từ xa và đám mây. Giải pháp WAF của Citrix được thiết kế để bảo vệ các ứng dụng web khỏi các cuộc tấn công và lỗ hổng bảo mật thông qua việc kiểm soát và lọc lưu lượng truy cập đến ứng dụng.
Một số đặc điểm và ưu điểm của giải pháp WAF Citrix:
- *Bảo vệ ứng dụng web đa tầng*: WAF Citrix cung cấp bảo vệ đa tầng cho các ứng dụng web, từ lớp ứng dụng đến lớp mạng, giúp ngăn chặn các cuộc tấn công từ nhiều góc độ.
- *Phát hiện và ngăn chặn các cuộc tấn công phổ biến*: WAF Citrix hỗ trợ phát hiện và ngăn chặn các cuộc tấn công phổ biến như SQL injection, cross-site scripting (XSS), cross-site request forgery (CSRF), và các cuộc tấn công khác.
- *Giám sát và báo cáo chi tiết*: Citrix cung cấp các công cụ giám sát và báo cáo chi tiết về hoạt động của WAF, giúp người quản trị theo dõi và phản ứng kịp thời đối với các cuộc tấn công.
- *Hỗ trợ cụ thể cho ứng dụng và ứng dụng di động*: WAF Citrix có khả năng hỗ trợ và bảo vệ các ứng dụng web và ứng dụng di động trên nhiều nền tảng.
- *Tích hợp với Citrix ADC*: Giải pháp WAF của Citrix có thể tích hợp chặt chẽ với Citrix ADC (Application Delivery Controller), giúp tối ưu hóa và bảo mật ứng dụng web trên nền tảng đám mây và truyền thống.
- *Bảo mật và hiệu suất*: WAF Citrix cung cấp cân bằng giữa bảo mật và hiệu suất, giúp đảm bảo rằng ứng dụng web vẫn hoạt động một cách hiệu quả trong khi đảm bảo an toàn.
### 2.1.3 Modsecurity
ModSecurity là một giải pháp Web Application Firewall (WAF) mã nguồn mở và được phát triển bởi Open Web Application Security Project (OWASP). ModSecurity được tích hợp trực tiếp vào máy chủ web như Apache, Nginx hoặc IIS và hoạt động như một module trung gian để giám sát, phát hiện và ngăn chặn các cuộc tấn công vào các ứng dụng web.
Một số đặc điểm và ưu điểm của giải pháp WAF ModSecurity:
- *Kiểm soát và lọc lưu lượng web*: ModSecurity kiểm soát và lọc lưu lượng truy cập đến ứng dụng web bằng cách quét các yêu cầu (request) và phản hồi (response) từ và đến máy chủ web.
- *Hỗ trợ các quy tắc bảo mật*: ModSecurity được cung cấp với một tập hợp các quy tắc bảo mật được phát triển bởi cộng đồng và có thể tùy chỉnh để phù hợp với nhu cầu cụ thể của ứng dụng web.
- *Phát hiện và ngăn chặn các cuộc tấn công phổ biến*: ModSecurity hỗ trợ phát hiện và ngăn chặn các cuộc tấn công phổ biến như SQL injection, cross-site scripting (XSS), remote file inclusion (RFI), và các cuộc tấn công khác.
- *Báo cáo chi tiết*: ModSecurity cung cấp các báo cáo chi tiết về hoạt động của WAF, giúp người quản trị có cái nhìn tổng quan về các cuộc tấn công và khả năng ảnh hưởng lên hệ thống.
- *Tích hợp với hệ thống quản lý sự cố*: ModSecurity có thể tích hợp với các hệ thống quản lý sự cố (SIEM) để đưa ra phản ứng kịp thời đối với các cuộc tấn công.
- *Khả năng tùy chỉnh cao*: ModSecurity cho phép người quản trị tùy chỉnh các quy tắc bảo mật và thiết lập cấu hình để phù hợp với nhu cầu cụ thể của ứng dụng web.
## 2.2. Đưa ra so sánh, đánh giá về các giải pháp WAF tìm hiểu(1.5d). Ưu và nhược điểm của các giải pháp WAF. Tại sao các giải pháp WAF không được sử dụng phổ biến.
| **Giải pháp WAF** | **Ưu điểm** | **Nhược điểm** |
|:-----------------:|:--------------------------------------------:|:--------------------------------------------------:|
| **Cloudflare** | - Dễ dàng triển khai và cấu hình | - Phụ thuộc vào dịch vụ của Cloudflare |
| | - Hỗ trợ CDN và DDoS protection | - Giai đoạn hoặc giới hạn hỗ trợ phức tạp |
| | - Giám sát và báo cáo chi tiết | - Phí cao với các tính năng nâng cao |
| | - Bảo mật cho ứng dụng web | |
| | - Khả năng chống giả mạo thông tin | |
| | - Quản lý chính sách an toàn dễ dàng | |
| | - Hỗ trợ cộng đồng và tài liệu phong phú | |
| **Citrix** | - Hiệu suất mạnh mẽ và ổn định | - Phức tạp trong việc cấu hình và triển khai |
| | - Hỗ trợ WAF truyền thống và cơ sở hạ tầng | |
| | - Cung cấp chế độ WAF ảo (VPX) | - Đòi hỏi cấu hình và quản lý chuyên nghiệp |
| | - Giám sát và báo cáo chi tiết | - Phí cao so với giải pháp khác |
| | - Hỗ trợ chính sách bảo mật phong phú | |
| | - Hỗ trợ chống giả mạo thông tin | |
| **ModSecurity** | - Miễn phí và mã nguồn mở | - Yêu cầu kiến thức về bảo mật |
| | - Độ linh hoạt cao với các tùy chọn cấu hình | |
| | - Được cộng đồng hỗ trợ và phát triển | - Đòi hỏi thời gian và công sức để cấu hình |
| | - Hỗ trợ chống giả mạo thông tin | - Cần thời gian để điều chỉnh cấu hình và vận hành |
## 2.3. Thực hành triển khai giải pháp modsecurity bảo vệ cho 1 web, framework có lỗi nghiêm trọng (tùy chọn). Thực hiện viết luật để chặn lỗi nghiêm trọng của website.
### 2.3.1. Reproduce *CVE-2023-28121*
#### Môi trường:
- Wordpress 6.2.2
- WooCommerce 7.6.0
- WooPayments 5.6.1
#### Tổng quan *CVE-2023-28121*
WooCommerce-Payments plugin có version `4.8 < 4.8.2`, `4.9 < 4.9.1`, `5.0 < 5.0.4`, `5.1 < 5.1.3`, `5.2 < 5.2.2`, `5.3 < 5.3.1`, `5.4 < 5.4.1`, `5.5 < 5.5.2`, và `5.6 < 5.6.2` chứa lỗ hổng bypass authentication bằng cách truyền một tham số user ID hợp lệ vào header `X-WCPAY-PLATFORM-CHECKOUT-USER` ở các request. Với lỗ hổng này, một người dùng ẩn danh hoàn toàn có thể sử dụng API để tạo user mới với quyền `administrator` ở trên trang Wordpress mục tiêu nếu như user ID hợp lệ được chọn là một tài khoản admin.
Đoạn code gây lỗi nằm ở hàm `determine_current_user_for_platform_checkout()` tại `includes/platform-checkout/class-platform-checkout-session.php`.
#### Reproduce
Thực hiện tạo một user mới có role `administrator` bằng *CVE-2023-28121*. Cấu trúc HTTP request có dạng như sau:
```
POST /index.php/wp-json/wp/v2/users HTTP/1.1
Host: 192.168.5.129
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:109.0) Gecko/20100101 Firefox/115.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,*/*;q=0.8
X-Wcpay-Platform-Checkout-User: 1
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Connection: close
Upgrade-Insecure-Requests: 1
Content-Type: application/json
Content-Length: 115
{
"username": "hacked",
"email": "hacked@vcs.com",
"password": "hacked",
"roles": ["administrator"]
}
```
Khi không có header `X-Wcpay-Platform-Checkout-User: 1`, thì server trả về `401 Unauthorized`.
Tuy nhiên, với header `X-Wcpay-Platform-Checkout-User: 1`, ta tạo thành công user.
Lí do chọn `X-Wcpay-Platform-Checkout-User: 1` là vì hiện tại ứng dụng chỉ có duy nhất một user quản trị là `admin` có `userID=1` → HTTP Request trên được WooCommerce Payments hiểu rằng `admin` đang thực hiện chức năng tạo người dùng mới `hacked` có role là `administrator`.
#### POC exploit
Thực thi mã khai thác tự động ([Link](https://github.com/gbrsh/*CVE-2023-28121*)).
### 2.3.2. Viết rule ModSecurity chặn *CVE-2023-28121*
#### 2.3.2.1. Cài đặt Modsecurity cho Apache2
Cài đặt và kích hoạt module cần thiết của modsecurity cho apache2.
```
sudo apt install libapache2-mod-security2
sudo a2enmod security2
sudo systemctl restart apache2
```
Thực hiện cấu hình cho modsecurity:
```
sudo cp /etc/modsecurity/modsecurity.conf-recommended /etc/modsecurity/modsecurity.conf
```
Sửa `/etc/modsecurity/modsecurity.conf`:
```
SecRuleEngine DetectionOnly --> SecRuleEngine On
```
Thực hiện cập nhật các core rule mới nhất của modsecurity cho modsecurity của mình.
```
cd
git clone https://github.com/coreruleset/coreruleset.git
cd coreruleset
sudo mv crs-setup.conf.example /etc/modsecurity/crs-setup.conf
sudo mv rules/ /etc/modsecurity/
```
Sau đó cần include đường dẫn chứa các file config rule ở file `/etc/apache2/mods-enabled/security2.conf`. Có thể hiểu rằng, các rule có thể đặt trong file `.conf` ở `/etc/modsecurity` hoặc `/etc/modsecurity/rules`.
Restart lại apache2 service.
```
sudo systemctl restart apache2
```
#### 2.3.2.1. Viết rule
*Source: https://coreruleset.org/docs/rules/creating/*
Cú pháp của một câu custom rule:
```
SecRule VARIABLES "OPERATOR" "TRANSFORMATIONS,ACTION"
```
Trong đó,
- Variables - Instructs ModSecurity where to look (sometimes called Targets)
```
Request Variables - ARGS, REQUEST_HEADERS, REQUEST_COOKIES
Response Variables - RESPONSE_HEADERS, RESPONSE_BODY
Server Variables - REMOTE_ADDR, AUTH_TYPE
Time Variables - TIME, TIME_EPOCH, TIME_HOUR
Collection Variables - TX, IP, SESSION, GEO
Miscellaneous Variables - HIGHEST_SEVERITY, MATCHED_VAR
```
- Operators - Instructs ModSecurity when to trigger a match
```
String Operators - rx, pm, beginsWith, contains, endsWith, streq, within
Numerical Operators - eq, ge, gt, le, lt
Validation Operators - validateByteRange, validateUrlEncoding, validateSchema
Miscellaneous Operators - rbl, geoLookup, inspectFile, verifyCC
```
- Transformations - Instructs ModSecurity how it should normalize variable data
```
Anti-Evasion Functions - lowercase, normalisePath, removeNulls, replaceComments, compressWhitespace
Decoding Functions - base64Decode, hexDecode, jsDecode, urlDecodeUni
Encoding Functions - base64Encode, hexEncode
Hashing Functions - sha1, md5
```
- Actions - Instructs ModSecurity what to do if a rule matches
```
Disruptive Actions - block, drop, deny, proxy
Flow Actions - chain, skip, skipAfter
Metadata Actions - phase, id, msg, severity, tag
Variable Actions - capture, setvar, initcol
Logging Actions - log, auditlog, nolog, sanitiseArg
Miscellaneous Actions - ctl, multiMatch, exec, pause, append/prepend
```
Để ngăn chặn *CVE-2023-28121*, ta chỉ việc chặn các request có chứa header `X-Wcpay-Platform-Checkout-User` với giá trị số bất kì. Câu rule như sau:
```
SecRule REQUEST_HEADERS:X-Wcpay-Platform-Checkout-User "@rx \d+" "id:12345,phase:1,t:none,t:lowercase,deny,status:403,msg:'Blocked request with X-Wcpay-Platform-Checkout-User header to prevent CVE-2023-28121'"
```
Khi đó, modsecurity sẽ tìm kiếm các request có header `X-Wcpay-Platform-Checkout-User` có giá trị match với regex `\d+` thì sẽ trả `403 Forbidden`.
Bây giờ ta sẽ có 2 cách để add rule trên vào apache2:
***Cách 1:***
Mở file config sau:
```
sudo nano /etc/apache2/sites-available/000-default.conf
```
Thêm 2 dòng vào như hình dưới:
```
SecRuleEngine On
SecRule REQUEST_HEADERS:X-Wcpay-Platform-Checkout-User "@rx \d+" "id:12345,phase:1,t:none,t:lowercase,deny,status:403,msg:'Blocked request with X-Wcpay-Platform-Checkout-User header to prevent CVE-2023-28121'"
```
***Cách 2:***
Tạo một file `.cnf` chứa các custom rules, ví dụ:
```
sudo nano /etc/modsecurity/modsecurity_custom_rules.conf
```
Sau đó add rule vừa tạo vào file này.
```
SecRule REQUEST_HEADERS:X-Wcpay-Platform-Checkout-User "@rx \d+" "id:12345,phase:1,t:none,t:lowercase,deny,status:403,msg:'Blocked request with X-Wcpay-Platform-Checkout-User header to prevent CVE-2023-28121'"
```
Sau khi thiết lập rule thành công, thực hiện restart lại apache2 service
```
sudo service apache2 restart
```
*Kết quả sau khi thêm rule*: *CVE-2023-28121* đã không còn hiệu quả khi bị chặn `403 Forbidden`.
Xem error log của apache2, có thể thấy rule đã được kích hoạt thành công.
## 2.4. Viết một số luật chặn cơ bản của WAF: chặn theo geo IP, chặn theo URL, chặn theo Parameter, chặn kết hợp nhiều yếu tố (chain).
- **Chặn theo URL**: chặn người dùng truy cập vào URI bắt đầu bằng `/index.php/wp-json/wp/v2/users`
```
SecRule REQUEST_URI "@beginsWith /index.php/wp-json/wp/v2/users" "id:12345,deny,status:403,msg:'Access to /index.php/wp-json/wp/v2/users is not allowed'"
```
Truy cập `/index.php/wp-json/wp/v2/users` bị chặn:
Truy cập `/index.php/wp-json/wp/v2/users/1` bị chặn:
- **Chặn theo Parameter**: chặn bất kì request nào có chứa GET param `bypass_waf=true`
```
SecRule ARGS_GET:bypass_waf "@streq true" "id:12346,phase:1,t:lowercase,deny,status:403,msg:'Param bypass_waf=true is not allowed'"
```
Trước khi thiết lập rule, vẫn truy cập bình thường:
Tuy nhiên sau khi thêm rule và param `bypass_waf=true` vào request thì đã bị chặn.
- **Chặn kết hợp nhiều yếu tố (chain)**: Thực hiện chặn IP `192.168.5.1` (chính là IP Client) truy cập vào `/index.php/wp-json/wp/v2/users` có chứa param `bypass_waf=true`.
```
SecRule REMOTE_ADDR "@streq 192.168.5.1" \
"chain, id:10000,phase:1,deny,nolog,msg:'Blocked IP'"
SecRule REQUEST_URI "@beginsWith /index.php/wp-json/wp/v2/users" \
"chain"
SecRule ARGS:bypass_waf "@streq true"
```
IP `192.168.5.1` truy cập `/index.php/wp-json/wp/v2/users` thành công:
Tuy nhiên khi có thêm param `bypass_waf=true` thì đã bị `403 Forbidden`.
- **Chặn theo geo IP**: chỉ cho phép IP từ Vietnam (VN) truy cập
```
SecRule REMOTE_ADDR "@geoLookup" "chain,id:12345,deny,status:403, \
msg:'Non-VN IP address: address is in %{GEO.COUNTRY_NAME} (%{GEO.COUNTRY_CODE}).'"
SecRule GEO:COUNTRY_CODE "!@streq VN"
```
## 2.5. Đưa ra phương án xử lý các false positive của người dùng (chặn nhầm) và thực hiện tối ưu luật cho các false positive (tunning luật).
### Tuning Away False Positives
*Source: https://coreruleset.org/docs/concepts/false_positives_tuning/*
#### Cách 1: Trực tiếp sửa các CRS (Core Rule Set) rules
Đây là cách vô cùng thủ công và mất thời gian khi thực hiện tìm nguyên nhân false positive và chỉnh sửa lại các CRS rules trên các file config. Việc chỉnh sửa này có thể tạo nên một nhánh (fork) mới cho tập rules, làm gia tăng lỗi trong quá trình config rule. Do đó đây là phương án không được khuyến khích sử dụng.
#### Cách 2: Rule Exclusions
ModSecurity cung cấp một số cơ chế loại trừ quy tắc (Rule Exclusion - RE) cho phép thay đổi rule mà không trực tiếp chỉnh sửa rule đó. Điều này giúp dễ dàng tích hợp với các third-party rule sets như Core Rule Set (CRS) khi cập nhật các rule mới mà vẫn giữ nguyên vẹn các file rule set.
Có 2 loại RE cơ bản:
- **Configure-time rule exclusions**:
- Các rule exclusions này có hiệu lực duy nhất 1 lần ở thời điểm cấu hình (configure-time), ví dụ khi restart hay reload ModSecurity, hoặc web server.
- Các rule exlusions phải được include **sau** các CRS trong file config. Lí do là vì Configure-time rule exclusions dùng để remove rule thì phải load xong các rule trước rồi mới xóa nó được.
- **Runtime rule exclusions**:
- Các rule exclusions này được áp dụng tại thời điểm chạy trên cơ sở mỗi transaction (ví dụ: các rule exclusions có thể được áp dụng có điều kiện cho một số transaction nhưng không áp dụng cho các transaction khác). Ví dụ: nếu một transaction là yêu cầu POST tới vị trí `signup.php`, loại bỏ rule X.
- Các rule exlusions phải được include **trước** các CRS trong file config.
Có 2 cách để exclude rules:
- **Exclude the entire rule/tag**: loại trừ toàn bộ rule hay loại rule (xác định bằng tag) khỏi rule engine.
- **Exclude a specific variable from the rule/tag**: loại bỏ một variable cụ thể khổi một rule hay một loại rule (xác định bằng tag).
Việc kết hợp 2 cách exclude rule này với 2 loại RE cơ bản ở trên giúp ta có thể linh hoạt viết được các RE khác nhau.
| | **Exclude entire rule/tag** | **Exclude specific variable from rule/tag** |
|:------------------:|------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|--------------------------------------------------|
| **Configure-time** | - `SecRuleRemoveById`: Xóa rule theo 1 rule ID, nhiều rule ID hay dải ID (Range). <br /> - `SecRuleRemoveByTag`: Xóa rule tags theo tên tag. <br /> |- `SecRuleUpdateTargetById`: xóa variable theo rule ID <br /> - `SecRuleUpdateTargetByTag`: xóa variable theo rule tag |
| **Runtime** | `ctl:ruleRemoveById`<br />`ctl:ruleRemoveByTag` | `ctl:ruleRemoveTargetById`<br />`ctl:ruleRemoveTargetByTag` |
**Các ví dụ**
- **Loại 1: Configure-time RE**
1. Xóa dải rule ID
```
SecRuleRemoveById "913000-913999"
```
2. Xóa CRS rules tagged `attack-sqli` bằng
```
SecRuleRemoveByTag attack-sqli
```
3. Xóa variable request cookies dạng “uid_” khỏi rule có ID 923440
```
SecRuleUpdateTargetById 923440 "!REQUEST_COOKIES:/^uid_.*/"
```
4. Xóa variable request cookies dạng “uid_” khỏi rule tag `attack-sqli`
```
SecRuleUpdateTargetByTag attack-sqli "!REQUEST_COOKIES:/^uid_.*/"
```
- **Loại 2: Runtime RE**
5. Xóa rule ID 920230 tạo false positive tại đường dẫn `/webapp/function.php`
```
SecRule REQUEST_URI "@beginsWith /webapp/function.php" \
"id:1000,\
phase:1,\
pass,\
nolog,\
ctl:ruleRemoveById=920230"
```
6. Xóa rule tag `attack-sqli` tạo false positive tại đường dẫn `/web_app_1/content`
```
SecRule REQUEST_URI "@beginsWith /web_app_1/content" \
"id:1010,\
phase:1,\
pass,\
nolog,\
ctl:ruleRemoveByTag=attack-sqli"
```
7. Xóa variable request argument "text_input" khỏi rule có ID `941150` khi truy cập `/dynamic/new_post`
```
SecRule REQUEST_URI "@beginsWith /dynamic/new_post" \
"id:1020,\
phase:1,\
pass,\
nolog,\
ctl:ruleRemoveTargetById=941150;ARGS:text_input"
```
8. Xóa variable request cookies dạng “uid_” khỏi rule tag `attack-sqli` khi truy cập `/webapp/login.html`
```
SecRule REQUEST_URI "@beginsWith /webapp/login.html" \
"id:1030,\
phase:1,\
pass,\
nolog,\
ctl:ruleRemoveTargetByTag=attack-sqli;REQUEST_COOKIES:uid"
```
Sign in with Wallet
Connect another wallet