Nhiều lúc như là một nhà phân tích bảo mật, bạn sẽ thấy một số loại giao thông thú vị và mong muốn rằng bạn có thời gian hoặc động lực để điều tra nó hay hiểu nó tốt hơn. Bạn có một cơ hội tốt hơn của việc có thể làm điều này nếu bạn đang ở trong một vị trí nghiên cứu hơn là một môi trường hoạt động bận rộn nơi mà mục đích duy nhất của bạn là để đảm bảo rằng không có truy cập trái phép xảy ra.
Một trong những cơ hội để làm phân tích của một sự kiện quan tâm phát sinh tại một trang web nơi Shadow đã được sử dụng để chụp giao thông mạng.Các trang web là mục tiêu của một số hoạt động không giải thích được hướng tới cổng đích TCP 27.374, thường được sử dụng bởi SubSeven.
Lời giải thích và những phát hiện của giao thông mạng sẽ được thảo luận trong chương này. Khi chúng ta chứng kiến hoạt động này, chúng tôi đã có một cảm giác ruột mà chúng tôi đang nhìn thấy một cái gì đó duy nhất chỉ vì âm lượng tuyệt của nó. Chúng tôi sử dụng bản ghi TCPdump thu thập được của Shadow để phân tích các trường khác nhau và các khía cạnh của gói tin đi đến kết luận của chúng tôi. Đây là một nỗ lực đội ngũ thực hiện với sự giúp đỡ của đồng nghiệp Vern Stark và David Heinbuch.
Nghi ngờ của tôi là rất nhiều người hướng đến vị trí của các nhà phân tích bảo mật thích làm việc với những câu hỏi khó hiểu hoặc những điều huyền bí. Những bí ẩn của giao thông này đã được làm sáng tỏ một cách đơn giản bằng cách sử dụng chụp bản ghi TCPdump, lập trình Perl để xem xét và tóm tắt các khía cạnh khác nhau của giao thông, và Excel để phát hiện những âm mưu. Làm việc trên câu hỏi này không chỉ là một kinh nghiệm học tập tuyệt vời của việc đánh giá lưu lượng truy cập, và phục hồi sau khi thực hiện những giả định sai trái, nhưng nó cung cấp rất nhiều giải trí với một số đầu óc thực.
The Event in a Nutshell-Các sự kiện trong một Nutshell
một bộ cảm biến Shadow được đặt bên ngoài vành đai tường lửa phát hiện một một số lượng lớn các host nguồn đang quét mà những gì xuất hiện sẽ được không gian các địa chỉ lớp B của trang web cho cổng đích TCP 27374. Shadow phân tích truy hồi từng giờ của giao thông mạng cho các dị thường. Dị thường, hay chính xác hơn, các sự kiện quan tâm, được tiêu huỷ bằng cách chạy trước giờ giao thông được TCPdump thu thập qua một loạt các bộ lọc TCPdump. Một trong những bộ lọc tìm kiếm đã cố gắng kết nối TCP SYN từ bên ngoài mạng đến một máy chủ trong mạng.
TCP cổng đích 27374 được liên kết với một Trojan được gọi là SubSeven mà có thể cho phép truy cập vào máy của nạn nhân. Chúng tôi đã thấy rất nhiều máy quét lớn vào cổng SubSeven, tuy nhiên, chúng tôi chưa bao giờ nhìn thấy một máy quét mà tạo ra một khối lượng lưu lượng truy cập lớn-và chúng tôi cũng không thấy các lưu lượng đó đã đến từ nhiều nguồn cùng lúc.
Sự tương quan về các lưu lượng tương tự nhau
Khoảng cùng một thời điểm này quản trị mạng, mạng và Security (SANS) Internet Storm Center phát hành một tờ báo ngày 26 tháng 6 năm 2001 về một con virus có tên là Microsoft Windows W32.leave.worm. Các suy đoán rằng con virus này đã được sử dụng để làm cho máy chủ bị nhiễm độc một máy chủ tham gia, còn được gọi là zombie, trong phân phối từ chối dịch vụ (DDoS) tấn công. Theo báo cáo, sự lây lan virus thông qua các kết nối đến máy chủ lắng nghe trên cổng TCP 27374. Báo cáo lưu ý rằng virus đã quét khối mạng được xác định trước liên kết với @ Home và Earthlink cho cổng đích 27374. Tuy nhiên, nó không đề cập đến thực hiện đồng bộ quét, và cũng không đề cập đến chức năng quét của các mạng khác đã đề cập trước đây. Mặc dù hoạt động mô tả virus có vẻ khác với các hoạt động đã được chứng kiến tại trang web theo dõi, nó đã có thể là các hoạt động virus có đột biến kể từ khi có báo cáo ban đầu.
The Traffic
Đầu ra sau đây đại diện cho một số ít các bản ghi TCPdump cung cấp tổng quát “hương vị”của hoạt động này. Host nguồn và host đích được tô đậm. Đây là mười bản ghi đầu tiên liên quan đến hoạt động ngày 29 tháng 6, có bốn host nguồn khác nhau liên quan đến việc quét mười host đích khác nhau.
Các timestamps liên kết với các bản ghi cũng phải được xem cẩn thận. Bộ cảm biến mà chụp các bản ghi này đang chạy trên Redhat Linux 7.1 với một kĩ thuật bắt gói tin được gọi là turbopacket được biên dịch thành hạt nhân. Đây được cho là nội dung phương pháp cho bộ đệm hiệu quả hơn, nhưng nó cũng xuất hiện timestamp chính xác đã bị mất. Timestamps cần phải có độ trung thực tới micro giây, nhưng các timestamps này xuất hiện để có độ phân giải là 10-ms:
12:16:31.150575 ool-18bd69bb.dyn.optonline.net.4333 > 192.168.112.44.27374: S 542724472:542724472(0) win 16384 <mss 1460,nop,nop,sackOK> (DF) (ttl 117, id 13444) 12:16:31.160575 ool-18bd69bb.dyn.optonline.net.4334 > 192.168.112.45.27374: S 542768141:542768141(0) win 16384 <mss 1460,nop,nop,sackOK> (DF) (ttl 117, id 13445) 12:16:31.170575 24.3.50.252.1757 > 192.168.19.178.27374: S
681372183:681372183(0) win 16384 <mss 1460,nop,nop,sackOK> (DF) (ttl 117,id 54912)
12:16:31.170575 24-240-136-48.hsacorp.net.4939 >192.168.11.19.27374: S
39621) 12:16:31.170575 ool-18bd69bb.dyn.optonline.net.4335 > 192.168.112.46.27374: S 542804226:542804226(0) win 16384 <mss 1460,nop,nop,sackOK> (DF) (ttl 117, id 13446) 12:16:31.170575 cc18270-a.essx1.md.home.com.4658 > 192.168.5.88.27374: S 55455482:55455482(0) win 8192 <mss 1460,nop,nop,sackOK> (DF) (ttl 117, id 8953) 12:16:31.170575 24.3.50.252.1759 > 192.168.19.180.27374: S 681485650:681485650(0) win 16384 <mss 1460,nop,nop,sackOK> (DF) (ttl 117, id 54914) 12:16:31.170575 cc18270-a.essx1.md.home.com.4659 > 192.168.5.89.27374: S 55455483:55455483(0) win 8192 <mss 1460,nop,nop,sackOK> (DF) (ttl 117, id 9209) 12:16:31.170575 24.3.50.252.1760 > 192.168.19.181.27374: S 681550782:681550782(0) win 16384 <mss 1460,nop,nop,sackOK> (DF) (ttl 117, id 54915) 12:16:31.170575 cc18270-a.essx1.md.home.com.4660 > 192.168.5.90.27374: S 55455484:55455484(0) win 8192 <mss 1460,nop,nop,sackOK> (DF) (ttl 117, id 9465)
DoS hoặc Scan
Ban đầu, nó không được rõ ràng nếu điều này là một số loại DDoS hoặc một số loại máy quét phối hợp. Trong thời gian kiểm tra hoạt động, chúng tôi đã may mắn (từ quan điểm phân tích) để nhận được các hoạt động bổ sung vào 02 tháng 7 năm 2001 lúc 16:00 đó là điều đặc biệt. Sau khi chúng tôi nhận được lần quét thứ hai, chúng tôi bắt đầu một cách nghiêm túc xem xét các trường cá nhân tìm thấy trong các gói tin nhận được của hai tập hợp của các hoạt động để giải thích bản chất và mục đích của hoạt động này.
Source Hosts
Trong lần quét đầu tiên tổng số 132.706 gói tin đã nhận được và đã chỉ có 314 host nguồn bị liên lụy. Trong số những host này, chỉ có 17 host (khoảng 5,4 phần trăm) không có đăng ký tên host DNS. Trong quá trình quét thứ hai, tổng số 157.842 gói đã nhận được. Đã có 295 host nguồn khác thường với 24 (khoảng 8,1 phần trăm) với tên host chưa được giải quyết. Điều này đáng quan tâm. Hai sự lựa chọn phân loại host nguồn là chúng hoặc là phản ánh hoặc không phản ánh nguồn chính xác host nguồn đang gửi lưu lượng truy cập. Nếu host nguồn phản ánh người gửi thực tế, không thoái thác việc gửi các gói tin. Nếu host nguồn không phải là người gửi thực tế, một số IP nguồn giả mạo được đặt trong gói.
Thông thường, khi IP numbers nguồn được giả mạo, nó là sự phát sinh ngẫu nhiên của các IP number khác nhau trong trường hợp tràn. Cuộc tấn công khác có thể sử dụng một sự lựa chọn một hoặc nhiều IP numbers nguồn có thể là một cái bẫy hoặc một mục tiêu cuối cùng của một số loại. Khi host nguồn phản ánh đúng người gửi, mục đích có nhiều khả năng hơn là không thể nhận phản hồi từ traffic đã được gửi.
Do đó, nó xuất hiện rằng các hoạt động đó được xem là sử dụng các số IP nguồn chính thực. Nếu điều này là tràn và các IP nguồn bị bắt trước bằng cách sử dụng IP number được tạo ngẫu
nhiên, đó là thống kê không chắc xảy ra rằng các IP number này sẽ giải quyết những tên host từ 91,9 đến 94,6 phần trăm thời gian. Nó sẽ là bất thường, các IP number sẽ bị giả mạo bằng cách sử dụng một tập các IP number định trước giải quyết cho các tên host, bởi vì điều này có rất nhiều nỗ lực để đạt được.
Nó có thể được suy đoán rằng, vì số lượng tuyệt đối của host nguồn liên quan, chúng có thể đại diện cho các host dở sông dở chết bằng cách nào đó đã được khai thác và sở hữu. Nhiều trong số các mạng nguồn này có liên quan đến cáp modem hoặc các nhà cung cấp DSL như @Home và AOL. Chứng minh cho điều này các nghiên cứu về host zombie bởi vì người dùng gia đình có nhiều khả năng không biết các mối đe dọa an ninh và bảo vệ ít hơn so với hầu hết các mạng thương mại hoặc mạng lớn hơn với một số loại bảo vệ vành đai.
Destination Hosts
Tiếp theo, các phân tích di chuyển đến địa điểm kiểm tra của các host đích để cung cấp thêm dấu hiệu của một máy quét. Mạng được quét là Class B với 65.535 IP number khả năng để quét. Chỉ tiêu đầu tiên của máy quét 32.367 host đích và mục tiêu thứ hai quét 36.638 host đích. Phản ứng ban đầu khôngc ó căn cứ để các mạng con bị mất tích đã có một số thăm dò trước được thực hiện tới host mục tiêu hiện thời. Sau khi kiểm tra kỹ hơn các host đích, nó là hiển nhiên mà nhiều IP number đích đã được quét không có liên quan host hiện thời.
Lời giải thích chính đáng hơn cho các mạng con đích mất tích và các host đích là điểm đến có lẽ là zombie hay zombies đã được giao nhiệm vụ quét những mạng con bằng cách nào đó không hoạt động hoặc đáp ứng trong quá trình quét và đã không tham gia. Một host đích còn thiếu trong một subnet khác được quét có thể được hiểu như là một hủy bỏ gói tin ban đầu chứ không phải là một IP number đích bị bỏ qua.
Mặc dù một host nguồn duy nhất quét nhiều host đích, nhiều host nguồn quét một số host đích. Máy quét xuất hiện để có một số dư thừa máy quét để đảm bảo một phản hồi.
Scanning Rates
Một dấu hiệu của một máy quét chống flood là tốc độ quét của máy nguồn. Cả hai máy quét được duy trì một số kiểu hoạt động khoảngnăm hay sáu phút, tuy nhiên thời gian ramp-up nhanh và đã có sự bùng nổ của hoạt động trong hai phút đầu tiên. Các biện pháp đo băng thông như sau. Mỗi gói là một một gói tin TCP SYN với các tùy chọn và không payload.
Hầu hết các gói có độ dài 48 byte, một số ít có nhiều hơn, và một số ít đã có ít hơn 4 byte, tùy thuộc vào số lượng và loại tùy chọn TCP được sử dụng. Các gói tin có chuẩn 20-byte IP header không có tùy chọn IP. Bởi vì phần lớn các gói dữ liệu có độ dài 48 byte, điều này đã được sử dụng như độ dài gói tin cho việc tính toán về băng thông tiêu thụ. Bởi vì thông lượng hoặc băng thông được đo bằng bit / giây, độ dài gói tin được 384 (48 * 8) bits. (adsbygoogle = window.adsbygoogle || []).push({});
Vào ngày 29 tháng 6 máy quét đạt tỷ lệ tối đa 1.7Mbps lúc cao điểm. Lần quét thứ hai, ngày 02 tháng 7 đạt một tỷ lệ tối đa là 2.4Mbps lúc cao điểm. Điều này đã không ảnh hưởng xấu đến các trang web theo dõi, nhưng một trang web với một đường ống vào nhỏ như một T-1 với công suất 1.554Mbps có thể đã bị từ chối tạm thời của dịch vụ như là một tác dụng phụ của quá trình quét. Hình 11.1 cho thấy các bit/giây quét trong thời gian cao điểm.
Nhìn vào các hình vẽ trong hình 11.1 cùng một lúc, nó rõ ràng từ các đường viền chung mà tỷ lệ quét cho cả hai lần quét đã rất giống nhau. Trong thực tế, cả hai lần quét quét đạt đến tốc độ quét đỉnh cao chính xác 21 giây sau khi bắt đầu quét. Sau khi phát hiện ra, sau khi kiểm tra lưu lượng truy cập sử dụng khác nhau, hoạt động đỉnh cao này chỉ ra một số kiểu phối hợp của “người chỉ huy” những người được giao nhiệm vụ quét và đánh giá cho zombies.
Tốc độ cao nhất có thể đã xảy ra bởi vì có nhiều host quét máy trong lần thứ hai hoặc vì số lượng các gói dữ liệu gửi bởi hốt tăng lên. Hơn nữa xem xét dữ liệu cho thấy các đỉnh cao và thấp nhất tương quan với số máy quét được tăng lên.
Tốc độ đỉnh cao là 21 giây đã được quan sát thấy một lần nữa trong lần quét thứ ba, ngày 01 tháng 11 đã thực sự là một bí ẩn. Tuy nhiên, nó đã được quan sát thấy rằng các máy quét gửi retries của các kết nối với SYN ban đầu không nhận được phản hồi.
Đây là cách xử lý TCP điển hình, và nhiều chồng giao thức TCP/IP sẽ thử 3 retry sau SYN ban đầu, với một cahs thức chờ đợi 3 giây trước khi thử lại lần đầu tiên, gấp đôi thời gian chờ đợi đến 6 giây để thử lại lần thứ hai và gấp đôi thời gian chờ đợi một lần nữa 12 giây cho lần thứ ba và kết thúc. Do đó, thời gian tổng hợp mà giữa SYN ban đầu và retry cuối cùng là 21 giây. Và như vậy, khi SYN ban đầu thử được vẽ theo thời gian như trong hình 11.2, đỉnh cao nhất 21 giây biến mất.
Figure 11.2. June 29, 2001 initial SYN attempts.
Điều này chỉ giải thích một phần đỉnh cực đại 21-second. Nếu điểm cao nhất này là hoàn toàn đúng cho các retry duy nhất của cùng một host, tương tự như hoạt động cao nhất nên được quan sát tại 3 và 9 giây là tốt. Hình 11.3 cho thấy hai kiểu riêng của kết nối thử vào thời gian ngày 29 tháng 6-đường lên xuống cho thấy nỗ lực SYN ban đầu và dường dashed cho thấy những retry của SYN ban đầu. Điều này giai thích đầy đử hơn về điểm cực đại 21-second.
Figure 11.3. June 29, 2001 initial SYNs and retries.
Hoạt động cao điểm xảy ra lúc 12:16:52. Theo dự kiến, điều này tương ứng với retry thứ 3 của việc dồn các kết nối SYN được gửi lúc 12:16:31. Hơn nữa, nó tương ứng với các retry lần thứ hai của hàng tấn tập SYN khác được gửi 9 giây trước khi hoạt động cao điểm lúc 12:16:42. Nhiều hơn như vậy, trong cả hai lần quét, nó xuất hiện ít nhất là lúc đầu tiên, rằng các làn sóng kết nối SYN đầu tiên đến trong khoảng 12 second. Sự chồng chéo của retry từ mô hình này đặc biệt là lý do tại sao thời gian hoạt động cao điểm 21-second được xác nhận.
The 21-Second Mystery
Một trong những tiết lộ thú vị nhất của việc kiểm tra giao thông SubSeven này là thời gian 21 giây trước khi hoạt động cao điểm trong hai lần quét ban đầu, và sau lần ba đã được quan sát thấy. Nó đã rõ ràng rằng có một số ý nghĩa và giải thích gắn liền với điều này, điều này không thể là một sự trùng hợp chỉ vì nó đã xảy ra ba lần.
Tôi có một thói quen khó chịu: Khi tôi đi lộp cộp và thất vọng bởi sự bất lực của tôi để tìm ra một cái gì đó, tôi bắt đầu quấy rầy đồng nghiệp. Hầu hết những người có học sa thải tôi với một số lý do chính đáng như, "Có bánh rán miễn phí tại căng tin Nhìn bạn sau đó.." Nhưng, tôi bị dồn vào chân tường bởi đồng nghiệp–bạn thân đi xe đạp lâu năm Vern, và hỏi anh ta bí ẩn này để suy
ngẫm. Trong vòng vài giây và vẫn còn một cơ hội tốt để có được những quán bánh rán, ông nói, "Ồ, đó là điều dễ dàng, đó là thời gian backoff được phối hợp cho các retry”. Điều này làm cho chúng ta cái nhìn sâu sắc suy nghĩ lại cách tiếp cận của chúng tôi, và chúng tôi cuối cùng đã chia nhỏ giao thông riêng cho các SYN ban đầu và các retry, cho phép chúng ta khám phá ra rằng tốc độ cao điểm 21-giây là một chồng chéo của cac retry từ các lớp sóng ban đầu khác nhau của hoạt