Chiều 30/8/2008
Chiều hôm ấy rảnh rang, tôi đăng nhập vào firewall của HVA và tiếp tục táy máy.

Cả ngày hôm ấy, vừa làm việc linh tinh tôi vừa suy nghĩ về giải pháp "/dev/null".

Một gói UDP đi vào, nếu muốn đưa nó vào /dev/null cần phải hội đủ những điều kiện nào? Phải làm gì? Thực hiện chi tiết thế nào? Tôi không được cái tiện nghi để ngồi xuống bàn với mảnh giấy và cây bút để hí hoáy nên đành phải nghĩ ngợi và sắp xếp trong đầu ở mức độ cho phép. Những câu hỏi và trả lời tôi tự đặt ra như sau:

- Để cho gói UDP vào /dev/null, điều đầu tiên phải làm gì với nó? Nếu không DROP (-j DROP) -77- trên netfilter thì tất nhiên là phải cho vào (-j ACCEPT) -77-.
- Nếu cho vào (-j ACCEPT) thì nó đi đâu? Nó vào thẳng IP : DESTINATION_PORT (ở đây là IP của HVA và HTTP port 80 nhưng qua UDP).
- Nếu vậy, ở điểm nào nó bị tóm và đưa vào /dev/null -76-? Chưa rõ.
- /dev/null là một device đặc biệt dùng để wwwect stdout, stderr đến để huỷ bỏ. Vậy một gói UDP làm sao trở thành stdout để có thể vào /dev/null? Phải cần một công đoạn để thực hiện.
- Nếu tạo một công đoạn thực hiện, liệu nó có gia tăng khối lượng công việc cho firewall và tạo thêm trì trệ ở tình trạng 20 ngàn gói 1 giây? Chắc chắn là vậy rồi?
- Nếu thế, so sánh mức độ trì trệ khi dùng -j DROP như cũ và mức độ trì trệ khi đi xuyên qua một công đoạn nào đó để cho nó vào /dev/null thì cái nào trì trệ hơn? Chưa rõ.
- Có cách nào khác hơn là cách ứng dụng một công đoạn biến packet thành stdout để vào /dev/null? Tại sao phải luộm thuộm như thế? Chắc là có, trên *nix có discard -78- service. Ngoài ra còn có thể tạo một dịch vụ "giả" bằng netcat -79- rồi chuyển nó vào /dev/null.
- Nếu dùng netcat, liệu nó có bền chăng? Hay nó sẽ chết sau vài trăm ngàn cú dội và xử lý không kịp? Chưa biết.
- Nếu dùng discard service có sẵn liệu nó có bền chăng? Hay nó sẽ chết sau vài trăm ngàn cú dội và xử lý không kịp? Chưa biết.
- So sánh giữa netcat và discard, cái nào tốt hơn? Có lẽ discard tốt hơn vì nó gọn và có sẵn. Vả lại nó được xinetd điều tác.
- Nếu thử ứng dụng discard, cần phải làm những gì? Tất nhiên là phải sắp xếp và khởi tạo dịch vụ discard (chuyện nhỏ).
- Đã có discard rồi, cần làm gì trên iptables? Nếu gói tin đi vào thì tất nhiên hành động wwwect phải ở POSTROUTING table -77-.
..v...v......

Đã đến giờ phải kèm thằng bé môn toán nên tôi đành xếp máy lại vả lại anh chàng chủ nhân UDP kia sẵn sàng chờ đợi cơ mà. Thôi thì tạm ngưng.

Chiều 1/9/2008
Hôm nay thứ Hai, công việc lại hết sức dồn dập. Loay hoay đủ thứ việc nên mãi đến tối mới có thể ngồi vào bàn, giở laptop ra và tiếp tục... táy máy.

Tôi nhớ trước đây tôi đã tạo dịch vụ discard trên firewall của HVA và đã thử nghiệm qua khoản này nhưng chưa đi sâu bởi vì nạn DDoS x-flash ngày ấy (cuối 2005, đầu 2006) không nhằm mục đích saturate đường dẫn như dạng UDP DDoS lần này. Dịch vụ "discard" chỉ có thể access từ trên chính firewall nên không có gì phải ngại. Hơn nữa, nó được chính firewall bảo vệ. Bởi thế, có lẽ nó vẫn còn đó vì tôi nhớ mình chưa hề tắt bỏ nó.

Đăng nhập vào firewall của HVA, tôi thử:
Code:


Quả thật "discard" vẫn còn đó. Tôi kiểm tra lại config của dịch vụ này cho bảo đảm:
Code:



