Ký sự các vụ DDoS đến HVA - Phần 16

English | Vietnamese

Rules

Main Forum

Portal

Member Listing

Statistics

Search

Reading Room
[Register]

Login [ | https ]

Forum Index

Thảo luận bảo mật

Ký sự các vụ DDoS đến HVA - Phần 16

[Article] Ký sự các vụ DDoS đến HVA - Phần 16	24/06/2006 18:35:28 (+0700) \| #1 \| 802

prof
Moderator

Joined: 23/11/2004 01:08:55
Messages: 205
Offline

Sáng sớm 28/3/2005
Cả buổi chiều hôm qua đến khuya, tôi không hề động đến cái laptop. Lại chạy lăng xăng, lại nhậu lai rai và lại "nửa say, nửa tỉnh" (đúng là lễ Phục Sinh có khác smilie

). Mãi đến 2 giờ sáng ngày 28/3/2004, tôi nhận được một cú gọi từ công ty vì hệ thống máy chủ bị sự cố. Sự cố này khá đơn giản, tôi chỉ mất hơn 5 phút để tìm ra nguyên nhân và chỉnh sửa ngay. Sẵn tiện, tôi thử vào HVA forum xem sao.

Chậc, lại chậm rì thế này. Chắc chắn là chậm hơn hồi chiều hôm qua ngay lúc tôi ngồi tẳn mẳn với mớ log và packet dump. Tôi quyết định log nhanh vào HVA server để xem qua tình hình (mặc dầu lúc này não bộ của tôi muốn nghĩ ngơi). Tôi log vào HVA server khá dễ dàng, hơi chậm nhưng chỉ một lần là được. Tôi thấy server load không cao, số lượng process được tạo trên server quả nhiều hơn bình thường khá nhiều (và đây là chuyện hiển nhiên) nhưng request từ FireFox vẫn rất chậm. Tôi trầm ngâm "phải thực hiện việc chỉnh sửa lại firewall rule không thì kẹt". Ngay lúc log vào HVA server, tôi cũng nhận ra lão JAL đang ngồi chễm chệ với một console và có lẽ cũng đang dán chặt đôi mắt vào mớ thông tin từ apache log. Tôi định gởi cho lão một message nhưng lại thôi.

Cách khắc phục tình thế nhanh nhất lúc này là phải huy động đến chức năng SecFilterScanPOST On của mod_security (xem thông tin ở chú thích -41-) và chỉnh tạo lại một số rules cụ thể cho mod_security để cản mớ x-flash dai dẳng kia. Tôi nhẩm tính thật nhanh, 1) mở chức năng này của mod_security lên sau khi chỉnh vài cái rules cho nó 2) restart lại apache để ứng hiệu chức năng này 3) chỉnh lại firewall rule để mở rộng connection hơn (để tạo điều kiện cho người duyệt HVA có thể vào). Có lẽ tôi chỉ mất vài phút để thực hiện các bước trên. Nói là làm, tôi thực hiện ngay chuyện này và sau 3 phút, mọi chuyện đã hoàn tất. Tôi dùng FireFox để duyệt HVA forum thử lần nữa và thấy tình hình khả quan hơn nhiều.

Thật sự mà nói tôi không muốn lệ thuộc hoàn toàn vào chức năng SecFilterScanPOST để làm bức màn cản lọc vì lý do hết sức đơn giản: tôi không muốn hiệu năng của HVA server bị giảm thiểu. Một khi filter này được dùng, không có thứ gì trong mớ payload của các cú POST có thể tránh khỏi "bị" mod_security xét duyệt. Nói trên bình diện bảo mật thì đây là chuyện tốt. Tuy nhiên, cái giá phải trả, theo tôi, là quá đắt vì nó làm giảm hiệu năng của web service một cách đáng kể. Để ứng hiệu SecFilterScanPOST một cách tối ưu đòi hỏi một số thay đổi căn bản trên web application mà HVA đang dùng và đây là công tác lâu dài. Trong hoàn cảnh HVA đang bị "dội" dồn dập như thế này, trách nhiệm rà tìm và cản lọc của mod_security sẽ tạo ra hai vấn đề:

1) không thể có một cú x-flash POST nào có thể đi vào đến apache, cho nên việc tác động đến database query (để tạo load trên server) là chuyện sẽ không xảy ra. Đây là chuyện tốt.

2) bởi vì SecFilterScanPOST phải rà cản payload của từng cú POST, mọi request đến apache đều chậm lại (kể cả đối với người dùng hợp lệ). Đây là chuyện không tốt cho nên cần phải điều chỉnh và tối ưu hoá.

Đã 2 giờ rưỡi sáng. Tôi phải ngưng ở đây (dù ngày mai vẫn là ngày lễ "Happy Monday Easter"). Tôi xếp máy lại.

Trưa 28/3/2005
Trưa nay tôi có vài giờ để thong thả tiếp tục táy máy với HVA server. Tôi log vào HVA forum bằng FireFox và vào HVA server bằng SSH. Tình hình không khác gì sáng sớm nay khi tôi "dựng" SecFilterScanPOST lên. Hay nói một cách khác, server load không hề lên quá 2.0 và truy cập vẫn chậm hơn bình thường. Đây là chuyện hiển nhiên vì mọi cú request đều bị rà cản.

Tôi trở lại mớ firewall rule cần phải cải thiện (như đã đề cập trước đây). Có hai điểm khá nghiêm trọng mà tôi cần phải chỉnh sửa đó là: 1) thứ tự của các rule giới hạn connection và các rule cản lọc x-flash cụ thể 2) phân tích và ấn cụ thể "chiều dài" và tính chất của các gói tin được thẩm sát và cản lọc. Tôi không muốn đi sâu vào chi tiết cấu trúc các rules này vì tính bảo mật cũng như tính nhạy cảm của chúng nhưng tôi có thể chia xẻ với bạn những điểm trọng yếu về mặt nguyên tắc như sau:

- thứ tự của các rules: một chi tiết tôi đã không áp đặt một cách tỉ mỉ trước đây nhưng bây giờ đã trở thành một vấn đề hết sức rõ ràng và cần phải khắc phục. Trên nguyên tắc, thứ tự các firewall rule nên được sắp xếp để bảo đảm tối đa tính bảo mật và hiệu năng của nó. Trong trường hợp này, lưu thông đến cổng 80 là lưu thông chính đến HVA server. Cho nên, luật cho phép cũng như cản lọc các gói tin đến cổng 80 phải ở mức ưu tiên. Đây là điều tôi đã hình thành ngay từ đầu. Tuy nhiên, thứ tự của các luật giới hạn connection và luật cản lọc x-flash cụ thể đã không nằm đúng thứ tự dẫn đến tình trạng quá nhiều gói tin không được kiểm soát đúng mức khi cơn lũ "x-flash" ập vào.

- "chiều dài" các gói tin được kiểm soát để loại trừ x-flash: mặc dù đã ứng dụng "pattern matching" để cản lọc x-flash ở tầng thấp nhất (vì lý do hiệu năng), tôi chưa hoàn chỉnh các luật này để tối ưu hoá chúng. Đối với bình diện "pattern matching", việc thâu hẹp biên độ tìm kiếm "pattern" trong một packet là điều tối quan trọng bởi vì những pattern này phải được nhận diện và xử lý với tốc độ tối đa. Trong tay tôi đã có đầy đủ các thông tin biểu thị "chiều dài" nói chung của các cú "x-flash" kia, vấn đề còn lại cần phải giải quyết là "giúp" firewall thâu hẹp biên độ tìm kiếm -58-.

Tôi bắt tay vào thực hiện ngay phương án đã định. Sau mười lăm phút liệt kê sẵn thông tin và chỉnh sửa lại firewall, tôi hài lòng với những gì đã được hình thành. Khởi động lại firewall, tôi náo nức chờ xem kết quả thế nào. Mở một cái "tail" để theo dõi diễn biến trên syslog, thôi không hề thấy bất cứ thông điệp nào thuộc dạng Packet too big to attempt sublinear string search như đã dẫn trước đây. Một dấu hiệu tốt đầu tiên! Kế tiếp, tôi theo dõi server load bằng tiện ích top và thấy server load hạ xuống đáng kể. Dấu hiệu đáng mừng tiếp theo!

