Sáng 3/11:
Sáng nay tôi vào sở trễ hơn thường ngày vì tối qua thức quá khuya. Nói là trễ nhưng thật sự chỉ mới 7 giờ 30 sáng. Tôi quyết định dành riêng 30 phút để "thanh tra" HVA server và hoàn tất những gì tôi bỏ dở trước khi bắt tay vào chuyện viết bản báo cáo sự cố xảy ra trên server của công ty tối hôm qua.

Việc đầu tiên là tôi thử truy cập diễn đàn HVA bằng trình duyệt. Dự tưởng trong đầu chắc sẽ chậm lắm đây nhưng sự thử hoàn toàn trái ngược với điều tôi nghĩ; vào diễn đàn HVA vẫn nhanh như bình thường. Tuy nhiên, trình duyệt hiện ra thông báo "database is not available". Tôi thầm nghĩ: chắc giờ này chẳng ai thèm DoS và giờ này bên VN chỉ 4 giờ 30 sáng nhưng database không có thì có lẽ server vẫn sống nhưng database thì chết tiêu." Tôi log ngay vào HVA server và quả thật, server HVA vắng hoe; server load nằm ở mức 0.02. Tôi kiểm tra nhanh qua tình hình server xem nó có "bị" restart tối hôm qua hay không:
$ uptime
05:49:08 up 19 days, 10:04, 1 users, load average: 0.02, 0.02, 0.25

vậy là server vẫn còn sống sót sau "cơn bão" kinh hoàng. Chạy thử vài lệnh tiếp theo để kiểm tra process thì rõ ràng database đã "chết" tự khi nào. Tôi không rõ database bị "down" từ lúc nào và tôi cần rõ điều này. Chạy thêm vài lệnh grep đến mấy cái log, tôi xác định được database bị down từ 10 giờ 22 phút giờ trên server, có nghĩa là khoảng 0 giờ 22 phút giờ nơi tôi cư ngụ và khoảng 9 giờ 22 phút giờ VN. Tôi vò đầu lẩm bẩm: "chỉ có vài phút sau khi tôi logoff HVA server tối hôm qua! tại sao tôi không restart lại cái database server sau khi restart lại web server nhỉ?" Dù gì đi chăng nữa cũng là sự đã rồi. Có lẽ lý do HVA server sống sót tối hôm qua là do database server bị down suốt đêm (?)

Tối hôm qua, ngay khi tôi login HVA server và điều chỉnh web service để tháo bỏ ấn định "keep-alive", có lẽ lúc ấy database server đã tràn ngập QUERY và ở trong tình trạng "sống dở, chết dở" rồi nhưng tôi lại không để tâm đến nó. Có lẽ do não bộ của tôi bị mụ mẫm sau một ngày làm việc dài dằng dặt hôm qua nên không còn sáng suốt để suy xét vấn đề nữa. Tôi quyết định để yên database server ở tình trạng "down" như vậy để tiện làm việc.

- trước tiên, tiện tay tôi kiểm tra cấu hình database và xét qua số lượng connection cho phép. Giá trị ấn định này khá cao, nên tôi điều chỉnh để giảm bớt số lượng connection tương thích với lượng connection limit được ấn định trên firewall.

- kế tiếp tôi kiểm tra lại cấu hình của web server, điều chỉnh vài giá trị quan trọng nhất trong ấn định process được fork như thế nào để phục vụ requests (xem lại chú thích 45) đồng thời đưa vào một chuỗi filter cho mod_security.

- tôi tiếp tục chuyển xuống tầng snort và đưa vào mấy cái signatures đang dang dở; điều chỉnh thêm vài chi tiết nhỏ để cố gắng tạo hiệu xuất hơn và tái khởi động snort. Sau khi tái khởi đông, Snort hoạt động bình thường nhưng chưa thông báo thông tin nào về vấn đề DoS ở dạng URI ngẫu nhiên cả. Điều này hiển nhiên là vì tôi chẳng hề thấy dấu hiệu DoS ngay từ lúc logon HVA server.

- kế tiếp tôi xem xét lại firewall. Lần này tôi quyết định mở rộng connection limit trên firewall tương phản với việc thắt chặt nhiều điểm quan trọng trên web server. Sở dĩ tôi làm thế là vì muốn tạo cơ hội cho người dùng có thể truy cập được. Làm như thế server load sẽ gia tăng nhưng bằng mọi giá tôi phải tạo cơ hội cho người dùng hợp pháp có thể truy cập đến diễn đàn. Sau khi hoàn chỉnh firewall, tôi tái khởi động nó ngay (kẻo lại quên).