Restart lại một phát cho chắc ăn. Ngon lành! Tôi bắt tay vào "ngâm" công đoạn làm sao để các UDP packets đi vào sẽ được "match" và được chuyển đến cổng dịch vụ của discard.

Thử nghĩ xem, một packet đi đến firewall, nếu điểm đích của nó chính là firewall thì nó sẽ được "route" đến bảng (table) INPUT sau khi đi xuyên qua một loạt các bước trong kernel -80-. Trong trường hợp các gói UDP đang tấn công HVA, chắc chắn điểm đích tôi không muốn (hoặc sẽ không cho phép nó đến) là firewall bởi vì tình trạng trì trệ nó tạo ra. Tôi muốn "đẩy" chúng đi đến nơi khác rồi "xử" chúng sau. Ở đây, tôi đang có ý định "đẩy" chúng đến một dịch vụ gọi là discard. Bởi thế, ngay khi gói tin này đi đến firewall, nó phải được "PREROUTE" để chuyển đến "discard".

Một luật như sau:
Code:


sẽ ấn định rằng một gói UDP từ bất cứ nơi nào mà đi xuyên qua "interface" IF (trong trường hợp này là eth0) và có điểm đích là $IP (trong trường hợp này chính là pubic IP của HVA firewall) thì DROP nó. Điều này có nghĩa, công đoạn PREROUTING trước đó đã xong và gói tin này quả thật có điểm đích chính là HVA firewall. Tất nhiên, các gói UDP dùng để tấn công kia sẽ bị DROP nhưng tình trạng trì trệ không được giải quyết.

Trong khi đó, một luật như sau:
Code:


sẽ ấn định rằng một gói UDP từ bất cứ nơi nào mà đi xuyên qua "interface" IF thì sẽ được chuyển (REDIRECT) đến cổng 9. Với netfilter / iptables, "REDIRECT" có một vai trò hết sức cụ thể, nó dùng để direct gói tin đến một cổng dịch vụ khác cũng ở ngay cùng một host (trong trường hợp này, nó wwwect bất cứ gói UDP nào đi vào đến cổng 9 cũng ở ngay trên firewall).

Nhìn vào dòng luật trên, tôi nhận ra nó quá rộng và có thể tạo "false negative", hoặc nói một cách khác, nó sẽ cản luôn những gói UDP cần thiết. Ví dụ như ngay chính firewall cần liên hệ với một DNS server nào đó bên ngoài để lấy thông tin, DNS server ấy trả lời bằng một gói UDP; gói UDP ấy cũng sẽ có cùng.... số phận là biến mất trong '/dev/null' (vào discard service).

Nếu bạn đã dùng qua netfilter / iptables, có lẽ bạn sẽ thắc mắc tại sao tôi không dùng "state machine" (--m state) để ấn định rằng nếu chính firewall gởi một gói UDP ra ngoài thì hãy cho phép gói trả lời đi vào? Trên mặt nguyên tắc, đây là cách thông thường cho hoàn cảnh bình thường. Tuy nhiên, thử hình dùng cái "state machine" sẽ như thế nào nếu cứ mỗi giây có khoảng 20 ngàn packets dội vào? Bởi thế, tôi điều chỉnh dòng luật ở trên thành:
Code:



Dòng luật trên tạo một ngoại lệ mới, đó là chọn lựa ! --sport 53. Dấu ! biểu thị cho "negation", sự ngược lại. Dòng luật này có thể hiểu nôm na rằng, một gói UDP từ bất cứ nơi nào mà đi xuyên qua "interface" IF nhưng không có source port là 53 thì sẽ được chuyển (REDIRECT) đến cổng 9. Điều này có nghĩa nếu trong đám 20 ngàn packets trong mỗi giây kia có vài UDP packets với cổng nguồn (source port) là 53 thì có lẽ chúng là những gói tin trả lời từ DNS nào đó, không "wwwect" chúng vào '/dev/null'.

Vậy, bạn có thể tiếp tục thắc mắc rằng, nếu chủ nhân UDP DDoS kia có thể tạo hoàn toàn các UDP packets đều có cổng nguồn (source port) là 53 thì sao? Câu trả lời là: nếu thế thì tất nhiên dòng luật ở trên vô dụng vì chúng sẽ không đi vào '/dev/null' mà sẽ đi đến INPUT chain và đi thẳng vào trong. Tuy nhiên, xét theo nội dung của các gói tin sniff được thì thấy rằng, cá zombies dùng để tấn công đều tạo cổng nguồn là các cổng > 1024. Điều này dễ hiểu vì chương trình nào đó "ra lệnh" cho các zombies tạo UDP packets để gởi đi không thể ấn định packets phải có cổng nguồn là 53 mà hoàn toàn dựa vào quyết định của kernel trên mỗi máy con (của zombie) quyết định cổng nguồn sẽ là gì. Bởi thế, cơ hội gói tin dùng để tấn công có cổng nguồn (source port) là 53 là cơ hội cực kỳ hiếm hoi.

