Tối 01/11:
Ăn tối xong, sau khi ra một lô toán cho hai thằng nhóc (con trai tôi) để chúng bớt quấy rầy, tôi pha một ấm trà và mở laptop lên.

Lúc này tôi có đủ thời gian để cẩn thận phân tích từng tcp stream -48- khởi tạo từ mỗi IP có chứa thông tin "x-flash-client" để phân tích các biến thái của chúng (nếu có). Hãy xem thử đoạn HTTP header đã được decode từ một chùm HEX thuộc một tcp stream:
Code:


Chúng ta có thể thấy được những gì hiển nhiên ở đây? Đúng rồi:
- "x-flash-version"
- GET methods
- Connection: Keep-Alive
- Cache-control: bypass
- cùng GET các static images

Điều tôi phải tự gật gù cũng như nhếch mép cười khi đi xuyên qua đoạn packet dump bé tí tẹo đó là: chủ định của kẻ tấn công. Tôi muốn tập trung phân tích tính chất loại tấn công này trên tầng web service vì chúng ta vừa đi xuyên qua một số phân tích khá sâu ở tầng này trong các bài trước.

So với lần trước (dùng POST), lần này anh chàng đã tính toán kỹ lưỡng hơn, có cân nhắc hơn và nhất là có sáng tạo hơn. Nếu quả thật anh chàng chịu khó đọc RFC để thay đổi dạng tấn công thì đây là điều đáng mừng (và cũng đáng buồn). Đáng mừng vì chính bản thân anh ta thâu gặt được kiến thức về giao thức HTTP sâu sắc hơn, đáng buồn vì anh chàng dùng năng lực và trí thông minh của mình cho một mục đích không lấy làm hữu dụng. Tại sao tôi tự gật gù và nhếch mép cười?

- thứ nhất, suýt nữa tôi bị cái mớ "x-flash" header kia đánh lạc hướng. Trong một chuỗi có vài trăm tcp stream, các stream có header là "x-flash" chỉ chiếm chừng 1/2 tổng số, 1/2 còn lại có y hệt tính chất nhưng không hề có vướng một mảy "x-flash" trong suốt tcp stream. Điều này cho thấy, kẻ tấn công không đơn thuần "nhắm mắt phang đại" đến HVA mà có theo dõi và định hướng rõ ràng. Nói về mặt phòng thủ thì các HTTP header có mang "x-flash" hay không mang HTTP header "x-flash" dù có vuột khỏi snort cũng vẫn bị giới hạn connection limit của firewall kiềm chế tối đa. Các gói tin này khi lên đến application layer và nếu có mang "x-flash" header, khi đụng phải mod_security vẫn bị rụng lả tả. Tuy nhiên, một nửa các tcp stream khác có y hệt tính chất nhưng không mang "x-flash" header cụ thể thì không còn bị snort và mod_security kiềm chế nữa, chỉ có connection limit trên firewall là còn tác dụng. Nếu tôi chủ quan và phiến diện thì đã để vuột một số lượng đáng kể các gói tin không có x-flash header đi vào mà không có biện pháp thích ứng ngay lập tức.

- thứ nhì, POST method được dùng trước đây có cái lợi là nó tạo ảnh hưởng trực tiếp và nặng nề đến web server, nhưng cũng có cái hại là nó quá cồng kềnh vì phải dùng nhiều gói "continuation" để hoàn tất một lượt gởi. Điểm hạn chế lớn nhất của POST payload dài dằng dặc là sự chậm trễ trong việc chuyển tải các gói tin được xẻ nhỏ ra để hoàn tất lượt gởi. Dụng ý dùng GET method hiển nhiên là để khắc phục "cái hại" trên: hoàn tất mỗi cú gởi càng nhanh càng tốt. Bạn có thể thắc mắc "sao vậy?". Theo tôi, đây là một dạng "flood" để chiếm sockets trên máy chủ, nó khác với SYN FLOOD kiểu truyền thống là nó có đủ "bộ lệ" 3-way hand shakes, ACK-PSH để đẩy gói tin đi đến đích thật nhanh và rồi nó kết thúc bằng FIN. Với lối gởi tin này, firewall không thể xếp hạng nó là SYN-FLOOD kiểu truyền thống -49- để cản nó mà phải mở rộng cửa để đón nó vào như một request hoàn toàn hợp lệ.

