BAN CƠ YẾU CHÍNH PHỦ

HỌC VIỆN KỸ THUẬT MẬT MÃ

¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯

CHUYÊN ĐỀ AN TOÀN THÔNG TIN

NGHIÊN CỨU CÔNG NGHỆ WAF VÀ TRIỂN KHAI

BẢO VỆ HỆ THỐNG WEBSITE

Ngành: An toàn thông tin

Mã số: 7.48.02.02

Sinh viên thực hiện:

Võ Trà My – Lớp AT16E; Mã SV: AT160535

Người hướng dẫn:

TS. Phạm Duy Trung
Khoa An toàn thông tin – Học viện Kỹ thuật mật mã

Hà Nội, 2022

1
 BAN CƠ YẾU CHÍNH PHỦ
HỌC VIỆN KỸ THUẬT MẬT MÃ
¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯

CHUYÊN ĐỀ AN TOÀN HỆ THỐNG THÔNG TIN

NGHIÊN CỨU CÔNG NGHỆ WAF VÀ TRIỂN KHAI

BẢO VỆ HỆ THỐNG WEBSITE

Ngành: An toàn thông tin

Mã số: 7.48.02.02

Sinh viên thực hiện:

Võ Trà My
Lớp AT16E

Người hướng dẫn:

TS. Phạm Duy Trung
Khoa An toàn thông tin – Học viện Kỹ thuật mật mã

Hà Nội, 2022

2
 MỤC LỤC
Danh mục hình ảnh............................................................................................iii
Lời cảm ơn..........................................................................................................iv
Lời nói đầu...........................................................................................................v
Chương 1: Tổng quan về WAF..........................................................................1
1.1. Giới thiệu chung về WAF........................................................................1
1.1.1. Khái niệm WAF.................................................................................1
1.1.2. Phân loại WAF...................................................................................1
1.1.3. So sánh WAF với NetworkFirewall và IDS/IPS.............................3
1.1.4. Hoạt động của tường lửa ứng dụng web.........................................4
1.1.5. Lợi ích và tầm quan trọng của WAF...............................................5
1.2. Kiến trúc WAF.........................................................................................6
1.2.1. Vị trí đặt WAF...................................................................................6
1.2.2. Mô hình bảo mật................................................................................7
1.2.3. Mô hình hoạt động............................................................................7
1.3. Các phiên bản WAF mã nguồn mở phổ biến.........................................8
1.3.1. ModSecurity.......................................................................................8
1.3.2. WebKnight.........................................................................................8
1.3.3. Shadow Daemon................................................................................9
1.3.4. NAXSI.................................................................................................9
1.3.5. F5 Advance.........................................................................................9
1.4. Kết luận Chương 1.................................................................................10
Chương 2: Giới thiệu về ModSecurity WAF...................................................10
2.1. Tổng quan về ModSecurity...................................................................10
2.2. Chức năng của ModSecurity.................................................................11
2.3. Cấu trúc rule trong ModSecurity.........................................................12
2.3.1. VARIABLE......................................................................................13
2.3.2. OPERATOR....................................................................................14

i
 2.3.3. ACTIONS.........................................................................................15
2.4. Quá trình xử lý trong ModSecurity......................................................16
2.5. Kết luận Chương 2.................................................................................18
Chương 3: Triển khai WAF với ModSecurity.................................................19
3.1. Mô hình thực nghiệm.............................................................................19
3.2. Các bước thực hiện.................................................................................19
3.2.1. Cài đặt ModSecurity.......................................................................19
3.2.2. Cấu hình ModSecurity....................................................................20
3.2.3. Cài đặt DVWA:...............................................................................24
3.2.4. Triển khai ModSecurity trên DVWA............................................27
3.3. Kết luận chương 3..................................................................................31
Kết luận..............................................................................................................32
Tài liệu tham khảo:...........................................................................................33
Phụ lục................................................................................................................34

ii
 DANH MỤC HÌNH ẢNH

Hình 1.1: Định nghĩa WAF.......................................................................................

Hình 1.2: So sánh WAF và Firewall, IDS/IPS......................................................3
Hình 1.3: Mô hình của một hệ thống tường lửa ứng dụng Web (WAF)...................
Hình 1.4: Hoạt động của WAF..................................................................................
Hình 1.5: Vị trí đặt WAF.......................................................................................7
Hình 2.1: Operation(1)............................................................................................15
Hình 2.2: Operation (2)...........................................................................................15
Hình 2.3: Quy trình xử lí của ModSecurity.............................................................17
Hình 3.1: Mô hình thực nghiệm..............................................................................19
Hình 3.2: Cài đặt ModSecurity................................................................................20
Hình 3.3: nano /etc/ModSecurity/ModSecurity.conf..............................................21
Hình 3.4: nano /etc/apache2/mod-available/security2.conf....................................22
Hình 3.5: nano /etc/apache2/sites-enabled/000-default.conf...................................23
Hình 3.6: Clone DVWA Github..............................................................................24
Hình 3.7: Download DVWA thành công................................................................24
Hình 3.8: Cấu hình DVWA.....................................................................................25
Hình 3.9: http://127.0.0.1/DVWA/setup.php..........................................................26
Hình 3.10: http://127.0.0.1/DVWA/login.php.........................................................26
Hình 3.11: Giao diện DVWA khi đăng nhập thành công........................................27
Hình 3.12: Giao diện SQL injection ban đầu..........................................................27
Hình 3.13: Tấn công SQL thành công.....................................................................28
Hình 3.14: Trang web sau khi bật ModSecurity(SQL)...........................................28
Hình 3.15: Log ghi lại sau khi thực hiện tấn công SQL..........................................29
Hình 3.16: Giao diện trang thực hiện tấn công XSS...............................................29
Hình 3.17: Tấn công XSS thành công.....................................................................30
Hình 3.18: Trang web sau khi bật ModSecurity (XSS)...........................................30
Hình 3.19: Log ghi lại sau khi thực hiện tấn công XSS..........................................31

iii
 LỜI CẢM ƠN

Trước hết, em xin gửi lời cảm ơn chân thành nhất đến toàn bộ quý thầy cô
Học viện Kỹ thuật Mật mã, quý thầy cô khoa An toàn thông tin, chuyên ngành
An toàn hệ thống thông tin đã dạy dỗ, truyền đạt những kiến thức quý báu cho
em trong suốt bốn năm học tập và rèn luyện tại trường. Em xin gửi lời cảm ơn
sâu sắc đến giáo viên hướng dẫn - Thầy Phạm Duy Trung, người đã nhiệt tình
hướng dẫn em thực hiện đề tài chuyên ngành An toàn hệ thống thông tin này.
Do thời gian và trình độ còn hạn chế, bài báo cáo không thể tránh khỏi
những thiếu sót. Kính mong các thầy cô chỉ bảo và đóng góp ý kiến để bài báo
cáo của em được hoàn thiện hơn. Em xin chân thành cảm ơn!

SINH VIÊN THỰC HIỆN

Võ Trà My

iv
 LỜI NÓI ĐẦU