Việc điều chỉnh firewall và chuẩn bị "sẵn sàng tư thế" là chuyện đơn giản sau khi đã hoàn thành quá trình phân tích ở trên. Để bảo đảm, tôi restart lại firewall và quyết định... tự DoS vào firewall của HVA xem sao. Trên laptop, tôi chuẩn bị một cái script đơn giản để tạo UDP packets gởi đến địa chỉ IP của HVA. Trên firewall của HVA, tôi tạo ra 2 consoles, một để theo dõi logs do netfilter tường trình, một để theo dõi packets đi vào. Tôi chạy cái script và bắt đầu quan sát. Quả thật hàng loạt UDP packets do tôi tạo ra lũ lượt đi vào. tcpdump cho thấy:

Code:



và chúng.... biến mất ở đâu đó. tcpdump không thể sniff giai đoạn các packets trên đuợc wwwect đến cổng discard (9) nên tôi đoán rằng chúng đi đến cổng ấy. Tôi xoa tay thoả mãn và log vào Pidgin để xem có anh chàng chủ nhân UDP DDoS ở đó hay không để thử một phát xem sao.

Vào Pidgin, nick của anh chàng ấy xám xịt nên tôi đành gởi một cái offline message để nhắn khi nào tiện thì cho tôi biết để mình thử nghiệm tiếp. Không ngờ anh chàng "ẩn" trên YIM nên tôi nghĩ anh chàng offline mà thật ra anh chàng đang online. Chúng tôi trao đổi vài thông điệp và anh chàng cho biết đã sẵn sàng. Thế là chúng tôi bắt đầu.

Chẳng mấy chốc, trên console của tcpdump hiện ra hàng loạt gói tin UDP. Chúng lũ lượt đi vào với vận tốc hết sức dồn dập. Tôi phóng ngay một console tiếp theo để theo dõi tình hình tài nguyên (memory, CPU, disk...) trên server. Không như tôi dự đoán rằng anh chàng sẽ vận dụng y hệt phương thức mấy hôm trước, lần này các gói tin có độ ngẫu nhiên cao hơn rất xa:

Code:



Vẫn như trước, các gói tin UDP đi vào IP của HVA ở cổng 80 nhưng lần này chúng thay đổi kích thước chiều dài ngẫu nhiên. Dường như có một số zombies bị gắn chặt với "length" nhất định, các zombies khác lại thay đổi.

Qua lần trao đổi trước, tôi có đề cập đến khía cạnh lợi và hại của việc gởi gói tin kích thước lớn và gói tin kích thước nhỏ. Dường như anh chàng nghĩ rằng gói tin kích thước nhỏ lợi hại hơn vì chúng được gởi đi nhanh hơn và có lẽ anh chàng nghĩ rằng tôi sẽ cản các gói tin có kích thước nhất định nên mới hình thành các gói tin có kích thước lớn bé khác nhau.

Tôi thử truy cập vào diễn đàn HVA: vẫn bình thường! Vậy là có vẻ ổn rồi.

Thử xem: iptables -t nat -L -v -n | grep PREROUTING

Code:



Tôi định gởi cho anh chàng một thông điệp để thông báo tình hình thì đã nhận được một dòng gởi đến: "Anh ơi, hình như mấy con bots của em không có tác dụng gì hay sao đó. Để em coi còn được mấy con."

Tôi đáp: "Còn nhiều lắm, anh tính khoảng trên 200 con nhưng tình hình có vẻ không mấy tác dụng vì anh đã thay đổi một số điểm trong cơ chế chống UDP DDoS này rồi."

Cậu ta đáp: "À ra vậy. Để em coi lại thử xem sao."

Tôi ngồi đó, tiếp tục quan sát. Càng lúc càng có nhiều UDP đi vào nhưng tình hình có vẻ không thay đổi. Hồi lâu, chẳng thấy anh chàng lên tiếng, tôi bèn gởi một thông điệp báo rằng tôi phải logoff để đi ngủ và tôi logoff, không quên kiểm tra mọi thứ một lần nữa trước khi tắt máy.

