25/4/2005
Mấy ngày qua triền miên với gia đình và bạn bè vì nơi tôi cư ngụ có ngày lễ lớn. Tôi cũng không lo ngại mấy cho HVA forum vì tôi biết chắc giải pháp tạm thời "ép" người dùng đi vào cổng 443 dùng "self signed" ssl của HVA hoàn toàn hoá giải những cú "x-flash" hết sức hợp lệ kia. Tôi không muốn (và không tiện) vùi đầu vào mớ luật phòng thủ của HVA trong khoảng thời gian này.

Chiều nay, một buổi chiều ngày lễ. Sau những trận họp mặt náo nhiệt, tôi được một buổi chiều yên tĩnh và rảnh rang. Tôi nghĩ ngay đến việc tạo ra thêm một lớp "vỏ" cho HVA forum như đã đề cập trong bài "ký sự" trước. Làm một ly cà fê, tôi thong thả ngồi xuống bàn và mở laptop lên.

Lần trước tôi đã đề cập như sau: "Một biện pháp cản lâu dài tôi có thể nghĩ ra trong khoảng thời gian hạn hẹp này là "cản" không cho bất cứ request nào đi thẳng đến *.php cả. Làm được điều này, sự cản trở đầu tiên sẽ là việc loại trừ khả năng các cú 'x-flash' "ép" HVA forum ngoan ngoãn gởi queries đến database và tạo load trên máy chủ. Cả request "hợp lệ" lẫn "bất hợp lệ" đều phải đi xuyên qua các đường dẫn trước khi các *.php thực thi công tác." Có lẽ câu nhận định này khá rõ ràng cho những ai từng theo dõi sâu sát những bài "ký sự" trước. Tôi không cần phải nhắc lại chi tiết lý do tại sao phải thực hiện chuyện này nhưng điểm cốt lõi của vấn đề nên được nhấn mạnh: dạng tấn công lúc này không có điểm nào dùng để cản. Nếu không cản được thì cho vào cả, nhưng cho vào với điều kiện do mình đặt ra.

Chắc bạn đã thấy chiến thuật đã thay đổi một cách nghiêm trọng? Từ chỗ tìm ra những dấu hiệu đặc thù của những cú "x-flash" để cản, đi đến chỗ cho phép mọi request đi vào với các điều kiện tiền định nào đó. Nếu bạn hiện đang truy cập HVA forum, bạn hẳn thấy có trang index và nút "e n t e r" để đi vào trong forum. Đây chính là phần cản phục vụ cho khái niệm tôi vừa nêu ra ở trên.

Chuyện gì xảy ra bên dưới "tấm màn" index.html này? Như đã có nhiều tay kinh nghiệm nhận định trước khi bài "ký sự" kỳ này được viết, quả thật tôi đã dùng đến những thứ có trên HTTP header để quyết định cho những request nào tiếp tục vào[b] và đẩy những request nào không thoả mãn điều kiện lại [b]tiếp tục vào... trang index.html . Tôi không muốn nêu ra một cách chi tiết những gì có và không có trên HTTP header và những yếu tố nào tôi đã dùng để áp đặt từng bước "cho vào". Làm như vậy e tạo điều kiện quá dễ dàng cho "chủ nhân" các con "x-flash" kia (tôi đã sai lầm khi đã gợi ý cho chủ nhân "x-flash" đường hướng của dạng tấn công "không lan man" này và chỉ một lần là quá đủ). Đối với bạn, một admin có trách nhiệm quản lý server của mình, bạn chỉ cần dùng sniffer để "bắt" một mớ packets, thu thập những gói tin cho một xuất truy cập hợp lệ và so sánh với mớ gói tin được tạo từ "x-flash" dùng để tấn công thì bạn có thể dễ dàng thấy sự khác biệt. Cái khó và mất thời gian là bạn phải nắm rõ các URI nào diễn đàn dùng và chỉ cho phép chúng được truy cập dựa trên các luật nào đó cho phép. Những URI khác (và không tồn tại) sẽ phải được cản.

Viết thêm rules cho mod_security và .htaccess khá đơn giản sau khi hình thành kế hoạch rõ ràng nhưng thời gian dành cho debug có lẽ nhiều. Tôi bắt tay ngay vào thực hiện chuyện "viết rules" này. Sau hơn ba mươi phút, các rule cốt lõi cho cái "vỏ" đã sẵn sàng. Ba mươi phút kế tiếp tôi dành thời gian để "debug" mấy cái rules vừa hình thành. Mục tiêu chính là cố gắng giảm thiểu trường hợp những rule này tạo cản trở cho người dùng hợp lệ, đồng thời không vô tình để hở cho cho các cú "x-flash" đi vào. Điều khó khăn là tôi không thể "test" những rules này trên máy riêng ở nhà vì làm như vậy sẽ mất thời gian hơn để tạo các cú "x-flash giả" để thử nghiệm. Tuy nhiên, test các rules này ngay trên máy chủ HVA chắc chắn sẽ tạo bối rối cho nhiều thành viên nhưng... biết làm sao được?