- thứ ba, nếu anh chàng tấn công này đã quyết định GET static image mà không "kiện toàn" một chi tiết hết sức quan trọng thì cuộc tấn công của anh ta sẽ đổ vỡ: ra lệnh proxy server lấy bản nguyên thuỷ từ HVA server. Lý do rất đơn giản: nếu anh ta gởi 1000 cái GET trong một giây mà không lo đến phương diện cache thì sao? thì proxy server nào đó đứng trước máy con gởi GET request kia sẽ dùng thông tin có sẵn trong cache để trả lời (thay vì đi đến tận HVA server để lấy một loạt .gif, .swf images nguyên thủy). Nếu chuyện này xảy ra thì sao? Thì hiển nhiên là anh ta đang tự DoS cái proxy server mà anh ta dùng. Theo tôi, tấn công theo dạng này mà không có suy tư và phân tích thì cơ hội bị vướng vào lỗi này rất cao.

Tiếc thay (và cũng may thay cho HVA), directive Cache-Control: bypass-client=xxx.xxx.xxx.xxx được dùng ở đây hoàn toàn vô tác dụng với ý định cần phải bypass cache server. Theo RFC của giao thức HTTP -50-, directive cache-control không hề có chọn lựa "bypass-client". Theo tôi, đây là một dạng ứng dụng non-standard (phi tiêu chuẩn) nào đó cho HTTP header option. Nếu quả thật tác giả của cuộc tấn công này muốn "by pass" các proxy server trên đường đi từ máy của anh ta đến HVA server, anh ta phải dùng directive Cache-Control: no-cache đúng theo ứng dụng cho HTTP/1.1 như trong ví dụ trên. Nếu không, các request tiếp theo cũng cùng đòi hỏi bấy nhiêu static images sẽ "bị" proxy server nào đứng giữa máy anh chàng và HVA server cung cấp cho "bản sao" đã được lưu giữ trong cache của proxy server. Có thể kẻ tấn công HVA đã tính sai? có thể anh chàng cũng không hề tính toán? cũng có thể anh chàng còn "cao cờ" hơn một bậc?

Nếu bạn quay ngược lại phần thứ nhì của bài viết này, bạn sẽ thấy directive cache-control hơi khác hơn lúc này ở chỗ nó có ấn định no-cache và đây là điểm quan trọng nếu mục tiêu là để "đẩy" dữ liệu đến máy chủ HVA. Điểm cao cờ hơn một bậc ở đây là anh chàng "mượn tay" (các) proxy server để tạo socket connection trên HVA server. Cho dù proxy server sẽ cung cấp bản "cache" nó có sẵn nhưng theo đúng thuật toán caching thông dụng (common caching algorithm) thì proxy server vẫn phải liên hệ với server nguyên thủy (HVA server trong trường hợp này) để thử so sánh bản đã cache và bản hiện có trên HVA server xem chúng có khác nhau không. Nếu chúng khác nhau, proxy server tải bản mới nhất về, cung cấp bản mới nhất này cho client nào request (máy của tay tấn công HVA trong trường hợp này) và lưu bản mới nhất này trong cache. Vậy "cao cờ" ở đây là sao? là ở chỗ anh chàng chỉ muốn mở socket dồn dập trên HVA server, dữ liệu thật sự sẽ được proxy server cung cấp (từ bản đã cache) và những request đến HVA server xuyên qua proxy server chỉ là các cú connection nhanh gọn. Gởi request từ máy anh chàng đến proxy server "tiện" và "gần" hơn là gởi trực tiếp đến HVA server (xa và chậm hơn). Anh chàng "sai khiến" proxy server đi đoạn đường xa và lo liệu mớ request thật sự. Nếu quả thật đây là dụng ý của kẻ DoS HVA thì tay này đã tính toán và suy nghĩ rất kỹ lưỡng.