Chiều 2/9/2008
Hôm nay tôi được nghỉ bù nên làm loanh quanh vài việc lặt vặt rồi vào bàn ngồi. Tôi login Pidgin để kiểm tra offline messages đồng thời xem thử anh chàng chủ nhân UDP DDoS có online hay không để tiếp tục. Thật may là anh chàng đang online. Cu cậu cho biết là hắn đã thử đổi chiến thuật vài lần và gia tăng một số bots nhưng có vẻ tình hình không khả quan nhưng đã có sáng kiến mới. Tôi hăm hở hồi đáp rằng tôi sẵn sàng thử nghiệm.

Cũng như lần trước, tôi phóng ra mấy cái console và ngồi chờ. Không lâu, hàng loạt UDP packets tuôn vào và lạ thật, chúng malform (bất hợp lệ) đến mức kỳ quái nhưng không hiểu sao vẫn vượt qua bao nhiêu là routers trước khi đụng đến firewall của HVA. Chúng có dạng như sau:

Code:



Ngoài mấy dòng có "length 4000", các dòng còn lại (biểu thị cho các packets) hoàn toàn bất hợp lệ. Thật tình trước giờ tôi chưa bao giờ mục kích gói tin UDP kỳ quái đến thế. Bạn có nhận ra chúng kỳ quái thế nào không?

Chúng vào nhanh như vũ bão và kỳ lạ thay, cơ chế phòng thủ '/dev/null' lúc này không còn mấy tác dụng. Thống kê các packets xuyên qua tcpdump và xuyên qua số lượng 'match' mà netfilter đã cho vào 'discard' service thì thấy chúng chênh lệch khá xa. Điều này khiến tôi tin rằng vì lý do nào đó, netfilter không 'thấy' được các gói tin UDP không có cổng nguồn (source port) và cổng đích (destination port) nên chúng không chuyển chúng đến 'discard' service. Bởi thế, tình trạng trì trệ lại xảy ra như trước.

Anh chàng chủ nhân UDP gởi tôi một thông điệp báo rằng hình như tấn công kỳ này có kết quả. Tôi báo rằng đúng là HVA đang bị trì trệ. Tôi còn bảo: "Em dùng packet gì mà lộ liễu thế? Gói tin gì mà chẳng có source port, destination port gì hết. Mấy cái này nhận diện chúng quá sức là dễ dàng!"

Anh chàng chỉ trả lời vỏn vẹn một biểu tượng mặt cười: " "

Tôi vò đầu ngồi suy nghĩ. Có lẽ anh chàng nhận định về điểm yếu và điểm mạnh của packets có kích thước lớn và bé mà tôi trình bày với anh chàng vào ngày trước nên chàng ta quyết định lột bỏ luôn kích thước. Tiện tay, lột bỏ luôn source port và destination port để tôi có filter port cụ thể thì toi. Chẳng lẽ netfilter bị bug? Hay kernel có quy định nào đó về các packets thiếu hợp lệ như thế và đã lặng lẽ 'xử' chúng? Hãy thử xét lại vấn đề trên phương diện IP routing xem sao.

Rõ ràng, gói tin như:
Code:


được định tuyến qua nhiều routers, đi từ địa chỉ 83.142.226.76 đến www1.hvaonline.net. Trên phương diện IP routing, router chỉ có biết IP address và cứ việc forward datagram đến hop kế tiếp cho đến khi packet này đến đích. Khi host www1.hvaonline.net (là đích) nhận được IP này, nó tiếp nhận và bắt đầu thực thi demultiplexing -81- từ network layer (IP) lên transport layer (UDP). Ở giai đoạn depmultiplexing này, kernel nhận thấy datagram không có thông tin ấn định gói tin này sẽ đi vào cổng dịch vụ nào nên nó tự động hủy bỏ. Đây là thái độ xử lý bình thường và hoàn toàn đúng quy cách. Tuy nhiên, việc xử lý này trở nên bị trì trệ vì có quá nhiều "vụ" để "xử". Nếu kernel tự động xử lý chúng thay vì chuyển chúng đến một chỗ nào đó (như discard service) và không còn phí tài nguyên + thời gian để lo thì chắc chắn tình trạng trì trệ này sẽ giảm.

Tôi lục lại mớ packet dumps mấy ngày trước và xem lại thật kỹ. Rà từng dòng cho đến khi đụng đến các gói tin không có source port mà tôi bắt được mấy ngày trước đây, tôi tự vỗ vào đầu mình một phát và lẩm nhẩm: "đúng là lú lẫn". Quả thật, tôi bị cuốn vào mớ UDP có tính chất mới (biến thiên từ dạng có chiều dài 4000 bytes và đi vào HTTP UDP port đến dạng có chiều dài ngẫu nhiên) mà quên mất rằng ngay từ đầu mình đã bị "chơi" bằng các gói UDP không có source port và desination port. Rõ ràng netfilter không có ấn định cụ thể nào cho việc "match" các gói tin không có source port hoặc destination port hoặc cả hai. Bởi thế, tôi đành thử thêm một rule mới đi theo sau rule trước:

Code:



Rule này ấn định rằng bất cứ gói UDP nào đi vào mà không có kích thước từ 47 đến 65535 bytes và không đi đến cổng đích là 65431 thì đưa nó đến cổng số 9 (discard).

Tại sao phải ấn định luật như thế này? Bởi vì, tất cả các gói UDP dùng để tấn công không có kích thước thì chúng nằm bên ngoài biên độ cho phép ở trên, chúng bị wwwect. Nếu chúng có kèm kích thước nhưng không kèm cổng đích cũng không nằm trong biên độ cho phép nên cũng bị wwwect.

Tại sao chọn 65431? Bởi vì đó chỉ là một port ngẫu nhiên (làm sao anh chàng tấn công có thể đoán ra rằng nếu gói UDP đi vào mà không đến cổng đích thì bị wwwect?).

Tại sao chọn kích thước từ 47 đến 65535 bytes? Bởi vì 1 gói IP hợp lệ hiếm khi nào nhỏ hơn 47 bytes.

Tôi restart lại fireall có thêm dòng luật trên và tiếp tục theo dõi thông tin trên tcpdump và matched log của netfilter. Voila! lần này chúng có số lượng tương tự nhau. Tôi mỉm cười, gởi cho anh chàng một thông điệp và báo rằng sáng kiến mới đã bị chế ngự.

Tình trạng truy cập đến HVA dần dần trở lại bình thường. Sau đó tôi thấy anh chàng chuyển packets sang dạng có cổng nguồn, cổng đích và có kích thước ngẫu nhiên rồi lại tạo hỗn hợp UDP khác nhau để tấn công nhưng đều bị hai rules trên thấy được và cho vào "discard". Sau gần một giờ, anh chàng gởi đến tôi một thông điệp và bảo rằng lối "đánh" UDP đã bị thất bại. Tôi cười và đáp: "Cám ơn em đã giành thời gian cho một cuộc thử nghiệm hết sức lý thú. Có lẽ lần này đáng để đi vào loạt bài Ký sự DDoS HVA rồi đó."

Chúng tôi chào tạm biệt và logoff.

PS: cho đến lúc này, tôi vẫn chưa tìm ra lý do tại sao netfilter không match các gói UDP không có cổng nguồn và cổng đích.


Chú thích:
-76-: /dev/null

-77-: -j DROP, -j ACCEPT, POSTROUTING là những target và table trên iptables. Đọc thêm ở http://www.iptables.org để nắm chi tiết.

-78-: discard là dịch vụ ứng dụng tiêu hủy bất cứ gói tin nào đi vào cổng dịch vụ ấy. Nó tương tự như /dev/null cho stdin, stdout và stderr nhưng đặc biệt dành cho internet protocols (TCP và UDP). Dịch vụ này có sẵn trên hầu hết các hệ điều hành Unix và Linux.

-79-: netcat, một ứng dụng mạng nổi tiếng, được mệnh danh là "Swiss army knife for networking" (dao đa dụng quân đội của Áo dành cho mạng). netcat có trang chủ ở: http://netcat.sourceforge.net/

-80-: netfilter packet traversal. Một bức minh hoạ được "chôm một cách trắng trợn" từ tài liệu "Iptables Tutorial" của Oskar Andreasson





-81-: ở mỗi layer của TCP/IP model, packets được "đóng gói" (encapsulating) trước khi gói tin đi ra và được "mở gói" (multideplexing) trong khi gói tin đi vào.

Hình dung một gói tin trước khi đi ra ngoài, nó được đóng gói từ tầng cao nhất (application layer) đến tầng thấp nhất (link layer) như thể một hộp nhỏ được cho vào một hộp lớn hơn cho mỗi tầng:
Application layer -- [hộp A] ---> transport layer -- [hộp B [hộp A]] ---> network layer -- [hộp C [hộp B [hộp A]]] ---> link layer -- [hộp D [hộp C [hộp B [hộp A]]]]

Và khi gói tin đi vào một host, nó được mở gói từ tầng thấp nhất (link layer) đến tầng cao nhất như thể mở hộp lớn nhất có chứa hộp bé hơn và như thế cho đến khi mở hộp cuối cùng:
Link layer -- [hộp D [hộp C [hộp B [hộp A]]]] ---> network layer -- [hộp C [hộp B [hộp A]]] ---> transport layer -- [hộp B [hộp A]] ----> application layer -- [hộp A]