Trong những năm gần đây, xu hướng tấn công vào ứng dụng web đang
ngày càng trở nên phổ biến. Các kỹ thuật tấn công được sử dụng chủ yếu là
cross-site scripting, SQL injection, và nhiều kỹ thuật khác… tất cả các kỹ thuật
này đều nhằm vào tầng ứng dụng trong mô hình OSI. Các lỗ hổng trong ứng
dụng web chủ yếu xảy ra do người lập trình không kiểm tra kỹ các tham số hay
ký tự do người dùng nhập vào để tương tác với ứng dụng web. Để khắc phục các
lỗi trên ứng dụng web, người lập trình cần hiểu và viết được các đoạn mã ở mức
độ bảo mật nhất, tuy nhiên việc viết mã sao cho “bảo mật” nhất thường khó thực
hiện, bởi các lẽ sau: Thức nhất, các đơn vị lập trình thường không có hoặc thiếu
đội ngữ chuyên trách về việc kiểm tra và sửa lỗi bảo mật mã nguồn ứng dụng.
Thức hai, đôi khi áp lực phải hoàn thành ứng dụng web trong thời gian nhanh
khiến cho các ứng dựng ểb được đưa vào vận hành mà không qua các khâu kiểm
thử.Thức ba, việc dùng các công cụ kiểm tra lỗi web tự động đôi khi cũng không
tìm ra hết các lỗi khi được thực hiện bằng tay. Do vậy, việc bảo mật một ứng
dụng web đó là một quá trình phòng thử theo chiều sâu bao gồm các khâu phát
triển, vận hành, xây dựng cơ sở hạ tầng bảo vệ tốt và có một đội ngũ chuyên
trách vấn đề bảo mật riêng cho web.
Tường lửa ứng dụng web (Web Application Firewall – WAF) là một giải
pháp nhằm bảo vệ cho ứng dụng web tránh khỏi các lỗi bảo mật nói trên.
Đề tài được thực hiện nhằm mục đích tìm hiểu về nghiên cứu công nghệ
WAF và triển khai bảo vệ hệ thống website với WAF mã nguồn mở cụ thể là
ModSecurity. Mục tiêu đặt ra khi thực hiện đồ án là:
1. Hệ thống kiến thức về hệ mật WAF;
2. Nghiên cứu về ModSecurity ứng dụng WAF để triển khai bảo vệ web-
site;
3. Triển khai cài đặt ModSecurity trên Apache Kali Linux và kịch bản tấn
công SQL injection, tấn công XSS trên DVWA.

v
Sau thời gian thực hiện đề tài, các mục tiêu về cơ bản đã đạt được. Tuy nhiên
bảo mật website khỏi các tấn công là một lĩnh vực rất phức tạp, thời gian thực
hiện nghiên cứu chuyên đề tương đối ngắn nên chắc chắn không tránh khỏi thiếu
sót. Rất mong được sự góp ý của các thầy cô, cũng như các bạn sinh viên để đề
tài này được hoàn thiện hơn.
SINH VIÊN THỰC HIỆN

Võ Trà My

vi
 CHƯƠNG 1: TỔNG QUAN VỀ WAF

1.1. Giới thiệu chung về WAF

1.1.1. Khái niệm WAF

WAF là viết tắt của Web Application Firewall – tường lửa ứng dụng web,
công cụ giúp bảo vệ các ứng dụng web bằng cách lọc và theo dõi lưu lượng trao
đổi giữa web server và mạng Internet. Một WAF hoạt động thông qua một tập
hợp các quy tắc thường được gọi là chính sách. Các chính sách này nhằm mục
đích bảo vệ chống lại các lỗ hổng trong ứng dụng bằng cách lọc ra lưu lượng
truy cập độc hại.
Bằng cách triển khai WAF trước ứng dụng web, một lá chắn được đặt
giữa ứng dụng web và Internet. Mặc dù máy chủ proxy bảo vệ danh tính của
máy khách bằng cách sử dụng trung gian, nhưng WAF là một loại proxy ngược,
bảo vệ máy chủ khỏi bị lộ bằng cách cho phép máy khách đi qua WAF trước khi
đến máy chủ.

Hình 1.1: Định nghĩa WAF

1.1.2. Phân loại WAF

a. Phân loại mô hình tường lửa có thể định cấu hình dựa trên loại hoạt
động bảo mật mà bạn yêu cầu:
Blocklist
Cấu hình WAF này bảo vệ các trang web và ứng dụng dựa trên web khỏi
bị khai thác bằng cách lọc truyền dữ liệu thông qua danh sách đặt trước các mối

1
đe dọa đã biết được gọi là Blocklist. Bạn có thể tạo Blocklist tự động và thủ
công.
Khi tường lửa nhận ra rằng một số gói dữ liệu phù hợp với các mối đe dọa
được ghi trong blocklist, nó sẽ ngay lập tức ngăn chặn mục nhập của chúng.
Blocklist cũng có thể tiết lộ các mối đe dọa được ngụy trang dưới dạng
yêu cầu thực trong lưu lượng mạng và chặn hiệu quả tất cả các mối đe dọa đã
biết, chẳng hạn như các cuộc tấn công DDoS.
Thiếu sót chính của nó là nó không hiệu quả trước các mối đe dọa mới
gây ra cho các tổ chức, chẳng hạn như các cuộc tấn công zero-day.
Allowlist
Tường lửa WAF giám sát việc truyền dữ liệu thông qua cấu hình bảo mật
này và được lập trình để chỉ cho phép lưu lượng mạng được phê duyệt trước.
Việc bật Allowlist cho trang web và ứng dụng web của bạn có thể gặp sự
cố vì danh sách này thường chặn các yêu cầu an toàn không gây hại cho hệ
thống.
Điều này là do, theo thiết kế, Allowlist chặn tất cả lưu lượng truy cập
mạng vào ứng dụng web trong khi chỉ cho phép những người được phê duyệt
trước trong danh sách cho phép.
Hybird
Loại tường lửa này sử dụng kết hợp cả Allowlist và Blocklist để tạo cấu
hình kết hợp cả hai loại.
b. Phân loại theo mô hình triển khai, có ba cách chính mà WAF được xây
dựng sử dụng trực tuyến với cách sử dụng ở mỗi trường hợp khác nhau:
Network-Based (Nền tảng mạng lưới):
Network-Based được cài đặt cục bộ trên mạng. Đặc điểm của dạng này đó
là việc cần bảo trì và không gian lưu trữ. Mục đích chính là giảm thiểu độ trễ.
Đây là một WAF dựa trên phần cứng.
Cloud-Based (Nền tảng đám mây):
Cloud-Based được chạy trên đám mây, quá trình cài đặt dễ dàng mà thông
thường chỉ cần yêu cầu thay đổi DNS. Cài đặt dễ dàng, mang lại nhiều lợi ích đi
kèm với sự tiện lợi không cần lưu trữ hay bảo trì tại chỗ. Đây là giải pháp WAF
rẻ nhất.

2
 Thông thường, phương pháp này là một dịch vụ đăng ký với các doanh
nghiệp về cơ bản chuyển giao bảo mật WAF của họ cho một công ty khác để
hợp lý hóa quy trình và tháo gỡ mọi khó khăn tiềm ẩn.
Host-Based (Nền tảng máy chủ):
Loại WAF thứ ba mà các công ty thường sử dụng là Host-Based với khả
năng cung cấp mức độ tùy chỉnh cao hơn. Tuy nhiên, phương pháp này cần chạy
trên các máy chủ cục bộ, yêu cầu bảo trì tại chỗ. Đây là một WAF tốn kém.
Do đó, Cloud-Based là giải pháp được khách hàng chú ý tới vì tính đơn
giản, tiện lợi của đám mây đem lại sự giải phóng khỏi phí lưu trữ và bảo trì.
1.1.3. So sánh WAF với NetworkFirewall và IDS/IPS