- và cuối cùng, tôi dành một phần lớn thời gian trong 30 phút ngắn ngủi kia để điều chỉnh tất cả giá trị liên quan đến tcp stack trên kernel có thể xử lý khối lượng request khổng lồ tương tự như tối hôm qua. Nguyên tắc điều chỉnh các giá trị kernel này rất đơn giản:

1. tôi muốn có tối đa lượng memory để cho phép một số lượng socket khổng lồ được mở bởi vì không có gì tệ hơn tình trạng socket bị DoS chiếm hết và người dùng hợp lệ không thể vào.

2. tôi muốn thời gian một cú SYN tồn tại ngắn hơn bình thường vì nếu các cú SYN được dời khỏi hàng đợi (queue) càng nhanh thì cơ hội server có thể tiếp nhận thêm SYN càng nhiều.

3. tôi muốn thời gian chờ đợi FIN và RST hoàn tất (các giá trị biểu thị TIME_WAIT, FIN_WAIT....) ngắn hơn bình thường vì những cú đợi này càng kéo dài, lượng memory bị chiếm giữ cho mỗi socket đã hoàn tất càng lâu và tình trạng này sẽ càng ứ đọng nếu DoS kéo dài.

4. thay thế vào việc giảm thiểu thời gian một gói tin ở dạng SYN, tôi gia tăng số lượng SYN được tiếp nhận và được nằm trên connection queue. Tôi muốn số lượng request đi vào được nhưng chưa được xử lý có cơ hội chờ đợi lâu hơn (trước khi chúng bị huỷ); bởi vì tôi không muốn trình duyệt của người dùng hợp lệ phải "retry" quá nhiều để có thể đi vào diễn đàn trong khoảng thời gian server đang bị DoS. Nên biết rằng syn_timeout khác với syn_backlog, phần 2 ứng dụng cho syn_timeout và phần 4 ứng dụng cho syn_backlog (số lượng gói SYN được chờ để xử lý).

Xét lại các bộ phận một lần nữa, tôi cảm thấy hài lòng và tiến hành khởi động database và các dịch vụ cần thiết khác. Mọi thứ chạy ngon lành ngay từ lượt thử đầu tiên. Tôi tạo thêm một console đến HVA server trên màn hình và phóng cái "đuôi" tail thứ nhất để theo dõi snort log, cái thứ nhì để theo dõi thông báo của mod_security và tạm ngưng việc "táy máy" với HVA server để bắt đầu vào công việc ở sở.

Trưa, chiều 3/11:
Suốt bốn giờ vừa qua, hễ lúc nào có dịp là tôi chuyển sang hai cái console ở trên và xem chừng có biến cố gì trên server hay không? Thỉnh thoảng có vài loạt URI ngẫu nhiên đi vào và đều bị cả hai cơ phận snort, mod_security tóm chúng một cách đều đặn sau khi thoả mãn điều kiện connection limit trên firewall (mặc dù lúc này chỉ mới 9 giờ sáng bên VN). Tôi an tâm tiếp tục làm việc.

Mãi đến 3 giờ chiều, số lần các cú DoS đi vào thường xuyên hơn nhưng server load chưa hề lên khỏi mức 1.0. Tôi mở trình duyệt và thử truy cập vào diễn đàn HVA: thông suốt, nhanh chóng. Tôi thử nhấn Ctl-F5 -55- liên tục vài cái: chiếc "đồng hồ chờ đợi" hiện ra lâu hơn. Càng nhấn nhiều Ctl-F5, càng chờ đợi lâu. Lý do tại sao tôi thử nghiệm bằng cách này? Bởi vì lúc này web server của HVA không còn chế độ "keep-alive" nữa, mỗi cú "refresh" trên trình duyệt sẽ tạo dăm ba cái sockets với HVA server để tải nội dung của diễn đàn về trình duyệt. Trong lúc loạt connections của cú nhấn Ctl-F5 đầu tiên vẫn còn tồn tại, nếu tôi tiếp tục nhấn thì sockets mới sẽ được tạo thêm và sẽ bị "vướng" ngay vào quy định connection limit của firewall vì tôi không thể tạo thêm connection vượt quá giới hạn cho phép trong cùng một lúc. Nếu tôi thong thả duyệt từng trang một, mỗi trang tôi dừng lại tối thiểu là vài mươi giây (trong khoảng thời này connection giữa trình duyệt của tôi và HVA server đã kết thúc) thì tôi không gặp bất cứ cản trở nào. Đây chính là tình trạng duyệt web bình thường của một người dùng hợp lệ vậy.

