Chúng tôi sẽ không giúp bạn xâm nhập vào một hệ thống nào đó. Nếu như bạn thực sự muốn xâm nhập một hệ thống bảo mật nào đó thì bạn phải bắt đầu từ những điểm xuất phát đầu tiên và học hỏi càng nhiều càng tốt về hệ thống đó từ trong ra ngoài. Cũng nên nhớ rằng không có một sách vở nào dạy bạn làm thê nào xâm nhập 1 hệ thống cả và có lẽ là sẽ không bao giờ có.
Nếu như bạn muốn tìm hiểu thì hãy đến www.linuxsavvy.com/staff/jgotts/underground/hack-faq.html
Trước tiên bạn nên nhớ rằng, xâm nhập vào yahoo mail hay hotmail là một việc làm rất là tồi bại. Và bạn đừng có bao giờ làm chuyện này. Nhưng nếu bạn tò mò muốn biết nó như thế nào thì thật ra nó cũng có một vài cách cho bạn đấy. Cách ngu xuẩn nhất là dung một danh sách chứa các từ kèm với một chương trình (wwwhack chẳng hạn), chạy chương trình này, tắt điện đi ngủ hay đóng cửa nhà đi chơi với người yêu, nếu bạn may mắn bạn sẽ tìm được mật mã của account bạn muốn.
Cách thứ hai là gởi cho nạn nhân một trojan hay một keylog. Tuy nhiên hầu hết các chương trình quét virus hiện nay đều phát hiện ra những loại này. Nếu có thể, bạn tự học 1 loại ngôn ngữ lập trình nào đó rồi tự viết cho mình 1 trojan hay 1 keylog, đó là cách tốt nhất.
Câu trả lời là không và sẽ không bao giờ.
Tìm ở trong đây www.insecure.org/tools.html
Thật ra không có cách dễ dàng nào có thể đánh tráo IP cả. Và cũng không có một công cụ nào giúp bạn làm điều này cả. Để làm được điều đó bạn phải nghiên cứu cách làm việc bên trong của TCP/IP. Chúng tôi sẽ tóm tắt nó ở đây. Nhưng nếu bạn không thể hiểu chúng tôi đang nói cái gì thì các bạn có thể tìm hiểu thêm tại
http://phrack.infonexus.com/search.phtml?v...&article=p48-14
OK, chúng ta bắt đầu:
Trong một quá trình làm việc của TCP/IP (TCP/IP-connect), việc đầu tiên xãy ra là "làm quen TCP". Đây là khúc dạo đầu gồm có 3 bước trước khi gởi dữ liệu đi:
Bây giờ nếu như bạn muốn đánh tráo một IP nào đó, bạn có thể cho rằng bạn đang gởi một gói về IP này. Điều này hoàn toàn sai, bởi vì hệ thống internet được thiết kế theo cách sao cho các gói từ B luôn luôn đi thẳng đến A, và A có thể sẽ điều chỉnh lại sự liên lạc này, không hiểu biết tại sao B lại gởi cái SYN/ACK-gói của B đến A.
Như vậy, tất cả những gì bạn phải làm đó là bạn phải chắc chắn rằng A không thể trả lời các gói được gởi từ B. Điều này có thể được thực hiện thông qua một cuộc tấn công theo kiểu "từ chối dịch vụ".
Bây giờ để đóng vai trò của A một cách thực sự, bạn phải tưởng tuợng rằng B vẫn sẽ gởi các gói của mình đến A thực sự, vậy bạn sẽ không thấy chúng. Đây là một khó khăn vì bạn không nhận được SYN/Ack-gói từ B và như vậy bạn không thể đồng bộ hoá chuỗi số của các gói này. Điều đó có nghĩa là bạn phải đoán chuỗi số này của mỗi một gói phản hồi lại các gói của bạn. Làm việc này chống lại những máy tính có các IP-stack tồi (giống như Windows) thì có thể được nhưng đối với các hệ thống khác (chẳng hạn như Linux…) thì khó có thể mà nói trước được.
Đó là tất cả những gì bạn có thể làm được nhưng rất tiếc đó chỉ là lý thuyết. Nếu như bạn muốn biến nó thành hiện thực thì bạn nên tìm hiểu rất nhiều về TCP/IP. Biết đâu nó có thể giúp đỡ bạn, ví dụ, ứng dụng khéo léo với tuyến này sao cho các gói thực sự đi từ B đến A có thể đi xuyên qua một mạng mà nơi đó bạn có thể đoạt được chúng. Và trong trường hợp này bạn sẽ phải gởi các gói của bạn đủ nhanh đến B sao cho khỏi bị lỗi “timing out”
OK, nếu như bạn không có khả năng đánh tráo địa chỉ IP (xem câu hỏi 2.1), tôi nghĩ rằng bạn sẽ nảy ra ý nghĩ là tại sao mình không dấu nó đi. Chuyện này có thể làm được nếu chúng ta sử dụng một proxy. Một proxy là là một cái máy làm nhiệm vị chuyển giao các yêu cầu của bạn. Nếu như có thể tìm một proxy để chuyển giao một yêu cầu bât hợp pháp tới nạn nhân, thì những yêu cầu này chính là của proxy chứ không phải là của bạn. Địa chỉ IP được thâu nhận lại trong các filelogs cũng chính là các IP của proxy.
Ví dụ: Nếu bạn đã cài đặt các trình duyệt (IE hoặc Netscapê) để sự dụng một webproxy và bạn gõ vào một URL. Khi đó trước tiên webproxy sẽ chuyển giao một copy của URL (cache) này tới bạn (nếu nó có). Nếu nó không có một copy của URL này, lúc đó nó sẽ chuyển giao yêu cầu của bạn đến server của URL, và proxy cũng sẽ chuyển giao sự trả lời của server đến bạn, lưu giữ một copy của URL tại server.
Một ví dụ khác, nếu như bạn cố gắng quét các cổng của một server thông qua một proxy. Chuyện này có thể sẽ không được thực hiện với các chương trình quét cổng thông thường, tại vì những gì được chuyển giao không phải là các IP-gói (IP.pack), nhưng mà là các query. Và như vậy những đầu óc tưởng tượng làm, đó là bạn nối đến server:port xuyên qua cái webclient này, và lúc đó bạn đợi một chút, trước khi đụng vào nút “stop”. Trên màn hình bạn sẽ thấy các dòng hiện lên các chức năng phục vụ của các cổng này.
Bạn không thể nào quét được các cổng thấp (<1023) theo cách này, còn đối với các cổng cao hơn thì OK, không có chuyện gì.
Bây giờ bạn cũng có thể thử một dây chuyền các webproxxy như sau: Proxy1:Pport:proxy2:Pport:proxy3:Pport:victim:Sport, ở đây
Pport là cổng của các proxyserver (thông thường là 8080, 80 hay xẫp xĩ)
và Sport là cổng mà bạn muốn quét trên máy của nạn nhân.
Bạn không thể tìm được gì nhiều hơn ngoài cái IP của người đó. Điều này có nghĩa là bạn không thể có được các thông tin cá nhân về con người đó, ví dụ như: số điện thoại, địa chỉ, họ tên… nhưng nhà cung cấp dịch vụ (ISP) có các thông tin này.
Nếu như bạn không ở trên cùng một mạng với server thì bó giò. Thậm chí bạn ở cùng một mạng với server nhưng mà gặp một mạng chuyển đổi (switsched network) thì cũng bó giò luôn (mạng chuyển đổi đang rất thịnh hành hiện nay).
Nếu bạn bắt đầu việc dò dẫm trên một mạng khác, bạn có thể chỉ có khả năng coi được các thông tin đi từ một đoạn mạng đó đến server này, khả năng là chỉ dò được các thông tin về chính các gói của bạn gởi đi, bởi vì cái mạng mà bạn đang nối cũng được thay đổi luôn.