IPS là một sản phẩm bảo mật được tập trung rộng rãi hơn. Nó thường dựa
trên chữ ký và chính sách – có nghĩa là nó có thể kiểm tra các lỗ hổng nổi tiếng
và các vectơ tấn công dựa trên cơ sở dữ liệu chữ ký và các chính sách đã thiết
lập. IPS thiết lập một tiêu chuẩn dựa trên cơ sở dữ liệu và chính sách, sau đó gửi
cảnh báo khi có bất kỳ lưu lượng truy cập nào khác với tiêu chuẩn. Chữ ký và
chính sách phát triển theo thời gian khi các lỗ hổng mới được biết đến. Nói
chung, IPS bảo vệ lưu lượng trên nhiều loại giao thức như DNS, SMTP,
TELNET, RDP, SSH và FTP. IPS thường vận hành và bảo vệ tầng 3 và tầng 4
(Tầng mạng và tầng phiên).
Tường lửa truyền thống như Network Firewall, hệ thống phát hiện kẻ xâm
nhập (IDS) & Hệ thống ngăn chặn xâm nhập (IPS) rất tốt trong việc cung cấp
bảo mật cấp độ mạng và bảo mật lưu lượng mạng cấp độ mạng. Nhưng chúng
không có khả năng ngăn chặn các lỗ hổng hệ thống ứng dụng website OWASP
(Dự án bảo mật ứng dụng web mở) như SQL injection, chiếm quyền điều khiển
phiên, XSS, v.v… Nói một cách đơn giản, chúng không thể bảo vệ các cuộc tấn
công tầng ứng dụng (tầng 7).
Tường lửa ứng dụng web (WAF) bảo vệ tầng ứng dụng và được thiết kế
đặc biệt để phân tích từng yêu cầu HTTP/S ở tầng ứng dụng. Nó thường nhận
biết người dùng, phiên và ứng dụng, nhận thức được các ứng dụng web đằng sau
nó và những dịch vụ mà chúng cung cấp. Do đó, bạn có thể coi WAF là trung
gian giữa người dùng và chính ứng dụng, phân tích tất cả thông tin liên lạc trước
khi chúng đến ứng dụng hoặc người dùng. WAF truyền thống đảm bảo chỉ có
thể thực hiện các hành động được phép (dựa trên chính sách bảo mật). Đối với

3
nhiều tổ chức, WAF là tuyến phòng thủ đầu tiên, đáng tin cậy cho các ứng dụng,
đặc biệt là để bảo vệ khỏi Top 10 OWASP – danh sách cơ bản về các lỗ hổng
ứng dụng được thấy nhiều nhất (xem thêm ở Phụ lục).

Hình 1.2: So sánh WAF và Firewall, IDS/IPS

1.1.4. Hoạt động của tường lửa ứng dụng web

Hình 1.3: Mô hình của một hệ thống tường lửa ứng dụng Web (WAF)
WAF được triển khai trước các ứng dụng web và phân tích lưu lượng
HTTP – kiểm tra cả request GET và POST nhằm phát hiện và chặn bất kỳ thứ gì

4
độc hại. Không giống như tường lửa (Firewall) thông thường chỉ đóng vai trò
như một cổng an toàn giữa các server, WAF là một biện pháp bảo mật ứng dụng
được đặt giữa Web Client và Web Server.
Các cuộc tấn công độc hại đến máy tính thường được tự động hóa. Những
loại tấn công này rất khó phát hiện vì chúng thường được thiết kế để bắt chước
giống lưu lượng truy cập của con người và không bị phát hiện.
WAF thực hiện kiểm tra chi tiết mọi request và response đối với tất cả các
dạng lưu lượng truy cập web phổ biến. Việc kiểm tra này giúp WAF xác định và
chặn các mối đe dọa, ngăn chúng xâm nhập vào server.

Hình 1.4: Hoạt động của WAF

1.1.5. Lợi ích và tầm quan trọng của WAF

WAF có lợi thế hơn tường lửa truyền thống vì nó cung cấp khả năng hiển
thị tốt hơn đối với dữ liệu ứng dụng nhạy cảm được giao tiếp bằng cách sử dụng
lớp ứng dụng HTTP. Nó có thể ngăn chặn các cuộc tấn công lớp ứng dụng
thường vượt qua tường lửa mạng truyền thống, bao gồm những điều sau:
- Các cuộc tấn công cross-site scripting (XSS) cho phép kẻ tấn công đưa và
thực thi các đoạn mã độc hại trong trình duyệt của người dùng khác.
- Các cuộc tấn công đưa vào ngôn ngữ truy vấn có cấu trúc (SQL) có thể
ảnh hưởng đến bất kỳ ứng dụng nào sử dụng cơ sở dữ liệu SQL và cho phép kẻ
tấn công truy cập và có khả năng thay đổi dữ liệu nhạy cảm.
- Hack phiên web cho phép kẻ tấn công chiếm đoạt ID phiên và giả dạng
người dùng được ủy quyền. ID phiên thường được lưu trữ trong cookie hoặc
Uniform Resource Locator (URL).

5
 - Các cuộc tấn công từ chối dịch vụ (DDoS) phân tán áp đảo một mạng
bằng cách làm ngập nó với lưu lượng truy cập cho đến khi nó không thể phục vụ
người dùng. Cả tường lửa mạng và WAF đều có thể xử lý kiểu tấn công này
nhưng tiếp cận nó từ các lớp khác nhau.
Một ưu điểm khác của WAF là nó có thể bảo vệ các ứng dụng dựa trên
web mà không nhất thiết phải có quyền truy cập vào mã nguồn của ứng dụng.
Trong khi WAF dựa trên máy chủ có thể được tích hợp vào mã ứng dụng, WAF
được lưu trữ trên đám mây có khả năng bảo vệ ứng dụng mà không cần có
quyền truy cập. Ngoài ra, WAF đám mây rất dễ triển khai và quản lý, đồng thời
cung cấp các giải pháp vá lỗi ảo nhanh chóng cho phép người dùng tùy chỉnh
nhanh các cài đặt của họ để thích ứng với các mối đe dọa mới được phát hiện.
WAF quan trọng đối với số lượng ngày càng tăng các doanh nghiệp cung
cấp sản phẩm qua internet – bao gồm các ngân hàng trực tuyến, nhà cung cấp
nền tảng truyền thông xã hội và nhà phát triển ứng dụng di động – vì nó giúp
ngăn chặn rò rỉ dữ liệu. Nhiều dữ liệu nhạy cảm, chẳng hạn như dữ liệu thẻ tín
dụng và hồ sơ khách hàng, được lưu trữ trong cơ sở dữ liệu back-end có thể truy
cập được thông qua các ứng dụng web. Những kẻ tấn công thường nhắm mục
tiêu vào các ứng dụng này để giành quyền truy cập vào dữ liệu liên quan.
Ví dụ: các ngân hàng có thể sử dụng WAF để giúp họ đáp ứng Tiêu chuẩn
bảo mật dữ liệu ngành thẻ thanh toán (PCI DSS), là một bộ chính sách để đảm
bảo rằng dữ liệu của chủ thẻ (CHD) được bảo vệ. Cài đặt tường lửa là một trong
12 yêu cầu tuân thủ PCI DSS. Việc tuân thủ này áp dụng cho bất kỳ doanh
nghiệp nào xử lý CHD. Vì nhiều công ty mới hơn sử dụng các ứng dụng di động
và Internet vạn vật (IoT) ngày càng phát triển, ngày càng có nhiều giao dịch diễn
ra ở lớp ứng dụng bằng cách sử dụng web. Vì lý do này, WAF là một phần quan
trọng trong mô hình bảo mật của một doanh nghiệp hiện đại.

1.2. Kiến trúc WAF

1.2.1. Vị trí đặt WAF

Các thiết bị WAF cứng thường được đặt sau tường lửa mạng và trước
máy chủ ứng dụng web. Việc đặt WAF được thực hiện sao cho tất cả các lưu
lượng đến ứng dụng web cần qua WAF trước. Tuy nhiên, đôi khi cũng có ngoại
lệ khi WAF chỉ được dùng để giám sát cổng đang mở trên máy chủ web. Ngoài

6
ra các chương trình WAF còn được cài đặt trực tiếp lên máy chủ web và thực
hiện các chức năng tương tự như các thiết bị WAF để giám sát lưu lượng đến và
ra khỏi ứng dụng web.

Hình 1.5: Vị trí đặt WAF

1.2.2. Mô hình bảo mật