- thứ tư, "keep alive" connection -51-. Theo tôi, anh chàng ứng dụng cái "keep alive" này vừa tác dụng, vừa phản tác dụng. Tác dụng ở chỗ nó giữ nguyên connection hiện có và tiếp tục "đẩy" các GET request để tiếp tục "lấy" các static images qua connection này. Làm như thế thì mỗi cú truy cập để hoàn tất chóng vánh vì nó không đợi cho web server mở thêm connection mới để "đẩy" các static images khác đi đến server. Phản tác dụng ở chỗ, vì nó "keep alive" nên rất ít socket được mở thêm. Dụng đích dùng GET như tôi suy đoán ở trên là tạo một dạng FLOOD để chiếm sockets nhưng anh chàng lại "ra lệnh" cho nó "đẩy" 6 cái GET (ở trên) xuyên qua một socket thì còn gì là "chiếm socket"?. Cho nên, mục đích "chiếm socket" này bị vô tình giới hạn một cách đáng kể, nó chỉ còn phụ thuộc và tốc độ và mật độ gởi GET để tạo ảnh hưởng đến HVA server.

- thứ năm, mọi GET request để lấy các static images như gif files, flash file... đều được thiết kế một cách chính xác và tỉ mỉ đường dẫn. Lý do tại sao đường dẫn lại quan trọng đến thế? bởi vì như đã phân tích ở trên, dụng đích của kẻ tấn công là "đẩy" các GET request này đến HVA server càng nhanh càng tốt. Nếu một trong các đường dẫn đến static image bị sai thì sẽ bị web server báo lỗi ngược lại. Mỗi cú "báo lỗi" này là một cú "oánh ngược" lại nguồn gởi và làm chậm cuộc tấn công. Càng bị báo lỗi nhiều, cuộc tấn công càng mất tác dụng và máy con gởi request càng dồn dập sẽ càng bị "flood" ngược lại. Ngoại trừ nguồn IP dùng để gởi đi là các "spoofed IP" thì không kể vì các đợt báo lỗi sẽ đi về các spoofed IP thay vì về IP của máy gởi request nguyên thủy.

Vậy, với năm điểm làm tôi "gật gù" cũng như "nhếch mép" ở trên, điểm nào có vẻ tạo ảnh hưởng lớn nhất đến HVA server? Câu trả lời quá hiển nhiên bạn nhỉ? Đó là các gói tin mang y hệt tính chất các cú GET "x-flash" nhưng lại hoàn toàn không mang "x-flash" header. Có hai giả thuyết được đặt ra:
1) tay tấn công HVA thiết lập một nửa số lượng GET có "x-flash" header và số còn lại không có "x-flash" header.
2) tay tấn công HVA thiết lập 100% số lượng GET có "x-flash" header nhưng một nửa số này khi đi xuyên qua một vài proxy server nào đó, chúng bị "lột" mất cái header (như dạng anonymous proxy -52-).

Dù cố tình hay ngẫu nhiên, những cú GET đi vào và không được nhận diện như các "x-flash" đã tạo một số ảnh hưởng đáng kể đến máy chủ HVA. Hãy thử phân tích các điểm cốt lõi đã tạo ảnh hưởng.

- giả sử có 1000 cú không mang "x-flash" header đi đến HVA server trong một giây. Sẽ có bao nhiêu cú đi lọt vào? Cái này còn tùy vào một yếu tố chính là các cú GET đến HVA server từ 1 hay nhiều IP address khác nhau.