Tôi mở FireFox ra và thử duyệt HVA forum. Tình hình đã khá hơn rất nhiều. Tuy nhiên, chắc chắn vẫn còn dăm ba tiểu tiết có thể nắn sửa để cải thiện hơn nữa. Tôi điều chỉnh thêm vài chi tiết trên firewall và apache, xem xét lại một số tcp settings ở kernel level rồi restart lại apache. Thêm mười lăm phút trôi qua, lúc này tốc độ duyệt HVA forum gần như đã trở lại mức bình thường (được xác thực bằng load stat của forum) mặc dù cơn lũ x-flash vẫn đổ vào đều đặn. Tôi hài lòng với hơn một giờ đồng hồ táy máy với HVA server.

Có lẽ bạn vẫn còn thắc mắc việc tôi đề cập trước đây: "Tôi tìm ra không chỉ một mà là hai điểm hở khiến cho các cú x-flash có thể vuột qua hàng phòng thủ nếu như số lượng x-flash đạt tới mức dồn dập nào đó và nếu như apache đã cho phép "keep-alive". Thực trạng lúc này đều thoả mãn cả hai điểm nếu như ở trên". Điểm lại những chi tiết tôi vừa trình bày ở trên, bạn hẳn thấy firewall không hoàn toàn hiệu xuất và đã được chỉnh sửa. Lý do trọng yếu cho tính "thiếu hiệu xuất" này ở chỗ "pattern matching" ở IP layer không phải là một giải pháp vẹn toàn. Có thêm nó là một điều hay nhưng không thể trông cậy hoàn toàn ở nó. Lý do, có những packets quá lớn và modules dùng để kiểm tra "pattern" trong một packet từ chối kiểm tra. Giới hạn này có lý do hoàn toàn hợp lý khi từ chối không kiểm tra gói tin quá lớn: tính hiệu xuất. Nếu một luật đi theo để cản những gói tin quá lớn (vì không kiểm tra được) thì mức độ false positive (cản nhầm gói tin hợp lệ) quá cao. Các gói tin quá lớn này đã được phép đi qua khỏi hàng rào cản của firewall. Trong số này, có khá nhiều các gói chứa x-flash tấn công HVA. Đây chính là lý do server load của máy chủ HVA lên cao.

Lý do apache cho phép "keep-alive" là vì mục đích nâng cao hiệu xuất cho người dùng (hợp lệ). Trước đây tôi đã phân tích vấn đề này khá chi tiết, nếu thích, bạn nên đọc lại các bài trước đây. Tuy nhiên "keep-alive" là con dao hai lưỡi bởi vì đối với người dùng hợp lệ, nó cho phép dùng socket connection đang có để tiếp tục đẩy thông tin đi thay vì phải mở ra nhiều socket làm tốn tài nguyên và tạo truy cập chậm. Đối với các dụng đích "thiếu trong sáng" thì việc dùng socket connection đang có để tiếp tục đẩy thông tin mang tính phá hoại thì độ hư hoại đến máy chủ khó mà lường được. "Keep-alive" trên bình diện IP đơn giản là một tcp/ip stream chỉ có 1 lần "3way handshake" xảy ra, sau đó thông tin thông thường được đưa đi xuyên qua các cú ACK-PSH (acknowledge và push). "keep-alive" trên bình diện application (trên tầng apache chẳng hạn) có nghĩa là nhiều cú POST đi xuyên qua một connect đã hình thành. Hẳn bạn đã nhận thấy "2 điểm hở" rồi chứ?

Bạn có thể hỏi "tại sao không ra lệnh cho iptables tìm và cản những gói ACK-PSH có chứa thông tin x-flash? Tôi sẽ trả lời: A very smart question! nếu bạn hỏi tôi câu này. Tất nhiên là thế, tất nhiên là phải ra lệnh cho iptables "tìm và loại bỏ" những gói ACK-PSH "đen tối" kia nhưng, câu hỏi được đặt ra: kiểm soát "pattern matching" cho mọi gói ACK-PSH sao?. Được thôi! tuy nhiên vấn đề hiệu xuất sẽ trở thành chuyện đau đầu ở đây. Hơn nữa, không phải gói ACK-PSH nào cũng dài tương tự nhau, không phải các gói ACK-PSH lúc nào cũng trọn vẹn mà chúng có thể được tách nhỏ ra (xem khái niệm fragmentation trong chú thích -59-). Điều này dẫn tới vấn đề gì? chắc chắn sẽ có những gói tin "đen tối" đi vuộc qua khỏi hàng rào cản của firewall. Tuy nhiên, nếu cứ đưa ra mục tiêu cản được 2/3 số lượng các gói tin "đen" kia và để dành 1/3 cho SecFilterScanPOST lo liệu xem ra có thể chấp nhận được chăng? Hãy thử làm một bài toán nhỏ như sau:

Cho đến 12 giờ trưa ngày 28/3/2004 (giờ máy chủ), đã có gần 5 triệu rưỡi cú POST đi vào (dựa trên thông tin snort thông báo). Cứ làm tròn thành 5 triệu cú và cứ cho 9/10 số lượng này là các cú ACK-PSH hoàn chỉnh, 1/10 còn lại là các cú ACK-PSH bị tách nhỏ ra và iptables không kiểm soát được. Nếu, iptables có thể kiểm soát 2/3 của 9/10 tổng số 6 triệu cú POST kia thì:

9/10 của 5 triệu POST = 4 triệu rưỡi
2/3 của 4,500,000 = 3 triệu.
số còn lại để mod_security lo: 1 triệu rưỡi

Ở tình trạng này, tất nhiên sẽ không còn tình trạng mỗi cú x-flash tạo ra ít nhất 4 queries trên database server. Tuy nhiên, ảnh hưởng đến tài nguyên của máy chủ nằm ở đâu? Tất nhiên là ở socket level. Hãy thử phân tích qua vấn đề này xem sao.

a) Nếu iptables cản 3 triệu gói ACK-PSH có chứa payload của POST thì có những chuyện như sau xảy ra:
- giai đoạn "3-way handshake" giữa nguồn gởi x-flash và firewall đã xảy ra một cách hợp lệ.
- gói tin ACK-PSH tiếp theo đi từ nguồn x-flash sẽ bị cản nếu nó thuộc dạng x-flash. Nếu gói tin này gói gọn cú POST mà không được tách ra thành nhiều gói nhỏ (như đã đề cập với khái niệm fragmentation ở trên) thì trọn bộ xuất truy cập của cú x-flash này kết thúc tại đây. Những gói tin đi theo sau (nếu có) sẽ bị liệt vào dạng "INVALID STATE" và sẽ tiếp tục bị cản vì đối với firewall, chúng chẳng thuộc một "state" hợp lệ nào.
- nếu gói ACK-PSH này là phần thứ nhất của nhiều gói chia nhỏ ra thì có hai chuyện xảy ra: 1) nếu header của gói tin này có bất cứ thông tin gì dùng để nhận diện nó là x-flash, nó sẽ bị cản và trạng thái xử lý sẽ y hệt như trên. 2) nếu header của gói tin này không có bất cứ thông tin nào để nhận diện nó là x-flash, payload của nó sẽ được kiểm tra. Nếu trong payload có bất cứ thông tin nào để nhận diện nó mang tính chất một gói x-flash, nó sẽ bị cản như trên, nếu không, nó sẽ được đi vào như một gói tin hợp lệ.

False positive trong phương thức này? tất nhiên là có bởi vì không hệ thống nào lại không có false positive. Nếu có false positive, người dùng hợp lệ phải "refresh" lại trình duyệt của họ để tạo một xuất truy cập mới. False postive rate? hy vọng là không cao vì những cú x-flash có những tính chất rất đặc thù so với những gói tin hợp lệ. Vậy, nếu x-flash hoặc các dạng DoS khác có những "pattern" mới thì sao? Phương thức dùng "matching pattern" ứng dụng regex (xem chú thích -42-) nên một số biến thiên nào đó sẽ nằm trong khoảng kiểm soát của các firewall cho phương thức cụ thể này. Tuy nhiên, nếu các gói tin có payload hoàn toàn mới thì e rằng hệ thống phòng thủ không còn ứng hiệu ở mức tối đa. Trong tình trạng này, cơ phận duy nhất còn tác dụng là phần điều tác giới hạn connection.

