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

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 3

[Article] Ký sự các vụ DDoS đến HVA - Phần 3	21/06/2006 20:00:50 (+0700) \| #1 \| 590

prof
Moderator

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

Sáng 12/10
Sáng nay công việc có phần thư thả hơn mọi ngày, tôi quyết định log vào server HVA để bắt đầu xem xét cẩn thận cấu hình kernel / firewall / web server xem thử cần phải làm gì để "trị" căn bệnh x-flash này. Tôi quên bẵng là firewall / proxy của công ty không cho phép đi thẳng đến cổng 22 -12-, bây giờ mới đớ người ra vì không vào HVA server được. Tôi đã "bị" kẹt vụ này đã lâu cho nên phải biến cổng SSH trên firewall riêng ở nhà từ 22 thành 443 vì firewall của hãng chỉ cho truy cập đến cổng 80 và 443 (xuyên qua proxy dùng HTTP CONNECT), nhưng đây là chuyện khác, không khéo tôi lại lạc đề ở đây. Sau vài phút trầm ngâm, tôi nảy ra ý tạo tunnel từ máy của mình đến firewall riêng ở nhà rồi mới tạo ssh connection từ máy của mình đến HVA server xuyên qua tunnel này. Biết rằng "tunnel trong tunnel" -13- chắc là chuối lắm vì chậm, nhưng không còn cách nào khác.

Sau một phút thử nghiệm, tôi thử:
Code:

$ ssh localhost -p 25250

(localhost của tôi lắng nghe trên cổng 25250 và forward thông tin đến firewall riêng của tôi ở nhà, từ đó nó mới đi đến HVA server). Ái chà, nó chạy! Hơi chậm một tí nhưng không sao cả. Tôi mở thêm một console khác cũng xuyên qua tunnel này. Tốt rồi, hai cái shell là đủ làm việc.

Tôi tìm hồ sơ mà tôi đã hí hoáy ghi xuống chằng chịt ngày hôm trước rồi rà xuyên qua nó. Đây rồi Hơn 15 ngàn request đến HVA server mỗi ngày. Tập trung khoảng 8 giờ đến 10 giờ tối VN, cao điểm là 9 giờ. Từ 8 giờ đến 10 giờ tối có độ chừng 10 ngàn đến 12 ngàn x-flash requests. Có khoảng 1 truy cập hợp lệ cho mỗi 30 giây (HTTP GET, HTTP POST) của các thành viên duyệt diễn đàn khi diễn đàn đông nhất. Cứ cho là trong 2 giờ cao điểm này có 12 ngàn x-flash requests đến HVA server, số "lẻ tẻ" còn lại không đáng kể.

(12000 requests / 120 phút) / 60 giây = 1.6 request mỗi giây

Nói về mặt tần số truy cập thì đây là một con số khá cao. Dựa trên số liệu thành viên truy nhập diễn đàn và gởi / xem bài một cách hợp thức và bình thường (lấy từ log của web server) xấp xỉ:

(200 thành viên sign-in mỗi giờ / 60 phút) / 60 giây = 0.05 request mỗi giây

So sánh hai con số trên thì tần số "truy cập" bất hợp lệ (x-flash) gấp 32 lần tần số truy cập hợp lệ. Kinh nhể?
Câu hỏi cũng như câu trả lời ở giai đoạn này trở nên quá hiển nhiên:
- hỏi: vô hiệu hoá các truy cập bất hợp lệ ra sao đây? trả lời: giới hạn các truy cập bất hợp lệ.
- hỏi: vậy giới hạn là giới hạn thế nào? trả lời: hèm... cái này thì đang tính toán đây.

Phải hình thành một công thức để tạo giá trị trung bình của một kết nối bình thường và từ đó mới có thể hình thành giới hạn hợp lý được. Vì HTTP là một giao thức có tính stateless -14- cho nên, thông tin giữa client (trình duyệt) và server (web server) thường được kết thúc càng nhanh càng tốt và connection này sẽ được tắt bỏ sau khi quy trình chuyển gởi thông tin hoàn tất. Tuy nhiên, trong quá trình chuyển đổi, giữa client và server sẽ mở thêm các connection nếu dữ liệu được truyền quá lớn hoặc cần chuyển tải thông tin nhanh chóng. Mục đích là để đẩy thông tin đi đến client (hoặc server) càng nhanh càng tốt (HTTP GET và HTTP POST). Hãy xem thử một x-flash stream xem sao. Tôi điều chỉnh hai console đã được kết nối vào HVA server cho chúng nằm song song. Trên console thứ nhất tôi "tail" web server log của HVA, trên console thứ nhì tôi chạy netstat. À ha, có vài chú x-flash đang đi vào, tôi lấy ngay IP đang hiển thị trên console theo dõi log của web server và chuyển sang console có chứa netstat. Hãy thử IP 221.132.39.253 xem sao:
Code:

[root@hvaonline httpd]# netstat -nat | grep 221.132.39.253
tcp        0      0 192.168.1.100:80        221.132.39.253:4548      SYN_RECV
tcp        0      1 192.168.1.100:80        221.132.39.253:4544      LAST_ACK
tcp        0    723 192.168.1.100:80        221.132.39.253:4545      ESTABLISHED
tcp        0    723 192.168.1.100:80        221.132.39.253:4546      ESTABLISHED
tcp        0    723 192.168.1.100:80        221.132.39.253:4547      ESTABLISHED
tcp        0      0 192.168.1.100:80        221.132.39.253:4523      TIME_WAIT
tcp        0      0 192.168.1.100:80        221.132.39.253:4526      CLOSE_WAIT
tcp        0      0 192.168.1.100:80        221.132.39.253:4527      CLOSE_WAIT
tcp        0      0 192.168.1.100:80        221.132.39.253:4494      TIME_WAIT
tcp        0      0 192.168.1.100:80        221.132.39.253:4504      TIME_WAIT
tcp        0      0 192.168.1.100:80        221.132.39.253:4505      TIME_WAIT

Cha chả, chú 221.132.39.253 này tham lam quá nhỉ? một mình chú đã có đến những 3 cái "ESTABLISHED", lại thêm 1 cái "SYN_RECV" và một mớ "CLOSE_WAIT", "TIME_WAIT". Dựa trên thông tin của hình minh hoạ ở trên thì "thái độ" tham lam này hoàn toàn phù hợp, bởi lẽ, một HTTP POST có payload đến trên 2 ngàn bytes thì nó phải đòi mở thêm connection để "đẩy" dữ kiện đến HVA server càng nhanh càng tốt mà (bạn có để ý đến chi tiết ACK-PSH của TCP segment chứa HTTP POST đã nói trong bài trước không?). Tôi tiếp tục theo dõi thì thấy chú 221.132.39.253 có đến những tám cái "ESTABLISHED" cả thảy trong suốt quá trình chú hối hả POST lên server của HVA, điều này có nghĩa là có ít nhất 8 cái SYN đã gởi đến HVA server và vì nó là legitimate request (yêu cầu truy cập hợp pháp) cho nên HVA server không hề cản mà cho chúng đi xuyên qua các bước TCP handshake rồi đi đến tình trạng "ESTABLISHED". Có thể 8 cái "ESTABLISHED" này không dành riêng cho một stream mà có ai đó cũng dùng chung cái IP này để truy cập HVA server. Có lẽ đường dẫn giữa IP này và HVA server hơi chuối, cũng có lẽ chính chú bị nghẽn vì đồng đội của chú cũng đang hối hả flood HVA, cho nên, chú phải đòi mở nhiều connection đến HVA server đến như vậy. Như vậy, tổng số socket cần mở ra cho chú 221.132.39.253 và đồng đội của chú (từ nhiều IP khác) cho tất cả các stream sẽ lớn lắm đây. Cứ cho rằng mỗi stream chứa HTTP POST mở ra 6 connections, chúng ta có:
Code:

( 12000 requests tạo ) 12000 streams x 8 sockets = 72000 connections (cho mỗi giờ).
( 72000 connection / 120 ) / 60 = 10 connections cho mỗi giây.

Ôi giời ơi, sao mà kinh thế? Cho dù SYN state thoát ra rất nhanh, cho dù ESTABLISHED state chỉ chiếm vài giây nhưng hậu quả của mớ "TIME_WAIT" và "CLOSE_WAIT" sau khi "ESTABLISHED" tắt bỏ thật sự mới khinh khủng.

Tôi càng tin tưởng vào ý định dùng giới hạn connection thay vì giới hạn packet rate -15-. Lý do hết sức đơn giản: người dùng bình thường chỉ cần 4 connections là nhiều (tôi phỏng đoán với nội dung thông thường của 1 trang trên HVA forum). Chỉ có những chú "x-flash" tham lam kia mới cần hơn 4 connections vì HTTP POST chứa payload quá lớn.

Để bảo đảm, tôi dùng chính trình duyệt của mình để thử truy cập vào một trang trên diễn đàn HVA. Hèm, hãy thử netstat trên một console xem sao:
Code:

[root@hvaonline root]# netstat -nat | grep xxx.xx.xxx.98
tcp        0      0 192.168.1.100:80        grep xxx.xx.xxx.98:9322      SYN_RECV
tcp        0      1 192.168.1.100:80        grep xxx.xx.xxx.98:9313      LAST_ACK
tcp        0    198 192.168.1.100:80        grep xxx.xx.xxx.98:9307      ESTABLISHED
tcp        0    198 192.168.1.100:80        grep xxx.xx.xxx.98:9306      ESTABLISHED
tcp        0      0 192.168.1.100:80        grep xxx.xx.xxx.98:9303      TIME_WAIT
tcp        0      0 192.168.1.100:80        grep xxx.xx.xxx.98:9288      CLOSE_WAIT
tcp        0      0 192.168.1.100:80        grep xxx.xx.xxx.98:9292      TIME_WAIT

Rất tiếc tôi phải xoá cái IP của mình và thay thế bằng xxx.xx.xxx.98 vì IP này là IP toàn thời (tôi muốn ăn ngon, ngủ yên nên không thể tiết lộ IP của mình). Trở lại câu chuyện chính, bất chấp tôi vào trang nào, bất chấp trang ấy có nhiều hay ít thông tin, tôi không hề thấy có hơn 4 connection hiện diện cho mỗi lần. Tôi cũng thử lệnh netstat ngay trên máy con của mình và xác nhận được điều này. Phần lớn là 3 connections cho mỗi lần, ngoại trừ trang nào lớn lắm thì mới thấy có 4 connections nhưng tỉ lệ này chỉ 1/100 (xấp xỉ 100 lần duyệt mới có một lần). Một chi tiết đáng nêu ra nữa là: thời gian một socket nằm ở vị trí "ESTABLISHED" chưa bao giờ lâu hơn 2 giây, phần lớn chỉ 1/2 giây hoặc 1 giây là tối đa. Điều này giúp chúng ta rút ra vài điều rất lý thú:
- mỗi trình duyệt cần tối đa 4 connection để duyệt 1 trang.
- 4 connections này không ở tình trạng "ESTABLISHED" cùng 1 lúc, chỉ tối đa 2 sockets ở tình trạng "ESTABLISHED" cho mỗi lần.