Một WAF hoạt động dựa theo 2 mô hình bảo mật: Positive và Negative.
Mô hình Positive chỉ cho phép các lưu lượng hợp lệ được định nghĩa sẳn đi qua
và chặn tất cả các lưu lượng còn lại. Mô hình Negative sẽ cho phép tất cả các
lưu lượng vượt qua và chỉ chặn các lưu lượng được mà WAF cho là nguy hại.
Đôi khi cũng có các WAF cung cấp cả 2 mô hình trên, tuy nhiên thông thường
WAF chỉ cung cấp 1 trong 2 mô hình. Với mô hình Postitive thì đòi hỏi nhiều
cấu hình và tùy chỉnh, còn mô hình Negative chủ yếu dựa vào khả năng học hỏi
và phân tích hành vi của lưu lượng mạng.
1.2.3. Mô hình hoạt động

WAF có thể hoạt động ở các mô hình riêng biệt, dưới đây là một số mô
hình tham khảo:
- Reverse Proxy: đây là chức năng được sử dụng phổ biến khi triển khai
WAF. Trong mô hình này, WAF giám sát tất cả các lưu lượng đi đến ứng dụng
web, sau đó thay vì cho các địa chỉ IP bên ngoài gửi yêu cầu trực tiếp đến máy
chủ web thì WAF đứng ra làm trung gian để gửi các yêu cầu này đến máy chủ
web thay cho trình duyệt gốc rồi gửi trả lại kết quả cho các địa chỉ IP kia. Mô
hình này có nhược điểm là tạo ra độ trễ khi kết nối từ trình duyệt đến ứng dụng
web.
- Transparent Proxy: Ở mô hình này, WAF đứng giữa tường lửa mạng và
máy chủ web và hoạt động tương tự ở mô hình Reverse Proxy nhưng không
đứng ra làm trung gian kết nối như bên Reverse Proxy. Mô hình này không đòi

7
hỏi phải thay đổi điều gì trong hạ tầng mạng nhưng có thể không cung cấp được
một số dịch vụ như mô hình Reverse Proxy có thể.
- Layer 2 Brigde: Ở mô hình này, WAF đứng giữa tường lủa mạng và
máy chủ web, nhưng hoạt động giống như một thiết bị Switch ở lớp 2. Mô hình
này giúp mạng hoạt động với hiệu năng cao và mạng thay đổi không đáng kể,
tuy nhiên nó lại không thể cung cấp các dịch vụ cao cấp khác mà các mô hình
WAF khác có thể.
- Host/Server Based: Đây là các phần mềm được cài trực tiếp lên máy chủ
web. Các loại Host based không cung cấp các tính năng tương tự như các loại
WAF network base. Tuy nhiên mô hình này có thể khắc phục được vài điểm yếu
mà các mô hình network base (các thiết bị WAF cứng) có. Tuy nhiên nó cũng
làm tăng mức độ tải của máy chủ web.

1.3. Các phiên bản WAF mã nguồn mở phổ biến

1.3.1. ModSecurity

ModSecurity là một module mở rộng cho các web server như Apache,
Nginx, IIS và hoạt động như một firewall tại lớp ứng dụng web. Mod Security
đứng trước Web Server, làm nhiệm vụ như một firewall để kiểm soát truy cập
vào ra Web Server. Các thông tin đi từ bên ngoài vào bên trong ra sẽ được kiểm
soát chặt chẽ để tránh những thông tin có thể gây hại cho Web Server hay là việc
rò rỉ các thông tin đặc biệt từ Web Server đến Client.
Mục đích của ModSecurity là tăng cường bảo mật cho các ứng dụng web,
bảo vệ chúng khỏi các loại tấn công đã biết và chưa biết. Modsec sẽ giúp hạn
chế các vấn đề:
- Cross-site scripting
- Trojan
- Information leakage
- SQL injection
- Common web attacks
- Malicious activity

8
1.3.2. WebKnight

Là 1 sản phẩm dành cho các máy chủ web IIS sử dụng bộ lọc ISAPI bảo
vệ máy chủ web của bạn bằng cách chặn các yêu cầu xấu. Nó giúp ngăn chặn 1
số vấn đề sau:
- Buffer overflow
- Directory transversal
- Character encoding
- SQL injection
- Blocking bad robots
- Hotlinking
- Brute force
- And much more…
1.3.3. Shadow Daemon

Là một tập hợp các công cụ để phát hiện, ghi lại và ngăn chặn các cuộc
tấn công vào các ứng dụng web. Nó hỗ trợ ngôn ngữ PHP, Perl và Python. Nó
có thể phát hiện 1 số vấn đề sau:
- SQL injection
- XML injection
- Code injection
- Command injection
- XSS
- Backdoor access
- Local/remote file inclusion
1.3.4. NAXSI

Là viết tắt của Nginx Anti XSS and SQL injection. NAXSI là một module
web application firewall (WAF), opensource với hiệu năng cao của Nginx.
NAXSI hoạt động chủ yếu dựa vào việc phân tích tìm kiếm các ký tự đặc biệt
hay không mong muốn trong các HTTP GET và POST request.
1.3.5. F5 Advance

Cách tính năng WAF F5 Advanced như:

9
 - Bảo vệ ứng dụng nâng cao:kết hợp máy học thông minh để tìm ra các mối
đe dọa tinh vi.
- Chống tấn công Botnet: Bảo vệ ứng dụng khỏi các cuộc tấn công tự động
bởi bot và các công cụ độc hại khác.
- Chống bot SDK cho các ứng dụng trên di động: Bảo vệ các ứng dụng
dành cho thiết bị di động thông qua danh sách cho phép, phân tích hành vi, xác
thực cookie an toàn và tăng cường ứng dụng nâng cao.
- Mã hóa dữ liệu trong trình duyệt.
- Chống tấn công DDoS có chủ đích: Phân tích hành vi và máy học thông
minh nhằm cung cấp khả năng phát hiện và giảm thiểu DDoS Layer 7 với độ
chính xác cao.
- Bảo mật giao thức API: Triển khai các công cụ bảo mật API REST/
JSON, XML và GWT.

1.4. Kết luận Chương 1

WAF (Web Application Firewall) chính là một phương pháp tối ưu và

hữu hiệu nhất để bảo vệ tránh các tủi ro về bảo mật và đảm bảo an toàn đối với
người quản trị và người dùng.
Tường lửa bảo vệ ứng dụng Web (WAF) cho phép ngăn chặn và giảm
thiểu các cuộc tấn công lỗ hổng ở lớp ứng dụng như: SQL injection, cross-site
scripting, botnet, DDoS attacks... mà các tường lửa thông thường (Network
Firewall) không ngăn chặn được, đồng thời hệ thống đưa ra các cảnh báo tấn
công, đề xuất giải pháp ngăn chặn các lỗ hổng đã phát hiện được.

10
 CHƯƠNG 2: GIỚI THIỆU VỀ MODSECURITY WAF

2.1. Tổng quan về ModSecurity

Mod Security do Ivan Ristic phát triển là một module tường lửa có thể
tích hợp với các Web Application Server như Apache, IIS, Nginx. Mod Security
đứng trước Web Server, làm nhiệm vụ như một firewall để kiểm soát truy cập
vào ra Web Server. Các thông tin đi từ bên ngoài vào bên trong ra sẽ được kiểm
soát chặt chẽ để tránh những thông tin có thể gây hại cho Web Server hay là việc
rò rỉ các thông tin đặc biệt từ Web Server đến Client.
Mục đích của ModSecurity là tăng cường bảo mật cho các ứng dụng web,
bảo vệ chúng khỏi các loại tấn công đã biết và chưa biết. Cùng với sự gia tăng
về phương pháp tấn công web thì ModSecurity cũng đã cập nhật những rule và
đưa ra nhiều cách phòng chống trong mã nguồn của chương trình. Một số tính
chất mà ModSecurity có thể dùng làm Web Application Firewall:
Tính linh động (Flexibility):
Việc phân tích luồng HTTP theo một tiêu chí nhất định trong thực tế
thường gặp vấn đề là làm sao để có thể so trùng mẫu mà bạn muốn. Ngoài ra, do
nhu cầu của từng hệ thống web là khác nhau dẫn đến việc phân tích trên từng
loại ứng dụng cũng khác nhau. Mod_security đã kết hợp với OWASP phát triển
các tập rule mẫu (Core Rule Set) nhằm tạo ra tính linh động cho từng mô hình
web khác nhau, hỗ trợ người quản trị phân tích theo nhu cầu thực tế của hệ
thống đang quản trị.
Tính thụ động (Passivity):
Mod Security sẽ không thực thi các tác vụ nếu như người quản trị viên
không chỉ định công việc cụ thể cho chương trình; việc này là khá quan trọng
trong một ứng dụng có nhiệm vụ phân tích nguy cơ như ModSecurity. Mọi cảnh
báo sẽ được thực hiện thông qua cơ chế phân tích và quyết định tương tác với hệ
thống sẽ do người quản trị thực hiện.