Vậy ảnh hưởng về mặt tài nguyên của những trường hợp trên ở đâu? Bất cứ gói tin nào mang tính hợp lệ để có thể hoàn tất "3-way handshake", chúng đều chiếm một lượng tài nguyên nhất định cho bước này (ở socket level). Tuy nhiên, trạng thái SYN chuyển sang các flags sau đó (như ACK, ASK-PSH...) rất nhanh nên SYN không bị chiếm quá lâu (ngoại trừ bị syn flood một cách thực sự). Tuy nhiên, dạng syn-flood cổ điển đến nay đã không còn tác dụng mấy đến những kernel mới của linux và *bsd. Tài nguyên bị "phí" nhiều nhất ở giai đoạn socket được đóng (vì 1 trong hai đầu truy cập kết thúc), chuyển đến trạng thái FIN-WAIT-1, FIN-WAIT-2, TIME-WAIT. Trong trường hợp firewall can thiệp vào việc kết thúc một cuộc truy cập thì tình hình có khác nếu xử dụng target khác nhau (DROP hay REJECT và REJECT với chọn lựa nào đó).

- nếu firewall cản gói tin bằng phương thức DROP, gói tin vi phạm bị hủy bỏ một cách yên lặng, như thể không có chuyện gì xảy ra. Trên mức độ socket, không hề có gói RST (reset) hay gói FIN (finish) gởi từ máy chủ về lại nguồn của gói tin vi phạm để "thông báo" chuyện gì đã xảy ra. Với tình trạng này, nguồn gởi gói tin vi phạm sẽ bị vướng vào trường hợp bị hàng đống các "dead sockets" vì gói ACK-PSH gởi đi không hề có gói ACK từ máy chủ (bị tấn công) hồi đáp. Nếu máy nguồn gởi càng nhanh, càng dồn dập thì số lượng socket ở tình trạng "TIME-WAIT" sẽ tồn tại rất nhiều trên máy và đến một lúc nào đó, chính nó sẽ bị cạn kiệt tài nguyên (memory để giữ socket ở tình trạng "TIME-WAIT" đến khi timeout).

- nếu firewall cản gói tin bằng phương pháp REJECT, gói tin vi phạm này bị hủy nhưng đồng thời firewall sẽ gởi trả một thông điệp (tùy chọn lựa REJECT nào đó). Thông thường, một gói FIN hoặc một gói RST (tùy ứng dụng) sẽ được gởi trả về máy nguồn của gói tin vi phạm. Với tình trạng này, chính firewall phải tốn tài nguyên để tạo gói tin hồi đáp và máy nguồn của gói tin vi phạm được "thoát" khỏi tình trạng bị "dead socket". Cách này có vẻ "nice" đối với nguồn tấn công nhưng tùy vào giao thức mà dùng. Có những giao thức cần phải dùng REJECT để giải phóng tài nguyên cho cả hai đầu.

Vậy, khi iptables cản 3 triệu gói ACK-PSH vi phạm kia bằng phương thức DROP, sẽ có chừng 3 triệu "dead sockets" nằm đâu đó trên các máy dùng để tấn công. 3 triệu "dead socket" thì có gì ghê gớm? có đó! Cứ một dead socket chiếm 1.5Kb real memory (không phải swap). Cần bao lâu và cần bao nhiêu "dead socket" để máy này cạn kiệt memory nếu mỗi "dead socket" chiếm 1.5Kb và cần 180 giây để được hủy bỏ hoàn toàn (1.5Kb này sẽ được tái dụng)? Đây chỉ là khái niệm thuần toán, thực tế hẳn phải đa dạng hơn rất nhiều vì không chỉ 1 máy dùng để tấn công.

b) Nếu mod_security được dùng như một dạng firewall ở tầng application và phối hợp với firewall ở tầng IP thì có những chuyện sau xảy ra:
- các request thoả mãn "3-way handshake" ở ngay firewall (tầng IP) sẽ được tiếp tục xử lý. Nếu chúng (các gói ACK-PSH) là những gói vi phạm thì sẽ bị firewall ở tầng này cản lọc như đã phân tích ở trên.
- nếu các gói ACK-PSH được tách ra và firewall ở tầng IP không kịp xử lý chúng, khi lên đến mod_security (tầng application), chúng sẽ bị khám xét và cản lọc. Biên độ cản lọc trên mod_security rất rộng bởi vì nó đảm nhiệm việc khám xét trên request URL, trên các arguments được chuyển vào trong request (thường dùng cho các cú GET) và nhất là trong payload của các cú POST.