a. Nếu 1000 cú này đi đến từ một IP thì chỉ có 6 cú có thể đi vào theo nguyên tắc connection limit ở trên. Tôi dùng chữ "có thể" ở đây vì có thể ngay lúc các cú GET được gởi đi cũng có vài người nào đó cũng đang truy cập HVA và cũng dùng chung một proxy server nhưng những người này gởi request trước một tí. Nếu vậy, số phận của 994 cú còn lại ra sao? Chúng có thể được retry, chúng có thể bị timeout và bị huỷ, chúng cũng có thể đi vào đến HVA server. Cái này cũng còn phụ thuộc nhiều yếu tố nhưng yếu tố quan trọng nhất là HVA server tiếp nhận bao nhiêu cú retries, bao nhiêu cú được tiếp nhận và chờ phiên mình. Những chi tiết này phải được điều chỉnh ở kernel level trên firewall của HVA và giá trị thế nào thì... không thể công bố được; bạn chỉ cần nắm khái niệm là thế. Hơn nữa, những giá trị này được điều chỉnh theo nguyên tắc random (ngẫu nhiên) nên cũng khó mà xác định được chính xác để công bố.

b. Nếu 1000 cú này đi đến từ nhiều IP thì số lượng GET đi vào được HVA server sẽ gia tăng dựa trên nguyên tắc connection limit theo IP. Cứ cho 1 IP được dùng 6 connections trong một lúc, vậy, nếu anh chàng này dùng 20 cái proxy servers (20 IP addresses) chẳng hạn thì sao?
20 x 6 = 120 connections
nhưng vì các GET request "ấn định" dùng keep-alive nên mỗi tcp stream chỉ dùng một socket. Bởi thế, 120 connections chiếm 120 sockets.

Về phía máy chủ HVA, để có thể bảo hoà (saturate) socket pool của HVA server nếu như máy chủ HVA đã được ấn định mở và tiếp nhận 32000 sockets (chẳng hạn) thì anh chàng "x-flash" sẽ cần bao nhiêu proxy server?
32000 / 6 = 5333 proxy
Cha chả, nếu anh chàng huy động được trên năm ngàn cái proxy server thì HVA bị nguy to. Tuy nhiên, ngược lại máy con tạo ra dạng DoS này cũng không mấy "êm ấm" nếu số lượng request khổng lồ này được gởi đi và số lượng hồi báo quay trở về chính máy tạo request. Tôi tin chắc máy này sẽ "chết" đứ đừ để tiếp nhận hồi báo. Thật sự hiện tượng hồi báo này hoàn toàn hợp lệ và hiển nhiên: cần nhiều request thì nhận nhiều hồi báo. Nếu đây là một dạng tấn công mượn tay người dùng trình duyệt để gởi GET thì chắc chắn nó sẽ làm chậm hàng loạt người dùng vì số lượng hồi báo.

Tôi đưa ra các con số trên chỉ để minh hoạ dạng DoS GET này cần phải có tầm cỡ nào để có thể dung hại đến HVA server. Thực tế con số sockets HVA tiếp nhận là bao nhiêu thì rất tiếc... không thể trình bày được ở đây. Thực tế để có thể huy động trên 5000 proxy server cũng là điều... không tưởng và nhất là phải huy động các proxy server có số hop ngắn nhất để đi đến HVA server. Nếu không, mục đích flood sockets không còn mấy hiệu quả.

Bạn có thể thắc mắc về giải pháp kiềm chế các cú "GET" mới mẻ này. Như đã phân tích, có hai nhóm "GET" khác nhau đi vào HVA server:
- đối với nhóm GET có x-flash header, tôi chỉ "thắt chặt" bằng cách thêm vào vài cái signatures cho snort, tương tự như sau:
Code:


Bạn thử "decode" hai signatures trên để xem nó làm cái gì cho nhộn , tôi sẽ không mở rộng thêm về snort signature ở đây.