2.2. Tính năng của ModSecurity

ModSecurity hoạt động với chương trình web server (ví dụ: Apache) sẽ
thực hiện các tác vụ như sau:
Parsing

11
 ModSecurity sẽ phân tách các dữ liệu luân chuyển qua hệ thống thành cấu
trúc dữ liệu mà ModSecurity định nghĩa sẵn. Cấu trúc này sẽ được chuyển qua
cơ chế so trùng mẫu trong tập rule để phân tích nguy cơ.
Buffering
Chức năng buffer (đệm) đóng vai trò khá quan trọng trong cơ chế hoạt
động của ModSec. Việc này có ý nghĩa khi các request gửi đến ứng dụng web
thì phải thông qua ModSecurity trước khi đến ứng dụng xử lý và những
response cũng sẽ được phân tích trước khi trả về phía client. Cơ chế này là cách
duy nhất để có thể ngăn chặn các cuộc tấn công thời gian thực, các dữ liệu mà
ModSecurity nhận được và phân tích sẽ được lưu trữ trong RAM (bao gồm
request body và response data)
Logging
ModSecurity hỗ trợ ghi nhật ký các gói tin HTTP: request headers,
request body, response header, response body nhằm hỗ trợ người quản trị phân
tích nguy cơ mà hệ thống đang gặp phải để có thể ra quyết định kiểm soát.
Rule Engine
Các tập mẫu trong ModSecurity đóng vai trò quan trọng trong việc phát
hiện các dạng tấn công và thực hiện phòng chống. ModSecurity cùng phát triển
với dự án OWASP phát triển một nhóm các tập lệnh có tên là OWASP
ModSecurity CRS để phân tích và phòng chống các tấn công hệ thống web.
Nhằm mục đích bảo vệ các ứng dụng web phổ biến, CRS phân loại nội
dung các rule dựa trên các phương pháp tấn công:
- HTTP Protection: phát hiện các nguy cơ dựa trên giao thức HTTP như
Method (GET HEAD POST …), phiên bản HTTP (1.0, 1.1)
- Real-time Blacklist Lookups: lọc các dãy IP nguy hiểm dựa vào một bên
thứ ba.
- Web-based Malware Detection: xác định các mã độc trong nội dung trang
web bằng cách sử dụng Google Safe Browsign API.
- HTTP Denial of Service Protections: chống lại dạng tấn công từ chối dịch
vụ như HTTP Flooding và Slow HTTP DoS.
- Common Web Attacks Protection: phát hiện một số dạng tấn công phổ
biếtn vào ứng dụng web Automation Detection: phát hiện các bots, crawler,
chương trình quét (scanner) và các hoạt động thu thập thông tin.

12
 - Integration with AV Scanning for File Uploads: phát hiện các mã độc,
webshell, 0days thông qua các chức năng upload tập tin.
- Tracking Sensitive Data: theo dõi các hoạt động và chặn lộ thông tin thẻ
tín dụng (trong trường hợp website có hoạt động thương mại điện tử).
- Trojan Protection: phát hiện các mẫu trojan.
- Identification of Application Defects: cảnh báo các lỗi trong quản lý cấy
hình ứng dụng webserver.
- Error Detection and Hiding: gửi các mã thông báo lỗi giả về phía người
dùng.

2.3. Cấu trúc rules trong ModSecurity

Tất cả các hoạt động trong ModSecurity hầu hết sẽ liên quan đến hai phần
chính là: cấu hình (configuration) và các tập luật (rules). Phần cấu hình chỉ định
cách thức xử lý dữ liệu, trong khi các rule sẽ quyết định thực hiện các hành vi
(action) với dữ liệu đã được xử lý.
Một ví dụ về rule: SecRule ARGS "<script>" log,deny,status:404
Cấu trúc chuẩn của một rule trong ModSecurity bao gồm 3 phần chính:
SecRule VARIABLES OPERATOR ACTIONS
2.3.1. VARIABLE

VARIABLES xác định vị trí dữ liệu mà ModSecurity sẽ tìm kiếm mẫu.

Trong ví dụ trên, tham số ARGS nhằm chỉ định tìm kiếm mẫu trong tất cả các
tham số trong request.
Các tham số thường thấy của VARIABLES:
REMOTE_ADDR: Địa chỉ IP của client.
REMOTE_HOST: Hostname của client (nếu tồn tại) .
REMOTE_USER: Authenticated username (nếu tồn tại) .
REMOTE_IDENT: Remote Username (lấy từ inetd, ít dùng) .
REQUEST_METHOD: Request Method (GET, HEAD, POST..) .
SCRIPT_FILENAME: Đường dẫn đầy đủ của script được thực thi.
PATH_INFO: Phần mở rộng của URI phía sau tên của một script.
Ví dụ: /archive.php/5 thì PATH_INFO là /5
QUERY_STRING: URI phía sau dấu ?.
Ví dụ /index.php?i=1 thì QUERY_STRING là i=1.

13
AUTH_TYPE: Basic hoặc Digest Authentication.
DOCUMENT_ROOT: Đường dẫn đến documentroot.
SERVER_ADMIN: Email của Server Administrator.
SERVER_NAME: Hostname của Server.
SERVER_ADDR: Địa chỉ IP của Server.
SERVER_PORT: Server port.
SERVER_PROTOCOL: Protocol, (ví dụ HTTP/1.1).
SERVER_SOFTWARE: Apache version.
TIME_YEAR: Năm hiện tại (2014).
TIME_MON: Tháng hiện tại (12).
TIME_DAY: Ngày.
TIME_HOUR: Giờ.
TIME_MIN: Phút.
TIME_SEC: Giây.
TIME_WDAY: Thứ tự ngày trong tuần (ví dụ 4 - Thursday).
TIME : Thời điểm hiện tại được viết theo cấu trúc: YmdHMS.
Ví dụ: 20060220144530: 20/02/2006 14h 45' 30''.
API_VERSION
THE_REQUEST: Dòng đầu tiên của request. vd: GET / HTTP/1.1.
REQUEST_URI: Request URI.
FILENAME: Tên file được yêu cầu đến.
IS_SUBREQ
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
Có thể dùng 1 hay nhiều variables
SecRule ARGS|REQUEST_HEADERS:User-Agent dirty
2.3.2. OPERATOR

OPERATOR: chỉ định cách mà ModSecurity sẽ tìm kiếm mẫu. Các

operator được dùng theo dạng Regular expression nhằm tạo nên cơ chế phân
tích linh động cho các rule.

14
 Sử dụng @ để chỉ ra đây là một operation
Sử dụng !@ để chỉ ra một operation negation
Toán tử @rx (regular expression) là một toán tử mặc định, được sử dụng
khi không có một toán tử nào khác được chỉ định.

Hình 2.1: Operation(1)

Hình 2.2: Operation (2)

2.3.3. ACTIONS

ACTIONS: chỉ định hành động mà ModSecurity sẽ thực hiện khi có một mẫu
được so trùng. Trong ví dụ trên, phần action được viết log,deny,status:404 có