Độ cản lọc trên mod_security có thể rất chi tiết dựa trên một "pattern" cụ thể hoặc rất rộng nếu ứng dụng regex đúng mức. Khả năng các request "xấu" đi xuyên qua mod_security để tạo các queries trên database cực kỳ thấp (nếu chuẩn bị cẩn thận các rules cho mod_security). Tuy nhiên, phản ứng phụ trên tầng firewall này là một vấn đề không nhỏ. mod_security không DROP gói tin một cách lặng lẽ như firewall ở tầng IP mà nó kết thúc request nào mang tính vi phạm theo đúng quy cách ứng dụng của giao thức TCP.

Như bạn đã biết, giao thức TCP cần 3 bước để thiết lập một cuộc truy cập (3-way handshake) nhưng lại cần đến 4 bước để kết thúc một cuộc truy cập -60-. mod_security trước tiên gởi trả lại nguồn vi phạm một thông điệp (hay một HTTP error status tùy theo cấu hình ứng dụng), sau đó nó mới gởi một cú FIN (finish) ngược lại nguồn vi phạm và đợi đầu này gởi về một cú FIN-ACK, tiếp theo đó mod_security gởi một cú FIN-ACK và phải tiếp tục đợi đầu bên kia gởi trả một cú ACK trước khi cuộc truy cập này hoàn toàn đóng. Trên bình diện hoạt động bình thường, các bước kết thúc này chẳng có gì đáng phải bàn vì chúng cần thiết để bảo đảm một cuộc truy cập được kết thúc một cách trơn tru, tránh tình trạng time-out, tránh cơ hội bị "dead socket"... Tuy nhiên, trong tình huống một máy đang bị DoS dồn dập các bước kết thúc đúng quy cách này càng tạo thêm sức ép cho máy chủ. Cứ mỗi cú x-flash đi vào, trước tiên máy chủ phải tốn tài nguyên cho "3-way handshake", sau đó tốn tài nguyên để dò tìm nội dung vi phạm của gói tin. Để kết liễu nó, máy chủ cần thêm 2 gói tin cuối cùng cộng với thời gian chờ đợi đầu bên kia hồi báo. Trong lúc mod_security phải hoàn tất xử lý một cuộc truy cập vi phạm đúng quy cách thế này thì có lẽ đã có vài chục, vài trăm hoặc vài ngàn cuộc truy cập khác đang đứng chờ được xử lý. Có lẽ bạn đã hình dung ra hoàn cảnh của server thế nào nếu đang bị tấn công dồn dập. mod_security sẽ càng ngày càng ngập ngụa với công việc, request càng ngày càng dồn ứ. Chuyện gì xảy ra nếu tình trạng này xảy ra?

- người dùng hợp lệ dùng trình duyệt sẽ thấy vận tốc duyệt càng ngày càng chậm.

- trên máy chủ càng ngày số socket ở tình trạng FIN-WAIT-1, FIN-WAIT-2, TIME-WAIT càng nhiều.

Cho dù các cú DoS không đi vào tới database để tạo server load, chính máy chủ sẽ đi đến chỗ cạn kiệt vì hết memory do phải tuân thủ các bước "đóng" cuộc truy cập như đã nói ở trên. Thử phân tích sơ qua với số liệu 1 triệu rưỡi cú x-flash trong nửa ngày mà mod_security phải cản và giải quyết xem:

1,500,000 / 12 / 60 / 60 = 35 cú POST mỗi giây

Mỗi cú POST được mod_security triệt tiêu nhưng phải đi qua giai đọan FIN-WAIT-1, FIN-WAIT-2, TIME-WAIT. Theo mặc định trên Linux kernel, mỗi FIN-WAIT-1 sẽ tồn tại 60 giây và chiếm 1.5Kb real memory trong lúc nó còn tồn tại:

35 x 1.5Kb = 52.5Kb mỗi giây