Biết chắc là ấn định connection limit + "no keep-alive" làm việc "hài hoà" với nhau. Tôi an tâm xếp laptop lại chuẩn bị rời sở. Tôi tự nhủ là tối nay sẽ dành một giờ đồng hồ theo dõi chuyện gì xảy ra trên HVA server.

Tối 3/11:
Ăn tối xong, sau khi hoàn tất các chuyện lặt vặt, tôi bắt tay vào việc "thanh tra" HVA server.

8 giờ 30 tối nơi tôi cư ngụ chỉ mới 5 giờ 30 chiều giờ VN nhưng cứ thử xem sao. Tôi mở laptop lên, phóng ngay trình duyệt để vào diễn đàn HVA: khởi tạo trang chủ hơi chậm nhưng sau đó mọi chuyện bình thường và tôi biết lý do tại sao khởi tạo lại chậm, tôi mỉm cười mở ra hai console vào HVA server.

Nhưng thường lệ, tôi xem qua server load:
$ w
bình thường, giá trị server load trung bình là 1.1, tốt!

Tôi xem qua số lượng SYN đang hiện hữu trên server:
$ netstat -nat | grep SYN | wc -l
72
nhiều hơn bình thường nhưng chắc chắn là quá ít so với cơn lũ hôm qua.

Tôi xem qua số lượng GET dùng URI random mà snort đã bắt được từ lúc signature mới được đưa vào từ sáng nay:
# grep -i "random" $SNORT_LOG/alert | wc -l
317476

Kinh nhỉ? Gần 32 ngàn cú trong vòng 12 giờ qua.

Tôi muốn xem số lượng GET dùng URI random mà mod_security đã tóm được từ sáng nay:
grep -i "?&time" $HTTP_LOG/mod_sec.log | wc -l
17749
Nhiều thật! không hẳn server yên tĩnh như tôi nghĩ qua vài lần kiểm tra trong ngày nhưng rõ ràng server load không lên cao từ sáng nay sau lúc tôi điều chỉnh lại cấu hình server cho đến lúc này. 17749 lần ghi nhận trên mod_sec.log tương đương với 17749 cú QUERY đến database server nếu như chúng không được chặn lại từ bên ngoài web server. Nếu quy ra thành giá trị server load, con số này hẳn kinh khủng. Thảo nào đêm qua database serve không chết đứ đừ.

Tôi phóng thử một cái "đuôi" tail đến firewall log để xem tình hình hiện tại ra sao. Lác đác có dăm ba cú URI random đi vào trong vài chục cú request đến server. Tôi thầm nghĩ: "nếu cứ DoS kiểu này thì đến tết Ma-rốc cũng không xước nổi một cái vảy." Chắc còn quá sớm.

Tôi tò mò muốn xem thử có cú x-flash nào thuộc dạng POST đi vào từ khuya hôm qua hay không:
# grep "POST" $SNORT_LOG/alert

Hoàn toàn không có.

Thế x-flash dạng GET?
# grep "GET" $SNORT_LOG/alert | wc -l
34153

Whoa! có lẽ con số này bao gồm các cú GET đến HVA banner lẫn các cú GET với URI ngẫu nhiên.

Táy máy với mấy cái log chừng nửa giờ, tôi đâm chán vì chẳng có gì đáng phải quan tâm. Tôi quyết định đi chơi bóng bàn và sẽ quay lại sau một giờ đồng hồ.

9 giờ 25 phút 3/11:
Tôi trở lại khi hai cái console nối vào HVA server đang ở tình trạng "chảy" cuồn cuộn các thông tin về những cú GET đang hăm hở đổ vào HVA server. Hãy xem vào diễn đàn bằng trình duyệt ra sao. Tôi khởi động trình duyệt vào chọn địa chỉ HVA forum từ bookmark: vẫn hơi chậm lúc đầu nhưng sau khi đã vào được diễn đàn rồi thì lướt các trang thông suốt.

Tôi chuyển qua một trong hai cái console đang in ra hàng tràng log trên màn hình và xem thử có bao nhiêu cú SYN đang ập vào:
# netstat -nat | grep SYN | wc -l
173

Thử lại lần nữa:
176

Thêm lần nữa xem sao:
169

Tôi lẩm nhẩm, với số lượng log đang đổ cuồn cuộn trên màn hình kia mà chỉ có trung bình từ 160 đến 180 cú SYN trong bất cứ lúc nào thì hẳn là giá trị ấn định SYN timeout trên kernel đã có hiệu quả rõ rệt. Điều này là thế nào? Như đã nói ở điểm thứ 2 ở trên, tôi cố tình chỉnh định để SYN timeout ngắn hơn bình thường kiến cho các cú truy cập mới được giải quyết nhanh chóng hơn.