Trong khi thao tác các bước cần thiết để tạo thêm lớp "vỏ" này, tôi đã ngầm e ngại một "triệu chứng phụ" sẽ xảy ra. Triệu chứng này không thể làm cho máy chủ HVA treo vì cạn kiệt tài nguyên nhưng lại có thể không cho người dùng truy cập vào diễn đàn HVA. Dù gì đi chăng nữa, phải hoàn tất mảnh "vỏ" index.html và các luật bảo vệ rồi lo liệu chuyện "triệu chứng phụ" sau. Sau hơn một giờ táy máy với máy chủ HVA, tôi chuyển server về lại tình trạng cũ, có nghĩa là thành viên HVA vẫn phải đi xuyên qua cổng 443 (HTTPS) vì tôi nhận thấy việc thử nghiệm này sẽ mất rất nhiều thời gian. Có lẽ tôi phải chờ đến trưa mai, khi có ít thời gian rảnh rang, tôi sẽ tiếp tục phần thử nghiệm này.

Tôi logoff HVA server và vươn vai đứng dậy.

26/04/2005
Hôm nay quả là một ngày cực kỳ bận bịu đối với tôi. Trưa nay, vừa ăn trưa tôi vừa tranh thủ logon HVA server để tiếp tục khoản công việc dở dang hôm qua. Tôi nhận thấy truy cập vào diễn đàn HVA bằng https vẫn được và vẫn ở tốc độ "có thể chấp nhận". Tuy nhiên, tôi không thoả mãn với giải pháp tạm bợ này, phải hoàn tất "lớp vỏ" bảo vệ mới cho diễn đàn HVA càng nhanh càng tốt nhưng... thời gian quả là hạn hẹp.

Tôi tiếp tục công việc "debug" các rules mới tạo cho mod_security, từng phần một. Kiểm tra kỹ lưỡng mỗi request từ client (từ trình duyệt của tôi) và response từ server (từ máy chủ HVA), phân tích tính chất của mỗi URI chính yếu của diễn đàn HVA. Trong khi thử nghiệm, tôi khám phá ra IPB và mớ .php của nó có những điểm bất nhất khi nhận requests và trả về responses. Những điểm bất nhất này khó thấy nhưng chúng trở nên rõ ràng khi tôi bắt tay vào việc "debug". Tôi quyết định dùng mod_security để che lấp chúng và dành công tác điều chỉnh trên .php về sau, khi có thời gian rộng rãi. Những điều tôi tìm thấy không hẳn là điểm yếu bảo mật; chúng chỉ làm cho bộ luật của mod_security thêm phần rối rắm để có thể "che" trọn bộ các URI một cách vững vàng.

Một giờ nghỉ trưa trôi qua, 2 phần 3 bộ luật đã được kiểm chứng và điều chỉnh, 1 phần 3 còn lại có lẽ phải dành cho lúc khác vì tôi phải trở lại làm việc. Khi logoff máy chủ HVA, tôi quên khuấy một điều là đã quên đóng cổng 80 lại, chỉ cho phép người dùng truy cập diễn đàn ở cổng 443. Kết quả của sự đãng trí này đã tạo ra không ít bối rối cho người dùng trong buổi chiều hôm ấy. Mãi đến tối ngày 26/04/2005, khi login HVA server để "tiếp tục công việc", tôi mới khám phá ra rằng cổng 80 vẫn còn mở và bà con vào diễn đàn ở cổng này. Chắc hẳn họ đã gặp phải nhiều hiện tượng "kỳ quặc" bởi bộ luật của mod_security chưa hoàn chỉnh.

Tối 26/04/2005
Hôm nay công việc quá bề bộn nên tôi về nhà khá trễ. Cơm nước xong đã gần 8 giờ tối. Nhìn đồng hồ, tôi thầm nghĩ "chẳng còn bao nhiêu thời gian để táy máy". Tuy vậy, tôi vẫn log vào HVA server để xem qua tình hình và xem thử có tiếp tục được bao nhiêu công việc đang dang dở.