Quá ít? Hãy xem thử trong 60 (trước khi một socket chuyển từ dạng FIN-WAIT-1 sang FIN-WAIT-2):

52.5 x 60 = 3,150kb

Sang đến giây thứ 61 mới trả lại 52.5K memory nếu cơ chế này hoạt động nhịp nhàng và không có sự cố:

3,150 - 52.5 = 3,097.5Kb

Giả sử chỉ phó mặc cho mod_security lo hoàn toàn các cú x-flash trong trường hợp này thì:

5,000,000 / 12 / 60 / 60 = 116 cú POST mỗi giây
116 x 1.5Kb = 174Kb
174Kb x 60 = 10,440Kb

Mất toi 10Mb RAM một cách dễ dàng!

Nếu kẻ tấn công chọn phương pháp gọn nhẹ hơn (như GET chẳng hạn) và gia tăng từ 116 cú POST thành vài ngàn cú GET mỗi giây thì chuyện gì sẽ xảy ra? Đó là chưa kể trường hợp kernel phải lo điều tác với số "orphans sockets". Cứ mỗi "orphan" chiếm 64Kb real memery trước khi chúng được mang ra khỏi hàng đợi để được giải quyết. Điều tệ hại hơn nữa là các request hợp lệ phải đứng chờ lượt mình được mod_security "xét" và hiệu xuất giảm sút đáng kể. Phần tài nguyên hao hụt (khó thấy) nhất là phần logging xảy ra bên dưới. Mỗi trường hợp vi phạm (26 trường hợp mỗi giây) đều lưu lại ít nhất là 25Kb log và cơ chế read-write (cho disk I/O) bận rộn chưa từng có.

Ý tôi không phải "chê" mod_security là tệ nhưng thật sự nó được thiết kế để chống những loại tấn công đơn lẽ như xss, sql injection, buffer overflow... dù những loại tấn công này hoàn toàn tự động hoá (bằng scripting chẳng hạn) cũng không có trường độ và cường độ tương tự như DDoS. Bởi vậy, việc điều chỉnh và chọn lựa phản ứng cho mod_security trong hoàn cảnh này là điểm tối quan trọng nếu như quyết định dùng nó như một application firewall.

Ngay lúc tôi đang còn dông dài với bài viết này thì HVA đã trở lại bình thường (dù vẫn bị "gõ" đều đặn). Bạn tò mò muốn biết những gì đã xảy ra sau đó? Mời bạn xem phần tiếp theo.

Chú thích:
-58- dành cho những bạn thích đào sâu: đối với iptables, cách đơn giản nhất là dùng match length (-m length) để xác định độ dài của các packets cần được kiểm tra. Ngoài ra còn có nhiều kỹ thuật phức tạp hơn và chính xác hơn là phối hợp với một số netfilter's helpers và kỹ thuật "nắn" gói tin (traffic shaping) để kiểm soát các gói tin hiệu quả hơn. Đây chỉ là một gợi ý tổng quát.

-59- thuật ngữ mạng và bảo mật gọi là "packet fragmentation". Một gói tin có thể quá lớn để khít vào một MTU (Maximum Transmission Unit). Giả sử Ethernet có MTU là 1500 và gói tin có độ dài là 1550 chẳng hạn, nó phải được "tách" ra để tiếp tục gởi phần còn lại trên gói tin kế tiếp. Xem thêm chi tiết "packet fragmentation" trong bất cứ tài liệu nào nói về tcp/ip. Đối với iptables, các fragmented packets đều được nhập lại ở dạng hoàn chỉnh trước khi được kiểm soát. Tuy nhiên, với tinh thần vấn đề đang phân tích ở đây, sau khi các gói tin được nhập lại ở dạng hoàn chỉnh có thể trở nên quá lớn và đã bị từ chối kiểm tra "pattern".

-60- Nên tham khảo một cuốn sách nói về các giao thức trong tcp/ip suite. Tôi cho rằng bộ tcp/ip illustrated 1,2,3 của Richard Steven là một bộ sách không thể thiếu cho những ai muốn đào sâu về giao thức mạng.

Các bạn có thể theo dõi tiếp phần 17 tại http://hvaonline.net/hvaonline/posts/list/506.html

Go to:

Users currently in here
1 Anonymous