Giả sử 200 thành viên của HVA đang có mặt trên diễn đàn và cho rằng có 1/10 số lượng người đang bấm vào một số trang nào đó (đây là trường hợp cực đoan vì theo thông tin của web server log, thì trung bình mỗi 30 giây có một "GET" trong khoảng thời gian server bận rộn), và số lượng 1/10 này ít nhất là dùng 5 IP (5 proxy khác nhau) để truy cập HVA server:
(( 200 / 10) x 2 "ESTABLISHED" smilie

/ 1 giây = 40 "ESTABLISHED"
40 "ESTABLISHED" / 5 IP = 8 "ESTABLISHED" connections là số connection hợp lệ cho mỗi IP tại bất kì thời điểm nào.

8 "ESTABLISHED" connections tối đa cho mỗi IP một lần, con số này trông rất vừa phải. Nếu quy định cho firewall chỉ cho phép tiếp nhận tối đa 8 connections đến web server một lần thì nó đã dư sức phục vụ cho 200 thành viên có mặt trên diễn đàn cùng một lúc. Đó là chưa kể trường hợp khi một thành viên thứ nhất cần duyệt 1 trang nào đó, nếu nó bị xếp vào dạng quá connection thì trình duyệt của thành viên ấy sẽ tiếp tục gởi request đến HVA server để "thử lại", cơ hội "thử lại" lần thứ nhì này tạo connection trong phạm vi giới hạn 8 connections rất cao. Đối với người dùng bình thường, sự chậm trễ do "thử lại" này chỉ là một chậm trễ rất nhỏ. Tại sao tôi chọn tình trạng TCP "ESTABLISHED" để biểu thị cho "connection"? -16- lý do rất đơn giản là một kết nối đã đi đến tình trạng "ESTABLISHED" thì kết nối đó đã thành công, đã có thông tin qua lại giữa 2 đầu. Phải đi qua được giai đoạn TCP handshake thành công thì mới đến tình trạng "ESTABLISHED".

Cũng nên đào sâu thêm một tí về giới hạn 8 connections đã nêu ra ở trên về mặt logic. Giả sử chúng ta đã hình thành chế độ firewall được ấn định cho phép truy cập đến HVA web server từ bất cứ nơi đâu, miễn sao mỗi IP chỉ được phép dùng tối đa là 8 connections. 8 connections này có dạng na ná như một loại connection pools. Ví dụ, IP 203.162.5.100 là IP của một proxy server nào đó, đằng sau IP này có 10 người đang dùng để truy cập HVA server:
- người dùng thứ nhất chiếm 3 connections (nếu truy cập bình thường như tôi đã thử từ trình duyệt của tôi ở trên) --> "pool" còn lại 5 connections
- người dùng thứ hai chiếm 3 connections --> trong khi đó, người dùng thứ nhất đã trả lại 2 connection --> (5 + 2) - 3 = "pool" còn lại 4 connections
- ngay khi người thứ ba chiếm 3 connection nữa thì 3 connections của người dùng thứ nhất đã hoàn thành và đã trả lại 1, người dùng thứ hai trả lại 2 --> (4 + 2 + 1) - 3 = "pool" còn 4 connections

Và cứ thế mà xoay tròn. Đây là nói theo tình trạng truy cập sequential (theo chu trình) hết người này đến người khác, còn nếu tình trạng truy cập đồng thời thì sao? Cũng 10 người dùng proxy trên để truy cập HVA server:
- hai người 1 và 2 cùng truy cập một lúc, chiếm 6 connections --> "pool" còn 2 connections
- người thứ 3 và 4 kế tiếp cùng truy cập, chiếm 6 connections --> 1 và 2 ở trên trả lại ít nhất 4 connections --> (4 + 2) - 6 = "pool" còn 0 connection
- người thứ 5 và 6 cùng truy cập, chiếm 6 connections --> 1 và 2 trả lại hết các connection còn lại (2), 3 và 4 trả lại ít nhất 4 connections --> (2 + 4) - 6 = "pool" còn 0 connection
Theo phân tích trên, ngay cả trường hợp 2 người dùng cùng truy cập một lượt và dùng chung 1 IP (1 proxy server) để truy cập thì vẫn không bị ảnh hưởng gì từ chế độ cản của firewall (với ấn định tối đa 8 connections).

Nếu như kế tiếp có người thứ 7, 8 và 9 cùng truy cập thì sao? Chắc chắn là thiếu 2 connection. Tuy nhiên, anh chàng nào hơi chậm chân một tí thì trình duyệt sẽ "retry" ngay sau đó và khi "retry" packet này đụng đến server thì cơ hội có connection để vào rất cao vì khi ấy người thứ 3, 4, 5, 6 đã trả lại một loạt connection rồi. Đối với người dùng bình thường, đây là một "delay" rất nhỏ và có thể tiếp nhận được. Trên thực tế, chuyện này hiếm xảy ra. Theo thông tin đã thâu thập được từ log của web server thì cứ 30 giây mới có một xuất truy cập mới. Quy định 8 connections một lúc cho mỗi IP thật sự còn quá thư giãn so với hoàn cảnh thực tế. Tuy nhiên, cứ tạm dùng con số này làm điểm khởi đầu rồi chỉnh sửa sau vậy.

Vậy nếu HVA server bị "flood" liên tục và chiếm hết connections, làm cho người dùng bình thường không vào được thì sao? Đây là điểm đòi hỏi phải chỉnh sửa các thông số tcp/ip trên kernel để điều tiết cho thích hợp hơn. Nếu các giá trị ấn định cho tcp/ip cho phép "backlog" -17- thì vẫn giải quyết được trường hợp bị "flood". Tất nhiên là máy con truy cập sẽ bị chậm hơn nhưng vẫn còn tốt hơn là hoàn toàn bị "từ chối". Một ưu điểm rất lớn mà tôi tìm thấy được qua nhiều lần "táy máy" là trong trường hợp bị "flood", backlog queue này còn giúp cho IDS (Intrusion Detection System) kịp thời gởi gói tin xử lý đến những gói tin vi phạm với hiệu quả cao hơn-18-.

Dựa trên những điểm đã phân tích ở trên, tôi thấy rõ phương pháp dùng "connection pool" ở trên có hai điểm ưu việt hơn dùng phương pháp packet rates:
- giới hạn connection tính theo biên độ và trường độ truy cập cho phép người dùng có thể truy cập với băng thông tối đa và loại bỏ những truy cập "tham lam", không thực tế.
- với giới hạn này, nó giúp giới hạn tài nguyên cho máy chủ (và những bộ phận gắn liền với máy chủ), ví dụ như backend database chẳng hạn. Connection limit bảo đảm tối đa chỉ có 8 xuất query đến database một lần nếu những connection này đụng chạm đến database server (nên nhớ: truy nhập và lấy dữ kiện từ database tốn tài nguyên hơn bất cứ giai đoạn nào khác trên hệ thống).

Trong khi đó, packet rate giới hạn số packets trong một đơn vị thời gian nào đó, cái này chỉ làm chậm mọi quy trình lại nhưng không áp đặt một giới hạn nào rõ ràng. Nếu dùng packet rate, số xuất truy cập vào database có thể lên đến số lượng đã áp đặt trên chính cấu hình database mà thôi và đây là điều rất kẹt vì rất tốn kém tài nguyên của máy chủ. Đến một mức độ nào đó, đường truyền sẽ bị dung hoà (saturated) và các client hợp pháp sẽ vào được nhưng cực kỳ chậm nhưng để đạt tới mức độ này, ít nhất đường truyền dùng để tấn công phải hơn đường truyền của máy chủ HVA ít nhất là 3 lần. Giới hạn connection bảo đảm một điều tối quan trọng, cho dù máy chủ bị "flood" cỡ nào cũng không thể "giết" được nó.

Được rồi, hãy quyết định khai triển hướng giới hạn connection trước để cắt bỏ phần lớn khối 20 connections / 1 giây của các con bọ "x-flash" kia trước rồi tiếp tục khai triển bước "triệt tiêu" chúng hoàn toàn sau.

Chuyển sang console thứ nhất đã được kết nối vào HVA server, tôi chạy một loạt lệnh để kiểm tra:
Code:

# lsmod

Hèm... không thấy mấy cái modules mình muốn, hẳn là như vậy vì module mình muốn đâu nằm trong "base modules" của kernel.
Code:

# ls /proc/sys/net/ipv4/netfilter

Hèm... quả thật mấy cái modules mình muốn chưa hề có trong kernel, cũng nên xác định cho rõ.
Code:

# sysctl -a | grep net

Whoa... đa số là giá trị mặc định, chi tiết này phải ghi xuống để chỉnh lại sau, không thì quên nữa.
Code:

# iptables -L -v | more

Nhìn ok nhưng... còn thắt lại được nhiều lắm.

Chà chà, lão JAL và mấy lão BQT "hiền" quá, mấy cái rules này của firewall không dễ để "đột phá" nhưng nó có quá ít ảnh hưởng đến mớ x-flash quái đản kia. "Packet rate" cũng đã áp đặt nhưng với tần số 1.6 request / 1 giây thì.... bó tay, hơn nữa, áp đặt này chỉ làm cho bà con thành viên truy cập vào diễn đàn chậm hơn. Kernel hiện tại cần thiết lập vài modules quan trọng để thực sự giới hạn truy cập. Tôi chưa muốn xem xét các tầng cao hơn vì kế hoạch mà tôi đã hình thành trong đầu là: thắt từ dưới lên và hiện nay tôi đang ở tầng dưới cùng trong các tầng giao thức, những tầng kia sẽ xét sau.

Tôi gởi ngay cho JAL một PM về việc tái biên dịch kernel để thêm vài modules quan trọng cho kernel cũng như loại bỏ nhiều modules không cần thiết. Mười lăm phút trôi qua, rồi một giờ trôi qua. Chà, sao không thấy tăm hơi lão JAL đâu nhỉ? Tôi quyết định bắt tay vào thực hiện ý định của mình rồi sẽ thông báo để lão tái khởi động máy sau vậy.

Tôi dùng wget, tiện ích tôi rất ưa thích để lấy mã nguồn của kernel và các bản vá cần thiết. Trong khi wget tải những thứ lỉnh kỉnh kia về, tôi vi ngay hồ sơ cấu hình biên dịch của kernel (tiết kiệm thời gian mà lị). Hèm.... mười lăm phút đầy những Y, N và M trên một hồ sơ cấu hình biên dịch của kernel, hơi oải... nhưng biết sao hơn? Băng thông khá tốt nên mới sau vài phút thì những thứ tôi cần đã được tải hết về máy. Tôi xả nén mã nguồn kernel, vá và bắt tay vào chuyện biên dịch.

Tôi rà kỹ qua hồ sơ cấu hình biên dịch kernel một lần cuối... ok, mọi chuyện đâu vào đó. Một, hai, ba... chạy. Hơn ba mươi phút trôi qua với hàng loạt thông điệp chạy vi vút trên màn hình. Kinh khủng, kinh khủng, kernel được biên dịch xong dưới ba mươi lăm phút, đúng là dual CPU có khác, đây là không kể đến hoàn cảnh server hiện nay đang phải dùng sức để đối phó với đám loạn quân "x-flash" kia. Kernel đã xong nhưng vẫn chưa thấy tăm hơi lão JAL đâu. Thôi vậy, để xem thêm thử có gì khác cần phải làm nhưng chắc để lúc khác, đã đến lúc phải giải quyết vài công chuyện ở sở không thì bê trễ cả ra.

Sáng 13/10
Đang trên tàu lửa trên đường đi làm, tôi trầm ngâm lượt qua các chi tiết đã phân tích hôm qua. Vẫn chưa thấy JAL hồi đáp, cha chả, lão này đi chơi đâu mà bặt vô âm tín vậy nhỉ? Tôi chợt nhớ là kernel đã tái biên dịch xong nhưng firewall rules mới chưa hề có một mảnh. Tôi mở laptop lên, phóng ngay chú "vim" lên màn hình và bắt đầu gõ.

Tôi khá chắc là HVA cần dùng bấy nhiêu dịch vụ nên tôi quyết định dùng kiểu block function (hàm theo nhóm) để hình thành các phần logic của firewall rules. Ba mươi lăm phút trôi qua, chà tôi phải đổi sang chuyến tàu thứ nhì (tôi cần phải đổi tàu 2 lần mới đến sở làm). Nhìn xuyên qua đoạn script, tôi khá hài lòng vì nó đã gần như hoàn tất, chỉ cần điểm xuyết thêm, thắt chặt dăm ba điểm và tạo một số thông điệp thông báo khi chạy firewall script (để lão nào chạy nó thì còn biết chuyện gì xảy ra). Rất tiếc tôi không thể trình bày chi tiết firewall rules này có những gì ở đây vì lý do... bảo mật.

Lên chuyến tàu thứ nhì, tôi mở laptop ra và tiếp tục hoàn tất những thứ đã dự định trong đầu. Tôi ngẩng lên nhìn đồng hồ, chà! còn đến 15 phút nữa mới đến sở. Tôi quyết định rà lại từng dòng một trên cái firewall script. Mèn... tưởng đã hoàn chỉnh, hoá ra rà qua lại "nẻ" ra lỗi, rà lại cũng "nẻ" ra lỗi. Còn 10 phút... tôi nảy ra ý định tạo thêm một lớp safe-guard (bảo kê) cho mỗi truy cập đến dịch vụ đã được cho phép. Xong xuôi, tôi khá hài lòng vì sáu mươi phút đồng hồ trôi qua khá bổ ích. Thôi được, thử upload cái script này lên và chạy thử trên HVA server xem sao. Nếu có gì kẹt thì "đì bấc" tại chỗ chớ làm sao hơn được?

Sau mấy giờ đồng hồ liên tục làm việc, tôi đã hoàn tất cả đống công việc. Giờ này lão JAL bên Nhật chắc cũng đã có mặt ở sở, để xem lão có hồi báo gì không. Tôi log vào diễn đàn, khè khè "Bạn có 3 PM", chắc là của lão JAL chớ không ai vào đây. Quả thật, lão JAL "mê" chơi đâu quá nên tối hôm qua về trễ. Tôi upload cái firewall script lên HVA server, xem xét mọi thứ một lần nữa. Rồi, gởi cho JAL một cái PM thông báo chuyện khởi động lại server.

Lão JAL hồi đáp trong tích tắc. Lão cho biết sẽ khởi động server lúc "vắng vẻ" một tí. Mèn.... sau vài phút cái SSH console của tôi chợt báo "socket error", lão JAL này nói "đợi khi nào server vắng vẻ một tí rồi restart" vậy mà làm liền vậy sao cà? Quả thật lão "làm liền". Chưa đầy 2 phút sau, tôi hối hả thử log vào HVA server, vào được ngay! Tôi phóng ngay mấy cái lệnh:
Code:

# less /var/log/boot
# lsmod
# /usr/local/sbin/iptables -L -v | more 
# tail -f /var/log/messages

"I can't believe it", tôi thốt lên một mình. "First hit wonder!" tôi lẩm nhẩm tiếp. Firewall chạy như ý muốn ngay lần đầu tiên. Mọi chuyện đều ổn từ kernel lên tới firewall và các dịch vụ khác (Vậy mà ngày hôm ấy lão thần bài phát hiện ngay ra một lỗi, lỗi gì vậy lão thần bài? ). Nhìn cái "đuôi"
Code:

# tail -f /var/log/messages

tôi muốn ngộp thở:
Code:

Oct 13 07:12:44 hvaonline kernel: OVERCONNLIMIT: IN=eth0 OUT= SRC=221.132.49.131 DST=192.168.1.100 LEN=48 TOS=0x00
PREC=0x00 TTL=113 ID=22369 DF PROTO=TCP SPT=50257 DPT=80 WINDOW=64240 RES=0x00 SYN URGP=0
Oct 13 07:12:44 hvaonline kernel: OVERCONNLIMIT: IN=eth0 OUT= SRC=221.132.49.131 DST=192.168.1.100 LEN=48 TOS=0x00
PREC=0x00 TTL=113 ID=22379 DF PROTO=TCP SPT=50258 DPT=80 WINDOW=64240 RES=0x00 SYN URGP=0
Oct 13 07:12:44 hvaonline kernel: OVERCONNLIMIT: IN=eth0 OUT= SRC=203.113.160.94 DST=192.168.1.100 LEN=48 TOS=0x00
PREC=0x00 TTL=111 ID=7049 DF PROTO=TCP SPT=2370 DPT=80 WINDOW=64240 RES=0x00 SYN URGP=0
Oct 13 07:12:44 hvaonline kernel: OVERCONNLIMIT: IN=eth0 OUT= SRC=221.132.49.131 DST=192.168.1.100 LEN=48 TOS=0x00
PREC=0x00 TTL=113 ID=22381 DF PROTO=TCP SPT=50257 DPT=80 WINDOW=64240 RES=0x00 SYN URGP=0
Oct 13 07:12:45 hvaonline kernel: OVERCONNLIMIT: IN=eth0 OUT= SRC=221.132.49.131 DST=192.168.1.100 LEN=48 TOS=0x00
PREC=0x00 TTL=113 ID=22382 DF PROTO=TCP SPT=50258 DPT=80 WINDOW=64240 RES=0x00 SYN URGP=0
Oct 13 07:12:45 hvaonline kernel: OVERCONNLIMIT: IN=eth0 OUT= SRC=203.113.160.94 DST=192.168.1.100 LEN=48 TOS=0x00
PREC=0x00 TTL=111 ID=7070 DF PROTO=TCP SPT=2370 DPT=80 WINDOW=64240 RES=0x00 SYN URGP=0
Oct 13 07:12:45 hvaonline kernel: OVERCONNLIMIT: IN=eth0 OUT= SRC=203.113.135.196 DST=192.168.1.100 LEN=48 TOS=0x0
0 PREC=0x00 TTL=110 ID=43299 PROTO=TCP SPT=42913 DPT=80 WINDOW=16384 RES=0x00 SYN URGP=0
Oct 13 07:12:45 hvaonline kernel: OVERCONNLIMIT: IN=eth0 OUT= SRC=203.113.135.196 DST=192.168.1.100 LEN=48 TOS=0x0
0 PREC=0x00 TTL=110 ID=43764 PROTO=TCP SPT=42913 DPT=80 WINDOW=16384 RES=0x00 SYN URGP=0

Vâng vâng và vâng vâng..... Chuyện gì đây? Hồi sau sẽ rõ smilie

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

Chú thích:
-13- Bạn có thể tạo secure tunnel (đường ống) từ máy của mình đến một máy chủ nào đó bằng cách dùng SSH. Bên trong tunnel này, các thông tin chuyển lưu hoàn toàn được mã hoá. Tuy chậm nhưng khá an toàn nếu dùng SSH2. Nếu thích bạn nên thử đọc tài liệu và tải software từ openssh ở http://www.openssh.org.

-14- HTTP là một giao thức stateless, sau khi thông tin giữa hai đầu server và client hoàn tất, connection này được tắt bỏ.

-15- Giới hạn connection là giới hạn bao nhiêu sockets được mở ra để phục vụ một IP nào đó. Ví dụ, tối đa 4 connections từ một IP nào đó. Nếu IP này "đòi" mở thêm 1 connection thứ 5 thì connection này bị loại bỏ.
Giới hạn packet rates là giới hạn số packet được truyền tải trong một đơn vị thời gian nào đó. Ví dụ: giới hạn 100 packets / 1 giây từ một IP nào đó chỉ cho phép server nhận tối đa là 100 packets 1 giây, packet thứ 101 trở đi sẽ bị loại bỏ.

-16-Tôi dùng thuật ngữ "connection" ở đây là để chỉ chung cho các giai đoạn: SYN từ client, SYN-ACK từ HVA server, ACK-ACK từ hai đầu client và HVA server và sau đó là ACK-PSH hay bất cứ gì khác từ client cho đến khi "ESTABLISHED" trở thành "TIME_WAIT". Giới hạn connection ở đây thật sự là giới hạn SYN. ESTABLISHED chỉ dùng để biểu thị connection đã hình thành một cách hợp lệ và đúng quy định mà thôi. Nếu truy cập từ cùng một IP mà quá giới hạn 8 "connections", có nghĩa là SYN vẫn được gởi nhưng nếu hiện đã có 8 ESTABLISHED connections thì SYN đứng đó chờ hoặc SYN bị huỷ. ESTABLISHED dùng để đo lường số connection hiệu hữu và SYN dùng để cản (hoặc cho phép) các truy cập tiếp theo dựa trên số connection đã hiện hữu

-17- "backog" là số lượng công việc bị dồn ứ lại. Với TCP connections, ví dụ nếu chỉ định 100 "backlog" chẳng hạn thì gói SYN thứ 101 trở đi sẽ bị hủy bỏ, dẫn đến tình trạng người dùng không truy cập được. Nếu chỉnh định 10000 "backlog" thì vẫn tạo cơ hội cho các truy cập đang đợi có thể vào thay vì bị huỷ.

-18- Hầu hết các IDS hiện đại đều có khả năng tác ứng đến các gói tin mang tính vi phạm. Riêng trong trường hợp này, tôi dùng snort vì nó miễn phí. Nó có thể gởi nhiều gói RST đến cả client lẫn server cùng một lúc để "xé" ngang đường nối hiện hữu giữa client và server.

Cập nhật:
10/11/2004: chỉnh sửa các chi tiết tính toán bị sai lẫn do mrro tìm thấy trong bài tường trình và thêm chi tiết giải thích cho khái niệm "connection".

[Article] Ký sự các vụ DDoS đến HVA - Phần 3	24/05/2010 13:08:40 (+0700) \| #2 \| 211534

huyente
Member

Joined: 15/07/2007 18:34:33
Messages: 22
Offline

prof wrote:

Sáng 12/10
Sáng nay công việc có phần thư thả hơn mọi ngày, tôi quyết định log vào server HVA để bắt đầu xem xét cẩn thận cấu hình kernel / firewall / web server xem thử cần phải làm gì để "trị" căn bệnh x-flash này. Tôi quên bẵng là firewall / proxy của công ty không cho phép đi thẳng đến cổng 22 -12-, bây giờ mới đớ người ra vì không vào HVA server được. Tôi đã "bị" kẹt vụ này đã lâu cho nên phải biến cổng SSH trên firewall riêng ở nhà từ 22 thành 443 vì firewall của hãng chỉ cho truy cập đến cổng 80 và 443 (xuyên qua proxy dùng HTTP CONNECT), nhưng đây là chuyện khác, không khéo tôi lại lạc đề ở đây. Sau vài phút trầm ngâm, tôi nảy ra ý tạo tunnel từ máy của mình đến firewall riêng ở nhà rồi mới tạo ssh connection từ máy của mình đến HVA server xuyên qua tunnel này. Biết rằng "tunnel trong tunnel" -13- chắc là chuối lắm vì chậm, nhưng không còn cách nào khác.

Sau một phút thử nghiệm, tôi thử:
Code:
$ ssh localhost -p 25250
(localhost của tôi lắng nghe trên cổng 25250 và forward thông tin đến firewall riêng của tôi ở nhà, từ đó nó mới đi đến HVA server). Ái chà, nó chạy! Hơi chậm một tí nhưng không sao cả. Tôi mở thêm một console khác cũng xuyên qua tunnel này. Tốt rồi, hai cái shell là đủ làm việc.

Đoạn màu cam là SSH local port forwarding phải không anh?
Code:

ssh user@Home_IP -L 25250:HVA_IP:22

[Article] Ký sự các vụ DDoS đến HVA - Phần 3	08/12/2010 02:44:16 (+0700) \| #3 \| 226621

quanta
Moderator

Joined: 28/07/2006 14:44:21
Messages: 7265
Location: $ locate `whoami`
Offline

conmale wrote:

...
Cứ cho rằng mỗi stream chứa HTTP POST mở ra 6 connections, chúng ta có:

( 12000 requests tạo ) 12000 streams x 8 sockets = 72000 connections (cho mỗi giờ).
( 72000 connection / 120 ) / 60 = 10 connections cho mỗi giây.

Chỗ này là nhân 6 và cho mỗi 2 giờ chứ anh nhỉ.

conmale wrote:

...
Được rồi, hãy quyết định khai triển hướng giới hạn connection trước để cắt bỏ phần lớn khối 20 connections / 1 giây của các con bọ "x-flash" kia trước rồi tiếp tục khai triển bước "triệt tiêu" chúng hoàn toàn sau.

10 connections / 1 giây chứ anh.

conmale wrote:

Còn 10 phút... tôi nảy ra ý định tạo thêm một lớp safe-guard (bảo kê) cho mỗi truy cập đến dịch vụ đã được cho phép.

Anh nói rõ hơn chỗ này giúp em với?

Let's build on a great foundation!

Go to:

Users currently in here
2 Anonymous