Tôi nhận thấy server có vẻ chậm hơn trưa nay rất nhiều. Kiểm tra server load, tôi ngạc nhiên khi thấy load trung bình lên tới 98. Tôi tò mò muốn xem thử trò chơi mới của "x-flash" thế nào nên để yên server ở tình trạng như thế. Không còn thời gian để dump các packets này và tải về để xem trên Ethereal trên laptop, tôi phóng ngay lệnh tcpdump trên màn hình để xem chuyện gì xảy ra. Tôi cần tcpdump bắt trọn gói mỗi gói tin bất kể kích thước nào và hiển thị trên màn hình cho tôi ở dạng binary lẫn ASCII nên lệnh dùng thế này (nếu bạn cần biết):
Code:


Tôi phải đảo mắt rất nhanh để theo dõi dòng thông tin "chảy" như thác trên màn hình. Thỉnh thoảng tôi phải tạm chấm dứt lệnh này để xem kỹ vài chi tiết rồi lại tiếp tục. Sau vài phút kiểm tra, tôi đã có đủ thông tin cần thiết để biết chuyện gì đang xảy ra. Tôi lẩm bẩm: "đúng là điên khùng!" khi thấy có 4 dạng request khác nhau đổ dồn vào HVA:
- GET /
- POST /
- GET /forum/
- POST /forum/index.php

và tất nhiên chẳng có mấy gói tin mang "x-flash" header. Trong khi "lớp vỏ" che cho forum ở web layer chưa hoàn tất, những cú gõ trên chỉ bị giới hạn ở mức connection limit tổng quát trên iptables. Số còn lại thả dàn đi vào. Tôi đành phải dùng một chước khá buồn cười là đổi trang mặc định của web server từ index.php thành start.php và restart lại apache. Tất nhiên là mới GET và POST điên khùng ở trên không thể đụng đến index.php để tạo load trên server. Sau vài phút, server load tụt xuống đáng kể và truy cập xuyên qua SSH nhanh hơn rõ. Cái "chước" đổi trang mặc định thành start.php chỉ ngăn được mớ POST cụ thể đến /forum/index.php. Số request còn lại trỏ thẳng vào / vẫn tạo ảnh hưởng đến server. Mặc dù server load tụt xuống nhanh chóng nhưng đến mức nào đó, nó dừng lại. Chà, tôi lẩm nhẩm "chẳng lẽ lại phải chuyển về https sao?". Thật tình tôi không muốn làm thế vì nó sẽ tạo thêm bối rối cho thành viên của diễn đàn. Vả lại, tôi cần debug cho xong các rules của mod_security.

Tôi log vào YIM để liên lạc với JAL, lão đang online! Tôi gởi JAL một thông điệp thông báo tình hình. Giờ này lão vẫn còn ở sở vì nơi JAL cư ngụ sau nơi tôi cư ngụ 2 giờ. JAL hí hoáy gì đó vài phút và bảo tôi "lão vào diễn đàn xem sao?".

Tôi log vào diễn đàn HVA bằng FireFox. Ái chà, khi bấm vào nút "enter" trên trang index.html, một khung hiện ra và đòi hỏi nhập username + password! Tôi lẩm bẩm "tricky, tricky!". Quả thật, chước này của JAL đã ngưng lại trọn bộ các request của "x-flash" vào mà chước đổi trang mặc định thành start.php của tôi không thể cản hết. Server load tụt xuống nhanh chóng và truy cập diễn đàn nhanh hơn hẳn. JAL đã dùng một chước rất "cổ điển" trên .htaccess nhưng hết sức hiệu quả ngay lúc này. Tôi chỉ cần làm sao cho server load giảm xuống để có thể hoàn tất mớ luật kia. Tôi gởi JAL một thông điệp "Quá hay đó bồ, tuyệt cú mèo! nhưng làm sao cho cái ID và password trên dialog đó trông rõ hơn một tí." Tất nhiên là JAL đồng ý.

Tôi quyết định để yên server như vậy và kiểm tra nhóm luật cho mod_security lại. Từng dòng một, tôi cân nhắc, điều chỉnh, dùng grep trên cygwin -61- để xác thực các mảnh regular expression hoàn toàn "match" và ứng hiệu. Tôi dành hơn ba mươi phút cho công tác này và đã gần hoàn tất trọn bộ nhóm luật. Nhìn đồng hồ tôi thấy không còn sớm nữa. Tôi phải tạm ngưng vì ngày mai phải đi làm sớm.

Chú thích:
-61- cygwin, môi trường *nix chạy trên Windows có số lượng rất lớn các chương trình dựa trên *nix và được mang sang môi trường Windows. Xem thêm về cygwin ở" http://www.cygwin.com

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