15
nghĩa là: khi trùng mẫu <script> trong gói tin thì thực hiện ghi log, deny gói tin
bằng cách sử dụng mã trạng thái 404 (Not found).
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:
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ó 4 primary actions:
- 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õ allow:phase
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
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 Actions
Chain: kết nối 2 hay nhiều rules lại với nhau.
Skipnext : n: ModSecurity sẽ bỏ qua n rules theo sau nó.
Default Action
Khi một rule không chỉ rõ action thì rule đó sẽ dùng default action được
thiết lập trong SecDefaultAction.
Ví dụ: SecDefaultAction "phase:2,deny,log,status:403"

16
2.4. Quy trình xử lý trong ModSecurity

Trong ModSecurity mỗi phiên phân tích sẽ thực hiện lần lượt qua 5 bước
(pha), tại mỗi bước ModSecurity sẽ thực thi các rule tương ứng nhằm phát hiện
và phòng chống các khai thác.

Hình 2.3: Quy trình xử lí của ModSecurity

Request Header (1)
Đây là bước đầu tiên trong quá trình thực hiện phân tích gói tin. Mục đích
của bước này nhằm cho phép người viết rule tương tác với các request trước khi
thực hiện các yêu cầu trong phần HTTP body. Phần này khá quan trọng để phân
tích các khai thác dựa vào HTTP method cũng như dựa vào URL như SQL
Injection, Reflect XSS, Local file include …
Request body (2)
Bước 2 là quá trình kiểm tra chính trong quá trình client gửi request đến
server, phần này sẽ có hiệu quả khi người dùng cố sử dụng phương thức POST
hoặc PUT để upload tập tin lên phía server. Việc kiểm tra này bảo đảm dữ liệu

17
đưa lên server là an toàn, tránh tình trạng upload mã độc hoặc các dạng tấn công
nhưng Stored XSS, Ajax Injection …
Response headers (3)
Những request đã được xử lý tại server sẽ được trả về cho ModSecurity
kiểm tra trạng thái trong phần respone header. Trước khi phần respone body
được đọc thì ModSecurity sẽ dựa vào tập rule để xác định có cần kiểm tra nội
dung dữ liệu trong phần body hay không.
Ví dụ: mã trạng thái trả về là 404 (Not found) thì lúc này sẽ không cần
kiểm tra nội dung gói tin trả về.
Response body (4)
Sau khi ModSecurity đã hoàn thành việc kiểm tra tại respone header thì
nội dung trong phần body sẽ được kiểm tra so trùng với mẫu trong tập lệnh.
Việc này là khá hiệu quả để phát hiện và phòng chống xâm nhập trong trường
hợp bước 1 và 2 không phát hiện được tấn công.
Ví dụ: trong khai thác SQL injection, nếu hacker cố gắng sử dụng một số
công nghệ evasion thì việc phát hiện khi request là khó han. Khi khai thác thành
công, ModSecurity sẽ phân tích kết quả trong gói tin trả về để phát hiện nếu như
câu truy vấn thành công.
Logging (5)
Việc ghi log sẽ ghi nhận các cảnh báo cũng như quy trình làm việc của
ModSecurity.

2.5. Kết luận Chương 2

ModSecurity là một web application firewall (WAF) được Ivan Ristic

phát triển dành cho Apache Web Server. Giống như những firewall thông
thường khác, nó lọc những lưu lượng dữ liệu vào và ra để có thể quyết định chặn
lại những lưu lượng mà nó nghi ngờ là độc hại dựa theo tập lệnh nó định nghĩa.
Nó còn có nhiều tính năng vượt trội khác như: HTTP transaction logging và
content injection…
Các luật được tạo và chỉnh sửa sử dụng một định dạng văn bản đơn giản,
nó làm cho việc viết rules trở nên đơn giản hơn. Một khi đã quen với cú pháp
của ModSecurity, chúng ta có thể nhanh chóng viết được những rules để block
một exploit mới hoặc ngăn chặn một lỗ hổng.

18
 Có thể hình dung ModSecurity như là một trạm trung gian giữa HTTP
request và httpd (dịch vụ web server). Khi phát hiện ra một cuộc tấn công,
những chi tiết về vụ tấn công sẽ được lưu vào log file hoặc một email có thể
được gửi tới người quản trị viên để báo hiệu có một cuộc tấn công xảy ra trên hệ
thống.
ModSecurity cho phép bạn bảo vệ server của mình thông qua việc viết các
luật nhằm bao phủ một dải các viễn cảnh tấn công có thể. Do đó, ModSecurity là
một lớp bổ sung có thể giúp bạn bảo vệ theo một cách không cần bản vá.
ModSecurity giải quyết các vấn đề tầm nhìn: nó giúp bạn nhìn thấy lưu
lượng web của mình. Đó là chìa khóa trong security: mỗi khi bạn có thế nhìn
thấy HTTP traffic, bạn có thể phân tích nó trong thời gian thực, record nó khi
cần thiết và phàn ứng lại với các sự kiện. Điểm nổi bật ở đây là bạn có thể làm
tất cả mà không tác động gì tới các ứng dụng web. Thậm chí tốt hơn, nó còn có
thể áp dụng với bất kì ứng dụng nào, ngay cả khi bạn không thể truy được vào
source code.
Chương kế tiếp sẽ triển khai ModSecurity hoạt động trên Apache
Webserver để chúng ta hiểu rõ hơn cách thức hoạt động và kết quả mà nó đem
lại.

19
 CHƯƠNG 3: TRIỂN KHAI WAF VỚI MODSECURITY

3.1. Mô hình thực nghiệm

Hình 3.1: Mô hình thực nghiệm

3.2. Các bước thực hiện

3.2.1. Cài đặt ModSecurity

Để cài đặt và định cấu hình ModSecurity, cần có máy chủ Linux và đảm
bảo web server Apache đã hoạt động tốt.
Cài đặt ModSecurity bằng câu lệnh thực hiện trên terminal:
sudo apt install libapache2-mod-security2 -y
Ngoài ra, bạn cũng có thể cài đặt ModSecurity theo cách thủ công bằng
cách sao chép kho lưu trữ ModSecurity Github.

20
 Hình 3.2: Cài đặt ModSecurity
3.2.2. Cấu hình ModSecurity

ModSecurity là tường lửa và do đó yêu cầu các quy tắc để hoạt động.
Phần này thực hiện triển khai OWASP Core Rule Set (OWASP-CRS). Trước
tiên, chuẩn bị tệp cấu hình ModSecurity.
Xóa phần mở rộng .recommended khỏi tên tệp cấu hình ModSecurity
bằng lệnh sau:
sudo cp /etc/ModSecurity/ModSecurity.conf-recommended
/etc/ModSecurity/ModSecurity.conf
Mở file /etc/ModSecurity/ModSecurity.conf và thay đổi giá trị cho
SecRuleEngine thành On:
# -- Rule engine initialization ----------------------------------------------

# Enable ModSecurity, attaching it to every transaction. Use detection

# only to start with, because that minimises the chances of post-
installation
# disruption.
#
SecRuleEngine On
...

21
 Hình 3.3: nano /etc/ModSecurity/ModSecurity.conf

Khởi động lại Apache để áp dụng các thay đổi:

sudo systemctl restart apache2
Bộ quy tắc cốt lõi ModSecurity OWASP (CRS) là một bộ quy tắc phát
hiện tấn công chung để sử dụng với ModSecurity hoặc tường lửa ứng dụng web
tương thích. CRS nhằm mục đích bảo vệ các ứng dụng web khỏi một loạt các
cuộc tấn công, bao gồm cả Top Ten OWASP, với tối thiểu các cảnh báo sai.
CRS cung cấp sự bảo vệ chống lại nhiều loại tấn công phổ biến, bao gồm SQL
injection, Cross Site Scripting (XSS) và Local File Inclusion. Để thiết lập
OWASP-CRS, thực hiện theo các bước sau:
Trước tiên, xóa bộ quy tắc mặc định của ModSecurity bằng cách chạy
lệnh sau:
sudo rm -rf /usr/share/ModSecurity-crs
Sao chép kho lưu trữ OWASP-CRS GitHub vào thư mục
/usr/share/ModSecurity-crs:
sudo git clone https://github.com/coreruleset/coreruleset
/usr/share/ModSecurity-crs

