Không nghi ngờ gì bạn đã có đủ những hiểu biết về lý thuyết phân tích kĩ gói tin và các trường header. Làm thế nào về việc đưa vào một số chi tiết thú vị, hấp dẫn,giao thông mạng trong thế giới thực? Đó là những gì chúng ta có để tham gia tìm hiểu trong chương này. Đối với bạn để hiểu được phân tích mà sẽ được chỉ ra ở đây, nó là cần thiết để đưa ra cơ sở trong chương đầu tiên.
Để làm mới lại bộ nhớ của bạn về mục đích của phần này, chúng ta muốn phân tích lưu lượng truy cập từ nhiều quan điểm khác nhau. Chúng ta đã phát triển từ các bit và các trường trong chương trước để kiểm tra một hay nhiều gói tin cho mục đích của chúng và giải thích một số sự kiện thực tế của lợi ích mà bị giữ lại bởi Shadow từ các trang web.
Việc chuyển đổi từ sự hiểu biết lý thuyết để giải thích thực tế một số lưu lượng truy cập mà bạn thấy là không phải là dễ dàng. Phải mất thời gian và tiếp xúc với một số lưu lượng đáng quan tâm trước khi bạn đạt được sự tự tin và kinh nghiệm để thực hiện chuyển đổi này. Các ví dụ được đưa ra trong chương này sẽ giúp bạn sự bắt đầu.
You've Been Hacked!
Sự đơn giản của sự kiện này lần đầu tiên trong thế giới thực gây một ấn tượng sai lầm về tính sâu sắc của nó. Trong khoảng thời gian trước, tôi đã làm việc cho quân đội địa phương Computer Emergency Response Team (CERT). Tôi đã bắt đầu làm việc sớm lúc 05:30 để tránh áp lực của giờ cao điểm từ các vùng ngoại ô của một trong những quốc gia khủng khiếp nhất về sự đi lại trong các thành phố là Washington, DC. Một buổi sáng tôi bước vào trong văn phòng, và điện thoại đã đổ chuông rồi- một dấu hiệu không tốt, trừ khi nó là Ed McMahon gọi để nói với tôi rằng Tôi thắng
trong rút thăm trúng thưởng Clearinghouse của Nhà xuất bản. Thay vào đó, các cuộc gọi được từ một trong những bộ đội cấp trên Certs của chúng tôi thông báo cho chúng tôi rằng chúng tôi đã có một cuộc tấn công vào ngân hàng trong đêm
CERT cấp trên được sử dụng một bộ công cụ khác nhau để giám sát trang web nhiều hơn là chúng tôi đã làm và đôi khi có cuộc gọi khi nó đã có một cuộc điều tra về giao thông hoặc báo cáo một cái gì đó đáng chú ý, như trong trường hợp này. Các CERT cung cấp ngày, khoảng thời gian, và các IP nguồn và đích liên quan đến cuộc tấn công nhưng có thể cung cấp không nhiều thông tin hơn khi được hỏi.
IP đích của host nạn nhân bị cáo buộc là một máy chủ DNS tại trang web. Đây có lẽ là một trong những host được duy trì tốt nhất trên trang web, nó đã có những bản vá mới nhất của BIND, nó có tất cả các cổng được đóng ngoại trừ vỏ an toàn (SSH) từ địa chỉ nguồn cụ thể và truy vấn DNS, và nó đã bị tước bỏ tất cả tài khoản người dùng không cần thiết. Nó không phải là nếu điều này đã được một số hệ thống cũ sang ngồi công khai trên một DMZ không có sự chú ý gần đây, các cổng mở không cần thiết, và không bị giới hạn truy cập. Tuy nhiên, mặc dù phản ứng đầu tiên của tôi được hoài nghi, tôi đã không suy nghĩ ngây thơ rằng bất kỳ máy chủ kết nối vào Internet không thể bị tấn công. Sau tất cả, đây là một máy chủ DNS, và các phần mềm BIND đáng kính đã bị cản với một lịch sử của các vấn đề, bao gồm các cuộc tấn công tràn bộ nhớ đệm cho phép truy cập root từ xa.
Một cách hợp lý để tiếp cận bài báo vào sáng sớm này đã được sử dụng các bản ghi TCPdump từ Shadow để kiểm tra tất cả lưu lượng đến và đi từ máy chủ DNS của chúng tôi từ địa chỉ IP của kẻ tấn công bị cáo buộc. Trước khi hiển thị cho bạn một đoạn trích của các kết quả đó, chúng ta hãy chỉ cần tái kiểm tra những gì một phiên TCP được thành lập trông giống như trong điều kiện của tcpdump. Three-Way Handshake: boulder.myplace.com.38060 > aspen.myplace.com.telnet: S 3774957990: 3774957990(0) win 8760 <mss 1460> (DF) aspen.myplace.com.telnet > boulder.myplace.com.38060: S 2009600000: 2009600000(0) ack 3774957991 win 1024 <mss 1460>
boulder.myplace.com.38060 > aspen.myplace.com.telnet:. ack 1 win 8760 (DF)
Data Exchange:
boulder.myplace.com.38060 > aspen.myplace.com.telnet: P 1:28(27) ack 1 win 8760 (DF)
aspen.myplace.com.telnet > boulder.myplace.com.38060: P 1:14(13) ack 1 win 1024
aspen.myplace.com.telnet > boulder.myplace.com.38060: P 14:23(9) ack 28 win 1024
Session Termination:
aspen.myplace.com.telnet > boulder.myplace.com.38060: F 4289:4289(0) ack 92 win 1024
boulder.myplace.com.38060 > aspen.myplace.com.telnet: F 92:92(0) ack 4290 win 8760(DF)
aspen.myplace.com.telnet > boulder.myplace.com.38060: .ack 93 win 102
Trước tiên, cho hai host trao đổi một số kiểu dữ liệu, chúng phải hoàn thành bắt tay ba bước. Trong trường hợp này, chúng tôi có host boulder.myplace.com đang yêu cầu kết nối đến máy aspen.myplace.com trên cổng telnet. Host aspen.myplace.com cung cấp dịch vụ telnet và hai máy đồng bộ hóa các số sequence và kết nối được thành lập.
Tiếp theo, thường là một máy client kết nối tới một host với mục đích trao đổi một số dữ liệu. Và trong trường hợp này, chúng tôi chứng kiến sự trao đổi giữa hai máy như chúng ta thấy byte dữ liệu 27, 13, và 9 được gửi tương ứng trong ba gói PUSH được hiển thị. Nhiều dữ liệu đã được trao đổi trước phiên kết thúc, nhưng điều đó không được chỉ ra bởi vì nó thực sự không có thêm hiểu biết mới về cuộc thảo luận này.
Cuối cùng, hai host cắt đứt kết nối bằng cách trao đổi và ghi nhận các gói tin FIN. Đó là điều bình thường giống như các phiên TCP.
Bây giờ, kiểm tra một số giao thông từ cuộc tấn công bị cáo buộc:
whatsup.net.24997 > dns.myplace.com.sunrpc: S 2368718861:2368718861(0) win 512 <mss 1460>
whatsup.net.25002 > dns.myplace.com.139: S 4067302570:4067302570(0) win 512 <mss 1460>
whatsup.net.25075 > dns.myplace.com.ftp: S 1368714289:1368714289(0) win 512 <mss 1460>
dns.myplace.com.ftp > whatsup.net.25075: R 0:0(0) ack 1368714290 win 0 (DF) whatsup.net.25177 > dns.myplace.com.1114: S 3231175487:3231175487(0) win 512 <mss 1460>
whatsup.net.25189 > dns.myplace.com.tcpmux: S 368146356:368146356(0) win 512 <mss 1460>
whatsup.net.25118 > dns.myplace.com.22: S 2035824356:2035824356(0)win 512 <mss 1460>
Các host có hại là whatsup.net và DNS server của chúng tôi là dns.myplace.com. Chúng tôi thấy một bó SYN cố gắng kết nối đến các cổng khác nhau bắt đầu với cổng 111, còn được gọi là sunrpc hoặc portmapper, cổng 139, quản lý phiên NetBIOS, FTP, vv. Chúng tôi thấy không có phản hồi từ DNS server ngoại trừ một RESET trên truy vấn ftp phản hồi lại. Chúng tôi có thể phỏng đoán rằng thiết bị lọc gói tin chặn các cổng khác chúng ta thấy, nhưng không phải ftp. Khi máy chủ DNS nhận được ftp SYN attempt, nó trả lời với một RESET bởi vì nó không nghe ở cổng đó.
Đây chỉ là một đoạn trích của lưu lượng được thấy, nhưng nó cũng tương tự như tất cả ngoại trừ các cổng đích khác. Có điều là bắt tay ba bước không thành công, trao đổi dữ liệu, hoặc các phiên kết thúc được xác nhận. Trừ khi có một số kiểu backdoor không biết vào mạng của chúng tôi mà không được giám sát, nó xuất hiện mà đây là một cách quét đơn giản của DNS server và không phải là một cuộc tấn công.
Sau khi phân tích lưu lượng này, tôi là người đã có báo cáo về break-in. Tôi chia sẻ kết quả của tôi và yêu cầu kiểu bằng chứng gì mà họ đã có về break-in. Người trả lời rằng một trong những cấp trên của tổ chức CERT đã có báo cáo này và đã được chỉ qua các thông tin trên trang web của chúng tôi. Tôi đã nhận các thông tin liên lạc cho những người gốc đã báo cáo vụ việc và được gọi để tìm hiểu lý do tại sao ông tin rằng chúng tôi đã phải chịu một sự xâm nhập. Các phản hồi mà ông đã báo cáo nó như là một máy quét, và nó đã bị truyền đạt nhầm lẫn đến tôi như một break-in.
Nhiệm vụ của tôi đã không bị xác nhận là có tội, nó đã được xác định rõ kiểu bằng chứng vững chắc của bất cứ ai có để bác bỏ niềm tin của tôi rằng chúng ta chỉ có một máy quét. Tuy nhiên, vì nó bật ra, có thực là không có break-in sau tất cả. Sự cố này mang về nhà sự cần thiết để có một dấu vết của hoạt động theo dõi bên trong và ngoài mạng. Chúng tôi không có các tcpdump record của máy quét, chúng tôi đã không có bằng chứng để bác bỏ các yêu cầu bồi thường xâm nhập. Chúng tôi sẽ phải tin tưởng người gọi và tin rằng chúng tôi đã có một sự xâm nhập mà NIDS không có phát hiện.
Chúng tôi có thể đăng nhập vào máy chủ DNS. Tuy vậy, sẽ không có bất kì dấu vết nào, nếu chúng ta may mắn. Hiện sẽ không có thay đổi trong bất kỳ bản ghi Tripwire mà duy trì kiểm tra tính toàn vẹn của các tập tin quan trọng, sẽ có không rootkit, và có thể sẽ không có thay đổi mật khẩu của các tập tin hoặc khởi động tập tin. Nó sẽ không thể biết chắc chắn rằng có hay không có sự xâm nhập, sẽ có sự kéo dài nghi ngờ rằng chúng tôi không thấy các biểu hiện của break-in, có lẽ vì rootkit được cài đặt và phần mềm Trojaned. Trong trường hợp như vậy mà bạn vẫn không chắc chắn về hoạt động tốt của các host, không có nhiều lựa chọn. Bạn cần phải xây dựng lại hệ thống từ mặt đất lên-đó không phải là một công việc mong muốn.
Trước sự kiện này, tôi đã có được một đề xuất của Shadow và đã thu thập các hoạt động tcpdump tại các trang web được theo dõi. Điều này được tôi chuyển đổi một Shadow die-hard, và tôi bây giờ sử dụng Shadow cho tất cả các trang web mà tôi theo dõi. Trung thực, không quan trọng nếu bạn sử dụng tcpdump hoặc bất kỳ cơ chế tập hợp khác. Điều quan trọng là bạn có nắm bắt lịch sử của lưu lượng truy cập vào và ra khỏi mạng của bạn. Và, bạn không cần phải nắm bắt trọng tải, chỉ cần các phần header của các record, để hiểu bản chất của hoạt động này như đã được chứng minh trong vụ việc này. Thật vậy, nó cũng có thể hữu ích để nắm bắt tải trọng nếu bạn có đủ không gian, ngay cả khi chỉ để giữ cho nó một vài ngày trước khi lưu trữ nó.
NetBus Scan
Trong vụ việc tiếp theo, chúng ta xem xét một máy quét đến cổng đích 12345, mà là thường gắn liền với NetBus Trojan có ảnh hưởng đến máy chủ Windows. Máy quét đặc biệt này đã được đưa ra đối với một mạng con lớp B bởi nó tập hợp tất cả các loại báo động. Các mạng đã được quét có một số cổng truy cập mở thông qua các thiết bị lọc gói.
Các bản ghi sau đây cung cấp rất ngắn gọn một trích đoạn rất ngắn gọn về giao thông được phát hiện. Máy quét này đã thử kết nối tới hơn 65.000 địa chỉ IP trong mạng mục tiêu. Điều quan trọng cần lưu ý rằng lưu lượng truy cập này đã được thu thập trên một bộ cảm biến đặt phía sau (bên trong) thiết bị lọc gói. Đây là giao thông mà thực sự đã nhận bên trong mạng. Quét xảy ra! Trong thực tế, chúng xảy ra tất cả các thời gian trên mạng này. Nó không phải là mạng nàynhiều mạng khác, nó chỉ là một thực tế của cuộc sống mà quét là chắc chắn xảy ra và thường xuyên. Biết được
điều này, bạn không thể làm việc được nhiều khi bạn thấy quét. Tuy nhiên, đây là bên trong các thiết bị lọc gói tạo ra sự hiếu kì hơn, như chúng tôi sau này sẽ thấy. Sau đây là các bản ghi:
bigscan.net.1737 > 192.168.7.0.12345: S 2299794832:2299794832(0) win 32120 <mss 1380,sackOK,timestamp 120377100[|tcp]> (DF) bigscan.net.1739 > 192.168.7.2.12345: S 2299202490:2299202490(0) win 32120 <mss 1380,sackOK,timestamp 120377100[|tcp]> (DF) bigscan.net.1741 > 192.168.7.4.12345: S 2293163750:2293163750(0) win 32120 <mss 1380,sackOK,timestamp 120377100[|tcp]> (DF) bigscan.net.1743 > 192.168.7.6.12345: S 2298524651:2298524651(0) win 32120 <mss 1380,sackOK,timestamp 120377100[|tcp]> (DF) bigscan.net.1745 > 192.168.7.8.12345: S 2297131917:2297131917(0) win 32120 <mss 1380,sackOK,timestamp 120377100[|tcp]> (DF) bigscan.net.1747 > 192.168.7.10.12345: S 2291750743:2291750743(0) win 32120 <mss 1380,sackOK,timestamp 120377100[|tcp]> (DF) bigscan.net.1749 > 192.168.7.12.12345: S 2287868521:2287868521(0) win 32120 <mss 1380,sackOK,timestamp 120377100[|tcp]> (DF
Chúng tôi thấy có phương pháp bigscan.net máy quét di chuyển thông qua các subnet 192.168.7 với một máy quét duy nhất tìm kiếm mô hình của tìm kiếm tại địa chỉ .0 và thậm chí octet cuối cùng sau đó.
NetBus Hijinks
NetBus là một công cụ cho phép truy cập từ xa và kiểm soát của một máy chủ Windows. Sau khi một máy chủ được thỏa hiệp, kẻ tấn công có một phương tiện truy cập tới host trong tương lai. NetBus là một trong nhiều backdoor trojan có thể được chạy để cung cấp truy cập tàng hình. Nó xảy ra khác trước, quen thuộc hơn backdoor Trojan, Back Orifice. Cả hai NetBus và Back Orifice có giao diện người dùng thân thiện dễ dàng điều khiển các host đã thỏa hiệp từ xa.
Not All That Runs on Port 12345 Is Malicious
Các virus OfficeScan xoá gói cho các công ty kinh doanh lắng nghe trên cổng TCP 12345 trên host desktop. Các phần mềm doanh nghiệp cung cấp chủ yếu bản ghi virus, cập nhật tự động (rõ ràng thông qua cổng 12345 trên host cập nhật), và quản lý từ xa dễ sử dụng để hỗ trợ giám sát và cấu hình.
Nếu bạn đã bao giờ nhìn thấy một máy chủ mà lắng nghe trên cổng TCP 12345, có thể rằng nó có thể là một quá trình xử lý hữu ích hơn là có hại. Với một loạt các cổng nghe có thể có từ 1 đến 65535, tôi rất thích xem những chiếc mũ trắng chọn cổng lắng nghe mà không chia sẻ các cổng hacker thường sử dụng.
Hãy tấn công vào nhược điểm của đối thủ và xem nếu có bất cứ cần phải tiếp tục kiểm tra máy scan này. Chúng tôi muốn kiểm tra các máy trong mạng nội bộ và xem nếu chúng phản hồi đến máy quét. Bộ lọc tcpdump để kiểm tra tìm kiếm lưu lượng truy cập từ mạng nội bộ 192.168 với một nguồn cổng 12345 và một cặp cờ TCP: SYN và ACK. Điều này có nghĩa rằng chúng tôi có một máy nghe, mà có thể có khả năng rất nguy hiểm. Bộ lọc của chúng tôi có thể đã sử dụng các số IP của máy quét để thay thế hoặc cùng chung với các địa chỉ subnet nội bộ.
Các lệnh tcpdump sử dụng để tách các bản ghi trả lời liên quan đến việc máy quét đọc tập tin nhị phân của các record thu thập cho trang web, và xác định máy quét này là một trong cái mà liên quan đến subnet 192.168 nội bộ và công 12345. Các lệnh tcpdump là tiếp tục tinh chế bằng cách sử dụng một bộ lọc nhìn vào các byte 13 offset của TCP header, tại vị trí byte TCP flag, và chờ cờ ACK và cờ SYN thiết lập cùng một lúc. Đây là lệnh tcpdump và đầu ra được tạo ra từ nó:
tcpdump -r tcpdumpfile 'net 192.168 and port 12345 and tcp[13] = 0x12'
mynet.edu.12345 > bigscan.net.3698: S 2633608519:2633608519(0) ack 2346088305 win 49152 <mss 1380,nop,nop,timestamp 2662730[|tcp]> (DF)
Các tin tốt là chỉ có một host trả lời. Tin xấu là một host được trả lời! Khi nó đã được phát hiện ra rằng có một host phản hồi, sự kiện này đã leo thang lên độ ưu tiên cao nhất bởi vì chúng tôi tin rằng chúng tôi đã có một máy chủ cung cấp các NetBus Trojan, một kết luận tự nhiên. Việc quét và phát hiện ra tiếp theo đó đã có một host phản hồi xảy ra tại 7 giờ sáng, có nghĩa là hầu hết các nhân viên chưa đến làm việc. Trong tạm thời, các nhóm mạng đã được liên lạc và nói không cho phép bất kỳ lưu lượng truy cập bên trong hoặc bên ngoài đến hoặc từ các host phản hồi bằng cách ngăn chặn nó ở thiết bị lọc gói. Ngoài ra, nhóm máy tính nội bộ phản ứng sự cố đã được huy động để quét các máy chủ cho các lỗ hổng và theo dõi chủ sở hữu.
Sau khi một số thăm dò bên ngoài, các đội trả lời sự cố phát hiện ra rằng các máy chủ là một Silicon Graphics. Inc (SGI) đang chạy một phiên bản cũ của Irix (SGI's version of UNIX). Như một đọi phản hồi sự cố kỳ cựu, tôi nhớ rằng phiên bản cũ của Irix sử dụng để cấu hình với một tài khoản