Phải thử "dump" một đoạn các packets xem sao.
Tôi chạy lệnh:
# tcpdump -s0 port 80 -w /tmp/dump-03-11-2004

Trong khi đoạn dump trên đang chạy, tôi muốn xác định có bao nhiêu ESTABLISHED connections hiện đang có trên server:
# netstat -nat | grep ESTABLISHED | wc -l
283


Tôi chạy thêm lệnh này và đưa kết quả và một hồ sơ tạm thời để phân tích kỹ hơn:
# netstat -nat | grep ESTABLISHED | sort > /tmp/conn.txt
Đúng như dự đoán, sau khi các connection được lựa theo đúng thứ tự, cứ mỗi IP chiếm từ 4 đến 8 connections.

Chờ vài phút, tôi dừng cú tcpdump và tải hồ sơ này xuống laptop của tôi để phân tích. Thông tin từ đoạn các packets chỉ rõ một điều:
- cứ mỗi IP lại hình thành trung bình 4 connections, tuy nhiên chúng kết thúc nhanh chóng và nhất là các cú GET với URI random vì ngay khi mod_security phát hiện chúng thuộc diện vi phạm, nó đã báo lỗi ngược về chủ nhân của cú GET này và huỷ bỏ connection.
- có vô số gói tin đi vào thuộc diện vi phạm đã bị snort RST ngay khi nó bắt gặp gói tcp ACK-PSH có chứa thông tin về cú GET dùng URI ngẫu nhiên.
- có những tcp stream nối tiếp nhau từ một IP bao gồm cả các connections chứa cả thông tin truy cập hợp lệ lẫn thông tin thuộc về các cú GET đang tấn công HVA. Điều này chứng tỏ nguồn tấn công và nguồn người dùng cùng đi xuyên qua một IP nào đó (có thể là proxy, có thể là NAT server ở đâu đó) và chúng xảy ra cùng một lúc (hoặc trước sau trong tíc tắc).

Đối với tôi, bấy nhiêu thông tin đã quá đủ để xác định tình hình như sau:
- trận DoS vẫn tiếp diễn đều đặn. Tuy nhiên, chắc chắn những gói tin "tàn phá" kia không còn có cơ hội dùng một ESTABLISHED connection để đẩy các cú GET dồn dập đến HVA server nhưng ngày hôm trước mà phải tuân thủ theo đúng nguyên tắc "xong một request, mở socket mới" và nguyên tắc này được connection limit điều tác triệt để.

- bởi các cú SYN không tồn tại lâu như bình thường nên server có cơ hội và tài nguyên tiếp nhận nhiều SYN hơn bình thường. Mọi connection biến chuyển từ SYN_RECV sang ESTABLISHED và đi đến TIME_WAIT hết sức nhanh chóng. Điều này tạo cơ hội cho người dùng hợp lệ có thể "chen chân" với cơn lũ DoS.

- snort đóng góp rất lớn trong vấn đề hủy bỏ các socket được tạo ra từ những request "tàn phá" kia bằng cách RST chúng. Đối với tôi, đây là cách hữu hiệu trong việc ổn định connection queue của server.

- không hề có bất cứ cú GET dùng URI ngẫu nhiên đi qua khỏi cửa ngỏ mod_security (nếu chúng có đi lọt qua được cửa ngỏ snort) cho nên chúng không hề tạo bất cứ ảnh hưởng nào đến database server.

- server load hoàn toàn bình thường và xê dịch ở mức 0.9 - 2.8 là tối đa.

Tôi nán thêm nửa giờ nữa để theo dõi tình hình trên HVA server. Số lượng SYN có gia tăng nhưng không đủ dồn dập để phương hại đến server. Tuy nhiên, điều tôi lo lắng là số lượng log được tạo ra trong khi trận DoS tiếp diễn. Mặc dù sức chứa trên HVA server có thể chứa hàng chục gigabytes logs nhưng điểm quan trọng là sự hao tổn tài nguyên trong cơ chế I/O. Tôi quyết định điều chỉnh firewall, web server, mod_security và các cơ phận log khác giảm thiểu mức độ log rồi khởi động lại các dịch vụ này.

10 phút trôi qua.

Rồi 15 phút trôi qua.