- đối với nhóm GET không có "x-flash" header, thật ra không cần phải thay đổi gì thêm cũng không ảnh hưởng nặng nề như POST đến HVA server vì các cú GET này chỉ lấy static images và không hề "đụng" mảy may đến database query nên ảnh hưởng đáng kể là ảnh hưởng trên socket. Đối với web server, con số MaxRequestPerChild cần thay đổi để mỗi child process tiếp nhận nhiều request hơn bình thường (xem bài trước). Mục đích là để tránh trường hợp chúng bị hủy quá nhanh (vì có quá nhiều GET request đi vào) vì mỗi lần bị hủy, mother process phải tạo thêm child process và làm gia tăng server load nếu chúng được tạo quá thường xuyên. Đối với kernel socket, các giá trị như max_orphan, syn_back_log, timeout, tcp_mem, keepalive_time.... cần được điều chỉnh để gia tăng cơ hội nhận SYN và giải quyết SYN. Server load sẽ tăng nhưng đây là việc cần thiết để bảo toàn cơ hội truy cập cho người dùng hợp lệ (ở mức tối đa tài nguyên cho phép). Ngoài các thay đổi này, tôi còn có thêm một giải pháp phòng bị nhưng tôi đã không ứng động nó mà chỉ cài sẵn và để yên đó cho nên miễn bàn thêm giải pháp phòng bị này.

Trong 6 cái GET của ví dụ trên có một cái GET rất đặc biệt:
Code:


Trong cùng một tcp stream, đột nhiên xuất hiện "anh chàng" này. Nó chẳng GET static images như các cú GET kia mà lại GET một URI rất... kỳ quái: /forum/?&time=0.13435. Cú GET này thuộc một sequence tiếp nối trong cùng tcp stream nhưng nó lại forward cho máy con có IP là 203.210.194.254 và cũng cùng đi qua gateway có IP là 203.160.1.66. Bởi lẽ nó là một sequence thuộc một tcp stream hợp lệ (và được cho phép vào theo quy chế connection limit) nên cú GET này vẫn đụng đến web server. Chuyện hiển nhiên sẽ xảy ra tiếp theo đó là web server của HVA sẽ báo lỗi "không tìm thấy" vì cú GET này trỏ vào một URI không tồn tại. Cũng như các cú GET khác trong cùng tcp stream, cú GET này có dụng đích không gì khác ngoài việc tạo thêm socket trên HVA server.

Đi xuyên qua các tcp stream đang phân tích, tôi chỉ thấy lác đác chừng một tá các cú GET tương tự. Tôi đã không cho những cú GET này quan trọng nhưng đây là lần đầu tiên tôi phán đoán sai kể từ lúc bắt tay vào phân tích các dạng DoS trên HVA. Từ kết quả phán đoán sai, tôi đã không phòng thủ trước. Trong suốt vài ngày kế tiếp, HVA server bị tấn công chỉ với loại GET có URI "/forum/?&time" này. Tôi đã học bài học không bỏ qua bất cứ một chi tiết đáng ngờ nào vậy mà lần này tôi đã sai phạm nguyên tắc căn bản này để rồi vất vả trong mấy ngày tới.

Sự thể ra sao, mời bạn xem tiếp kỳ sau.

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

Chú thích:
-48- "tcp stream", bạn hẳn đã nắm được tcp stream là gì. Tuy nhiên, để tránh nhầm lẫn giữa nhiều khái niệm và thuật ngữ trong bài, tôi quyết định đưa thêm chú thích về "tcp stream" ở đây. tcp stream là một "xuất" giao tiếp giữa client và server. Nó bắt đầu bằng SYN request từ client và kết thúc bằng FIN cũng từ client nếu "xuất" giao tiếp này thực hiện đúng quy cách. "Xuất" giao tiếp này có thể chứa nhiều sequences mang các tcp flags khác nhau trong quá trình trao đổi giữa client và server và mỗi sequence từ mỗi phía (client hoặc server) là một "entry" của tcp stream.