22
 Đổi tên file crs-setup.conf.example thành crs-setup.conf
sudo mv /usr/share/ModSecurity-crs/crs-setup.conf.example
/usr/share/ModSecurity-crs/crs-setup.conf
Đổi tên tệp quy tắc loại trừ yêu cầu mặc định:
sudo mv /usr/share/ModSecurity-crs/rules/REQUEST-900-EXCLUSION-
RULES-BEFORE-CRS.conf.example
/usr/share/ModSecurity-crs/rules/REQUEST-900-EXCLUSION-RULES-
BEFORE-CRS.conf
Để bắt đầu sử dụng ModSecurity, kích hoạt trong tệp cấu hình Apache
bằng cách thực hiện theo các bước sau:
Chỉnh sửa tệp /etc/apache2/mods-available/security2.conf , thêm vào nội
dung sau trên để bao gồm các tệp OWASP-CRS mà đã tải xuống:
<IfModule security2_module>
SecDataDir /var/cache/ModSecurity
Include /usr/share/ModSecurity-crs/crs-setup.conf
Include /usr/share/ModSecurity-crs/rules/*.conf
</IfModule>

Hình 3.4: nano /etc/apache2/mod-available/security2.conf

23
 Trong /etc/apache2/sites-enabled/000-default.conf tệp VirtualHost, thêm
các nội dung sau bao gồm chỉ thị SecRuleEngine đặt thành On:
<VirtualHost *:80>
ServerAdmin webmaster@localhost
DocumentRoot /var/www/html

ErrorLog ${APACHE_LOG_DIR}/error.log
CustomLog ${APACHE_LOG_DIR}/access.log combined

SecRuleEngine On
</VirtualHost>

Hình 3.5: nano /etc/apache2/sites-enabled/000-default.conf

Chỉ thị SecRuleEngine để ở chế độ DetectionOnly nghĩa là chỉ phát hiện
tấn công và cảnh báo trong file error.log
Sau đó khởi động lại dịch vụ Apache2 để áp dụng cấu hình đã thay đổi.
sudo systemctl restart apache2
Như vậy ta đã cài đặt xong ModSecurity và cấu hình với bộ quy tắc
OWASP-CRS. Các dịch vụ thiết lập hoàn tất, chúng ta sẽ thử nghiệm kết quả
trên DVWA.

24
3.2.3. Cài đặt DVWA:

Đầu tiên, khởi chạy Terminal và điều hướng đến thư mục /var/www/html
$ cd /var/www/html
Tiếp theo, sao chép kho lưu trữ DVWA GitHub trong thư mục /html:
$ sudo git clone https://github.com/ethicalhack3r/DVWA

Hình 2: Clone DVWA Github

Sau khi sao chép thành công kho lưu trữ, xác nhận DVWA đã được sao
chép thành công, chạy lệnh:

Hình 3.7: Download DVWA thành công

Bây giờ chúng ta cần gán quyền Read, Write và Execute (777) cho thư
mục này:
sudo chmod -R 777 DVWA
Để thiết lập và định cấu hình DVWA, điều hướng đến thư mục
/DVWA/config để xem nội dung thư mục cấu hình ta sẽ thấy được file cấu hình
mặc định của DVWA là config.inc.php.dist
Tạo một bản sao của tệp này với tên config.inc.php sử dụng để định cấu
hình DVWA.

25
 sudo cp config.inc.php.dist config.inc.php
Mở tệp vừa sao chép để thực hiện cấu hình cần thiết:
sudo nano config.inc.php
Đổi các thông tin như hình dưới đây:

Hình 3.8: Cấu hình DVWA

Theo mặc định, Kali Linux được cài đặt cùng với hệ thống quản lý cơ sở
dữ liệu quan hệ MariaDB. Đầu tiên, khởi động dịch vụ mysql bằng lệnh bên
dưới.
sudo systemctl start mysql
Đăng nhập vào cơ sở dữ liệu với quyền root. Tạo người dùng mới với
thông tin đăng nhập là thông tin đặt trong tệp config.inc.php trong /DVWA.
Thực hiện lần lượt các lệnh sau, sau khi tạo thành công thì exit.
MariaDB [(none)]> create user 'userDVWA'@'127.0.0.1' identified by
"dvwa";
MariaDB [(none)]> grant all privileges on dvwa.* to
'userDVWA'@'127.0.0.1' identified by 'dvwa';
Khởi chạy lại dịch vụ Apache2 và Mysql.
sudo systemctl start apache2
sudo systemctl start mysql
Cài đặt và cấu hình xong, chúng ta truy cập vào DVWA trên Web
Browser với đường dẫn http://127.0.0.1/DVWA/setup.php . Click vào Create /
Reset Database để bắt đầu đăng nhập sử dụng.

26
 Hình 3.9: http://127.0.0.1/DVWA/setup.php
Sử dụng thông tin đăng nhập mặc định bên dưới để đăng nhập:
Username: admin
Password: password

Hình 3.10: http://127.0.0.1/DVWA/login.php

27
 Hình 3.11: Giao diện DVWA khi đăng nhập thành công
Chọn mức Low ở mục DVWA Security để cài đặt mức độ thực hành tấn
công.
3.2.4. Triển khai ModSecurity trên DVWA

Với vai trò một Attacker tại máy Client sử dụng phương thức XSS và
SQL Injection tấn công website:
Kịch bản 1: Ngăn chặn tấn công SQL injection

Hình 3.12: Giao diện SQL injection ban đầu

28
 Trước khi bật ModSecurity, tiêm câu truy vấn ' or 'x'='x vào, tấn công
thành công vào cơ sở dữ liệu.

Hình 3.13: Tấn công SQL thành công

Sau khi mở ModSecurity, trực tiếp chặn truy cập:

Hình 3.14: Trang web sau khi bật ModSecurity(SQL)

29
 Hình 3.15: Log ghi lại sau khi thực hiện tấn công SQL

Kịch bản 2: Ngăn chặn tấn công Cross Site Scripting (XSS)

Hình 3.16: Giao diện trang thực hiện tấn công XSS

Chèn mã script vào: <script>alert(‘votramy’)</script>

30
 Hình 3.17: Tấn công XSS thành công
Sau khi mở ModSecurity với SecRuleEngine ở chế độ On, trực tiếp chặn
truy cập:

Hình 3.18: Trang web sau khi bật ModSecurity (XSS)

31
 Hình 3.19: Log ghi lại sau khi thực hiện tấn công XSS
3.3. Kết luận chương 3

Chương trình triển khai bảo vệ website sử dụng WAF ModSecurity đã

được xây dựng thành công, đáp ứng yêu cầu đặt ra là thấy được hoạt động và lợi
ích khi sử dụng. Từ các kiến thức về ModSecurity trên, người dùng cũng có thể
tự viết rules để bảo vệ sâu hơn cho trang web của mình.

32
 KẾT LUẬN
Ba chương của báo cáo đã thể hiện được rằng những mục tiêu đặt ra khi
thực hiện đề tài đều đã đạt được. Cụ thể:
Chương 1 đã hệ thống các kiến thức tổng quan về Tường lửa ứng dụng
web (WAF). Chương này đã cho thấy được cả những lợi ích và tầm quan trong
của WAF đối với hệ thống website.
Chương 2 là những kiến thức cơ bản về module mã nguồn mở của WAF
là ModSecurity. ModSecurity cho phép bạn bảo vệ server của mình thông qua
việc viết các luật nhằm bao phủ một dải các viễn cảnh tấn công có thể. Do đó,
ModSecurity là một lớp bổ sung có thể giúp bạn bảo vệ theo một cách không
cần bản vá. Các luật của ModSecurity được tạo và chỉnh sửa sử dụng một định
dạng văn bản đơn giản, nó làm cho việc viết rules trở nên đơn giản hơn. Một khi
đã quen với cú pháp của ModSecurity, chúng ta có thể nhanh chóng viết được
những rules để block một exploit mới hoặc ngăn chặn một lỗ hổng.
Trong chương 3, cấu hình và cài đặt thành công ModSecurity áp dụng
OWASP- Core Rule Set, minh hoạ thành công tác dụng của ModSecurity trong
việc ngăn chặn tấn công SQL injection, XSS.
Dù vậy, trên thực tế các lỗ hổng bảo mật hệ thống Website rất phức tạp.
Trước hết, báo cáo này mới chỉ tìm hiểu và thực hiện được cơ bản nhất về
ModSecurity ứng dụng làm Tường lửa ứng dụng web. Tìm hiểu sâu hơn về
ModSecurity và phân tích các rule ứng dụng thực tế của nó sẽ là hướng phát
triển của đề tài này.

33
 TÀI LIỆU THAM KHẢO:

[1]. Jim Beechey. Web Web Application Firewalls:Defense in Depth for Your
Web Infrastructure

[2]. Dustin Anders, CISSP. Introduction To Web Application Firewalls

[3]. F5 DevCentral. What is a Web Application Firewall (WAF)?

[4]. Breach Security, Inc. Mod Security For Apache User Guide

[5]. KALIMARVEL3000. Installation of ModSecurity WAF in Kali Linux

Apache2 server tested on DVWA |howtoinstallmodsecurity

[6]. Hackersploit .Securing Apache 2 With ModSecurity.

https://www.linode.com/docs/guides/securing-apache2-with-modsecurity/

[7]. NoobLinux. How to Install DVWA on Kali Linux for Pentesting Practice.
https://nooblinux.com/how-to-install-dvwa/

[8]. Khoa ATTT- Học viện Kỹ thuật Mật mã. Tìm hiểu Modsecurity

34
 PHỤ LỤC
OWASP (Open Web Application Security Project) là một dự án phi lợi
nhuận, tập trung vào việc cải thiện tính bảo mật của ứng dụng web. Thành viên
của dự án là các cá nhân, tổ chức, chuyên gia … cùng đóng góp các mã nguồn,
công cụ hỗ trợ kiểm tra lỗ hổng ứng dụng web.
Năm 2010, cộng đồng OWASP xuất bản “Tài liệu hướng dẫn kiểm tra
ứng dụng Web” phiên bản 3 (OWASP Testing Guide v3:
https://www.owasp.org/index.php/OWASP_Testing_Project). Tài liệu liệt kê và
phân nhóm các lỗ hổng bảo mật đã được biết đến trong ứng dụng web. Đồng
thời nội dung của tài liệu này mô tả các dự án được cộng đồng phát triển, bao
gồm dự án WAF ModSecurity.
Dưới đây là thông tin về Top 10 OWASP:
Nhóm này bao gồm các lỗ hổng như SQL injection, OS
command injection, LDAP injection…các lỗ hổng trong
A1-Injection
phân nhóm này cho phép hacker truy cập hoặc chèn các dữ
liệu giả vào hệ thống thông qua các câu truy vấn dữ liệu.
XSS xuất hiện khi một ứng dụng web cho phép người dùng
nhập các dữ liệu vào mà không thông qua kiểm duyệt nội
dung, những dữ liệu này sẽ tương tác trực tiếp với những
A2-Cross Site người dùng khác cùng sử dụng website. Nguy cơ tạo ra là
Scripting (XSS) hacker có thể chèn các mã kịch bản như HTML,
Javascript… nhằm ăn cắp SessionCookie, thay đổi giao
diện (deface) hoặc chuyển hướng đến trang có mã độc
khác.
Phân nhóm này liệt kê các nguy cơ về chức năng xác thực
A3-Broken
và quản lý phiên (session management) trong ứng dụng
Authentication
web. Thông thường các chức năng này không được triển
and Session
khai tốt, cho phép hacker vượt qua cơ chế kiểm duyệt
Management
người dùng.
A4-Insecure Nguy cơ trong nhóm A4 thường được gặp trong trường
Direct Object hợp các lập trình viên sử dụng tham chiếu đến một tập tin,
References thư mục hoặc các truy vấn database trong mã nguồn. Nếu
các tham chiếu này không được quản lý chặt chẽ, thì việc

35
 truy cập dữ liệu trái phép từ bên ngoài rất là nguy hiểm.
Một cuộc tấn công CSRF yêu cầu một người dùng đã đăng
A5-Cross Site nhập. Tiếp theo, hacker sẽ chèn các mã kịch bản đã được
Request Forgery dựng sẵn vào nội dung trang web nhằm thực thi một hành
(CSRF) động bất hợp pháp với quyền của người dùng đã đăng
nhập.
Các yêu cầu về bảo mật ứng dụng web cũng bao gồm việc
cấu hình và triển khai hệ thống, ứng dụng webserver
(Apache, Nginx, Tenginx…), cơ sở dữ liệu (MySQL,
A6-Security
Oracle…), hệ điều hành (Linux, Windows…). Tất cả công
Misconfiguration
việc thiết lập môi trường cho ứng dụng web hoạt động cần
được lên kế hoạch theo dõi, kiểm tra, cập nhật thường
xuyên nhằm giảm thiểu nguy cơ hệ thống bị khai thác.
Rất nhiều ứng dụng web không quan tâm đến việc bảo vệ
dữ liệu nhạy cảm như thông tin thẻ tín dụng, SSN và các
A7-Insecure
thông tin xác thực. Việc hacker thu thập các dữ liệu nhạy
Cryptographic
cảm không được mã hóa (encrypt) hoặc băm (hash) sẽ tạo
Storage
ra mối nguy hiểm lớn cho những website cho phép giao
dịch thông qua thương mại điện tử.
Hầu hết các ứng dụng thường thực hiện kiểm soát việc truy
cập thông qua URL (thông qua cơ chế Rewrite). Việc giới
A8-Failure to hạn quyền truy cập vào các tập tin, thư mục nhạy cảm là
Restrict URL cần thiết. Trong một số tình huống, việc kiểm soát này
Access không được quản lý đầu đủ tạo nguy cơ xâm nhập trái phép
vào ứng dụng (ví dụ: thư viện fckditor thường có thể truy
cập trực tiếp không cần xác thực).
Thông tin xác thực được truyền qua môi trường mạng
truyền dẫn không bảo mật sẽ tạo ra nguy cơ dữ liệu bị nghe
A9-Insufficient
lén. Việc này cũng tương tự nếu như ứng dụng sử dụng các
Transport Layer
chứng chỉ số (certificate) với các khóa yếu (weak key),
Protection
thuật toán mã hóa yếu (weak algorithms) hoặc chứng chỉ
đã hết hạn sử dụng (expired).
A10-Unvalidated Các ứng dụng web thường chuyển hướng người dùng đến
Redirects and những trang web hoặc URL khác nhau. Hacker có thể lợi

36
 dụng cơ chế này để chuyển hướng người dùng đến những
Forwards
website chứa phần mềm độc hại hoặc trang đăng nhập giả.
Dự án OWASP ModSecurity Core Rule Set (CRS) sử dụng bản quyền
ASLv2. Các tập rule trong CRS được phân loại theo tiêu chuẩn OWASP để có
thể bảo vệ máy chủ web theo từng loại tấn công. Các rule này hoạt động tốt với
phiên bản ModSecurity 2.5 trở lên.

Hà Nội, ngày tháng năm 2022

XÁC NHẬN CỦA NGƯỜI SINH VIÊN THỰC HIỆN

HƯỚNG DẪN

Võ Trà My

37