20 phút trôi qua, khối lượng DoS càng gia tăng qua biểu thị của số lượng SYN_RECV trên netstat. Tôi vẫn có thể nhấn Ctl-F5 và trang web của HVA diễn đàn vẫn tải nhanh chóng. Để xác định được chính xác bao nhiêu cú SYN đi vào trong một giây ngay lúc này, tôi quyết định "dump" thêm một mớ packets. Tôi viết một đoạn script đơn giản để chạy tcpdump và buộc nó phải ngưng lại sau 60 giây. Kết quả cho thấy có đến trên 1300 cú SYN đến HVA server trong một giây nhưng phần lớn bị loại bỏ ở firewall vì quá giới hạn cho phép. Phẩn còn lại bị "time-out" và bị hủy vì phải đợi lâu hơn mức ấn định trên connection queue. Phần còn lại bị snort RST ngay trước khi được firewall quản chế. Các cú SYN thành công (vào được) và thuộc diện "bất hợp lệ" đều bị web server trả lại thông báo lỗi 403.

Tôi gật đầu thoả mãn với kết quả và logoff HVA server.

Những ngày tiếp theo đó, dạng DoS dùng URI ngẫu nhiên vẫn tiếp diễn tuy nhiên chúng thưa dần rồi tắt hẳn.

Mãi đến ngày 13 tháng 11, một lần nữa server lại "bị nạn". Ngày 13/11 tôi không hề vào net. Đến ngày 14/11, không log vào HVA server được, tôi gởi e-mail đến JAL để hỏi thăm tình hình. Sau hôm đó, JAL cho tôi biết là HVA server bị DoS rất kinh khủng tạo sự cố cho card mạng và bị dịch vụ cung cấp đường dây Internet than phiền về khối lượng traffic khổng lồ ra vào HVA server nhưng server hoàn toàn bình thường, không bị sự cố gì cả. Bởi thế, JAL đã phải cho diễn đàn tạm ngưng hoạt động vài ngày để sắp xếp đưòng dây mới tạm thời trước khi tìm một dịch vụ thích hợp. Điều đáng tiếc là JAL đã quên không tạo một cú packet "dump" trong khi HVA bị tấn công lần này, cho nên tôi không đoán nổi là chuyện gì đã xảy ra nhưng tôi tin rằng, đây là một dạng DoS mới nào đó. Dù nó đã không triệt được HVA server nhưng cũng đã tạo không ít phiền toái cho vấn đề sắp xếp dịch vụ cung cấp Internet mới vì khối lượng thông tin tràn ngập đường dẫn.

Cho đến nay, HVA server đã dời sang một đường dẫn "tạm thời" thứ nhì sau biến cố ngày 13/11 và vẫn bị DoS đều đặn (nhưng không kinh khủng) như trước nữa. Bởi vậy tôi mới có thời gian để viết bài phân tích cho các bạn đọc, đồng thời suy nghĩ và phân tích sâu thêm các biến thái của các đợt tấn công có thể xảy ra để điều chỉnh lại server cho thích hợp. Tính từ ngày đầu tiên tôi logon HVA server (xuyên qua SSH) cho đến nay, đã có hơn 30 lần điều chỉnh lớn, bé để thích ứng với hoàn cảnh. Điều tôi muốn nói ở đây là: để bảo vệ máy chủ đến mức độ tối đa trong hoàn cảnh và điều kiện cho phép, điều đầu tiên mình phải hiểu rõ mình đang bảo vệ cái gì, hiểu rõ điểm yếu của mình ở đâu và hiểu rõ dụng ý của đối phương. Không có một công thức kỳ diệu nào có thể dùng để ứng dụng cho mọi trường hợp và càng không thể có một software nào có thể hoàn toàn bảo vệ vững chắc một hệ thống làm việc. Bảo mật là công tác lâu dài và bền bỉ, nó đòi hỏi sự quan tâm thường xuyên, khả năng phán đoán tình hình và phản ứng kịp thời. Để nhận ra được điểm yếu và điểm mạnh của mình không chỉ đòi hỏi kiến thức mà còn đòi hỏi khả năng tưởng tượng nữa. Tôi mong bạn có thể rút tỉa ra được những điều bổ ích và lý thú của loạt "ký sự" này để tự ứng dụng cho môi trường của mình.

Liệu loạt "ký sự" này có tiếp tục hay không? Tôi không rõ. Hy vọng là không nếu không có biến cố gì đáng phân tích.

Chúc bạn một Noel và một năm 2005 vui tươi.

Chú thích:
-55- tôi dùng laptop của công ty và chỉ có thể duyệt web bằng Internet Explorer. Ctl-F5 là để buộc trình duyệt lấy phiên bản mới nhất từ web server thay vì dùng một bản đã được cached ở đâu đó. Tương phản với F5, trình duyệt chỉ dùng bản đã được cached.

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