-49- SYN FLOOD là một dạng denial of service rất phổ biến từ giữa đến cuối thập niên 90. Cho đến nay, thỉnh thoảng SYN FLOOD vẫn còn xuất hiện rải rác mặc dù các hệ điều hành, routers, firewall ngày nay đã nâng cao để loại trừ dạng DoS cổ điển này. Tổng quát mà nói, dạng SYN FLOOD "truyền thống" lợi dụng tính chất (và cũng có thể là điểm yếu) của giao thức TCP IPv4 để tấn công. Kẻ tấn công gởi hàng loạt SYN request đến máy chủ của nạn nhân nhưng sau khi nhận được SYN-ACK từ máy chủ, nó không bao giờ gởi về gói ACK để hoàn tất 3-way handshake. Điều này làm cho máy chủ không thể tiếp nhận thêm connection sau một khoảng thời gian ngắn vì connection queue của nó bị đầy ứ do chờ đợi gói ACK hồi đáp từ client. Trong trường hợp SYN FLOOD kéo dài, hệ thống sẽ bị cạn tài nguyên (bộ nhớ) vì phải huy động quá nhiều memory cho socket pool và connection queue.

-50- đọc thêm RFC 2068 và RFC 2616 trên website http://www.rfc.org nếu bạn muốn đi sâu vào chi tiết tính năng và tác dụng của các HTTP headers.

-51- Keep-alive connection theo đúng tiêu chuẩn đưa ra trong RFC là một phương tiện để biến tính "stateless" của giao thức HTTP trở nên hiệu ứng hơn. Đúng theo nguyên tắc, mỗi objects được request đến server và được trả về từ server đều cần phải có connection mới. Ví dụ, trên một trang có 10 bức hình gif, thông thường giữa trình duyệt và web server phải tạo ra 10 connection riêng biệt cho mỗi cú GET để lấy hình (vì mỗi bức hình có href (đường dẫn) riêng và đối với trình duyệt, chúng có URI khác nhau). Tuy nhiên, "keep-alive" đòi hỏi server và client giữ nguyên một connection đã hình thành từ đầu để tiếp tục chuyển gởi các gif files đi thay vì phải mở thêm connection mới. Làm thế này giúp giảm thiểu quy đoạn tạo thêm sockets cho các trang web lớn, có nhiều hình ảnh. Làm thế này cũng có cái hại là với một connection đã thiết lập, client có thể request hàng "tấn" dữ liệu và server phải ngoan ngoãn phục vụ không ngừng nghỉ (tương tự như tình trạng dùng teleport hoặc wget để "rút ruột" một trang web), dẫn đến tình trạng quá tải máy chủ nếu quá trình "rút ruột" này tác động trực tiếp đến các dịch vụ xung quanh web service.

Giá trị "keep-alive" nên được cân nhắc kỹ nếu muốn tối ưu hoá web server vì nó là con dao hai lưỡi.
- Nếu bạn cho phép mở nhiều socket trên server (không dùng quy chế connection limit nào đó) thì không nên dùng "keep-alive" vì nó tạo load theo mức cấp số đến server (vì nhiều sockets + nhiều keep-alive).

- Nếu bạn giới hạn sockets trên server (dùng quy chế connection limit nào đó) thì bạn có thể dùng "keep-alive" nhưng phải tính toán giá trị thời gian thích hợp để "keep-alive" tùy theo nội dung và độ lớn (chữ và hình ảnh) của mỗi trang.
Cách tối ưu hoá hay nhất là tính sao cho mỗi trang duyệt chỉ cần một socket và đủ thời gian "keep-alive" để trình duyệt tải về.

-52- Có hai khái niệm về "anonymous proxy":
- một dạng proxy khi client dùng nó để duyệt web sẽ được "lột" bỏ hết các header cá biệt của trình duyệt mà client (có / dùng) gởi đến proxy server. Các gói tin đi xuyên dạng proxy này sẽ không còn một đặc tính cá biệt nào cả ngoài những gì proxy trang bị cho nó.

- một khái niệm khác về anonymous proxy không thuộc tinh thần "anonymous" đang đề cập trong bài viết. Đó là một dạng proxy khi dùng nó không cần phải khai báo tên người dùng và mật khẩu. Loại proxy này tương phản với "user proxy", nó buộc người dùng phải khai báo. Loại "anonymous proxy" và "user proxy" này đều có thể có tính năng "lột bỏ" các header cá biệt của trình duyệt như dạng ở trên.