Muốn biết thì nên sưu tầm vài cái 'shell', chúng có đầy trên web đó. Tải về và xem chúng được viết thế nào. Nếu muốn biết chúng làm việc thế nào thì cài lên cái Linux server mà vọc.Nhưng không nên sa đà vào những trò vớ vẩn bởi vì upload một cái shell lên server của người khác rồi delete files, rồi thay thế index.html có nội dụng 'hacked by cuti' thì chẳng có gì vui và sáng tạo cả. Mấy cái trò này dành cho những đừa 'teen' dư thời gian và thiếu định hướng mà thôi.

[..] Theo kinh nghiệm, những điểm nhận INPUT và kiểm soát, xác thực, giới hạn giá trị INPUT của một software là điểm đầu tiên nên được xét bởi vì ở những điểm này, dữ liệu có tính chất và kích thước nằm ngoài giới hạn dự tưởng nhất định sẽ tạo 'thái độ' bất bình thường cho software đó. Đối với một ứng dụng cung cấp dịch vụ web như Apache, điểm nhận INPUT quan trọng là mớ HTTP header. RFC cho giao thức HTTP có những quy định tổng quát nhưng bỏ ngỏ nhiều điểm tùy vào người ứng dụng. Bởi thế, điển hình là Apache quyết định giới hạn tối đa của header field có kích thước là 8190 bytes mặc dù RFC tiêu chuẩn không ép buộc giới hạn này.

Xin xem phần mục lục của series này ở bài giới thiệu.

Tổng quát mà nói thì options -O của nmap chỉ là 1 cái flag trên dòng lệnh để ra lệnh nmap thực thi công tác xác định footprint. Để biết cơ chế làm việc đằng sau đó thế nào thì cũng không phức lắm. Đại khái nmap có hồ sơ kèm theo chương trình gọi là "nmap-os-fingerprints"; nó chứa trọn bộ các bản mẫu 'dấu ấn' cho từng footprint có thể xác định được. Khi được ra lệnh xác định footprint, nmap sẽ thực thi một loạt thử nghiệm bằng cách 'phun' ra những request packets có tính chất khác nhau. Tuỳ theo kết quả thâu được và dựa trên bản mẫu này, nmap sẽ tường trình footprint đáng tin cậy nhất."

Xin xem phần mục lục của series này ở bài giới thiệu.

Mỗi khi gói tin đi qua một router, TTL nguyên thủy (lúc gói tin tạo ra) sẽ bị trừ đi 1. Chi tiết thế nào có trong cuốn TCP/IP illustrated của Richard Stevens, quyển này dành riêng mấy trang nói rất kỹ về TTL. Khi mình đã nắm được nguyên tắc: qua 1 router, TTL trừ 1 thì có thể suy luận và hình dung ra được ngay gói tin 'cuti' sniff được ở trên có TTL với giá trị đã được trừ 1 nhiều lần bởi vì nó phải đi qua nhiều router trước khi về đến máy mình'. 

Xin xem phần mục lục của series này ở bài giới thiệu.

Solaris, sản phẩm chủ đạo của công ty Sun Microsystems, là 1 trong những hệ điều hành Unix nổi tiếng nhất trong dòng OS phục vụ enterprise solutions (như BSD/OS của BSDi, HP-UX của HP, AIX của IBM, IRIX của SGI, UnixWare của SCO,...). Solaris vốn là sản phẩm mã nguồn đóng, được Sun bán với giá nhiều nghìn đô la, trái ngược hẳn với GNU Linux – hệ điều hành mã nguồn mở, miễn phí. Gần đây, như nhận ra xu hướng tất yếu của mã nguồn mở, Sun thay đổi chiến lược kinh doanh bằng việc cho phép người dùng sử dụng Solaris miễn phí – một điều tưởng như không thể xảy ra.

Dùng phương pháp thay đổi banner chỉ có thể đánh lừa những người chưa đủ kinh nghiệm và một số tools tự động hoá chưa đủ tinh vi. Tuy vậy, đánh lừa được nhóm 'thăm dò' ở dạng hoàn toàn phó mặc vào công cụ cũng đã là đáng kể vì nhóm này chiếm đa số. Vậy, trên phương diện phòng thủ, liệu có nên ứng dụng phương cách 'giả' banner không?"

[..] Nếu có thể 'giả' để giảm thiểu những màn thăm dò chung chung thì tại sao không làm? Em nên biết, chỉ có chừng dưới 10% các cú rà tự động được tiếp tục bằng quá trình 'rà' bằng tay để xác định thêm thông tin mục tiêu. Thông thường, quá trình rà tự động chỉ để thu thập một số mục tiêu có thông tin cụ thể mà kẻ thâm nhập muốn tìm. Tuy nhiên, đối với kẻ có quyết tâm thăm dò một mục tiêu cụ thể nào đó thì chuyện 'giả' có lẽ không tác dụng gì mấy.  

[..] Security through obscurity dịch nôm na ra tiếng Việt là bảo mật bằng tính bất khả định. Hay nói một cách khác, vì mục tiêu không được rõ ràng nên nó có vẻ bảo mật hơn. Có hẳn một trường phái rất chuộng security through obscurity nhưng nó chỉ thuộc về cái vỏ bên ngoài mà thôi. Đối với những ai thật sự muốn thâm nhập thì cái 'vỏ' này mỏng manh lắm. Nếu có thời gian và điều kiện thì thêm cái vỏ này cũng tốt nhưng nếu chỉ phó mặc vào nó để 'bảo mật' thì rất phiến diện." 

[..] Cần phải thu thập hết các bản mẫu 'xịn' :). Cái này còn gọi là 'footprint database'. Tùy mỗi người có cách lưu trữ và so sánh nhưng điểm cốt lõi là: dù có 'rà' bằng tay hay 'rà' tự động, cần phải có một số thông tin mẫu nào đó để làm chuẩn. Nếu không thì không thể so sánh cái mình thấy (từ việc thăm dò) với một cái gì khác cả." 

[..] Logic tối cần thiết nhưng tính tập trung và sự tinh tế không thể thiếu được. Sau này, khi em đi đến chỗ viết shellcode, dò stack mà lại thiếu sự tinh tế thì sẽ không thể đạt kết quả được. Đối với 'hacker', mỗi chi tiết bé nhỏ đều có thể mang một giá trị lớn lao. Chúng có thể làm em mất ăn, mất ngủ, mất thời gian để rồi, đến lúc nào đó em sẽ vò đầu và tự rủa mình vì đã 'sót' chúng trong khi phân tích. Thật ra, logic + tập trung + tinh tế là ba đức tính cần thiết không riêng gì trong bảo mật mà nó cần thiết trong các ngành khoa học." 

Xin xem phần mục lục của series này ở bài giới thiệu.

Tùy theo mục tiêu là một host, một network hay cả một organisation, profiling sẽ cần nhiều hay ít thông tin. Nguyên tắc căn bản áp dụng cho các mục tiêu đều như nhau.

1. Thứ nhất: cần biết mục tiêu đang ở đâu, đang thuộc network nào.
2. Thứ hai: cần biết từ nơi em đang thực hiện thăm dò đến mục tiêu cần thăm dò sẽ đi qua những chặng network nào.
3. Thứ ba: cần biết mục tiêu có những dịch vụ nào.
4. Thứ tư: cần biết mục tiêu được bảo vệ như thế nào.

Xin xem phần mục lục của series này ở bài giới thiệu.

Không có một luật nào bắt buộc phải thao tác đúng từng bước để phục vụ mục đích thăm dò cả. Tùy mục tiêu và tùy khả năng phòng bị và thắt chặt của mục tiêu mà khai triển kế hoạch thăm dò cho thích hợp. Có thể tóm gọn chúng lại thành ba phần chính:

• Tìm dấu ấn (footprinting) --> xác định mục tiêu tổng quát
• Rà quét (scanning) --> xác định các dịch vụ tổng quát
• Lấy số liệu cụ thể (enumerating) --> thu thập thông tin cụ thể.

[..] Một server chạy Linux bị dùng 'ping of death' để tấn công. Điều buồn cười là dạng 'ping of death' này dành cho Windows phiên bản cũ, bị lỗi ở phần giới hạn packet size của ICMP làm treo máy khi bị tấn công. Không hiểu sao nhóm này cứ hè nhau mà tấn công Linux server của anh bằng một thứ công cụ dành để tấn công Windows. Hơn nữa, Linux server này hoàn toàn cản mọi inbound ICMP và UDP. Các gói tin ICMP và UDP chỉ có thể đi vào khi chúng mang vai trò trả lời cho các request đi từ bên trong Linux server mà thôi. Điều này có nghĩa những gói ICMP họ 'tia' vào server của anh bị huỷ ngay khi đụng firewall. Vậy mà nhóm này vẫn nhắm mắt, nhắm mũi 'tia' đến mấy tiếng liên tục rồi mới chịu ngưng. Tất nhiên dạng tấn công như thế chẳng làm server suy suyển mảy may nào hết.

 Xin xem phần mục lục của series này ở bài giới thiệu.

Tôi đáp: "Ừa, 'kinh nghiệm chiến trường' đóng góp một phần nào đó nhưng theo anh, 'kế hoạch chuẩn bị' chu đáo giúp loại bỏ các sự cố này. Vậy, nhìn từ phương diện người dùng, em nghĩ sao nếu như em 'lỡ tay' gõ một giá trị gì đó và làm cả chương trình bị.. treo?"

[..] Kinh nghiệm bản thân anh thấy dạng thăm dò 'active' thường cho thông tin chính xác hơn nhưng cũng còn tuỳ mình muốn lấy thông tin gì nữa. Ví dụ như cách thăm dò để lấy thông tin về domain name, các hosts trong domain và IP của chúng thì em chỉ cần query một DNS server nào đó thì đã có thể có một số thông tin. Ngay cả em dùng các công cụ online (web-based) để lấy thông tin loại này cũng thuộc dạng 'passive' và cũng có thông tin khá chính xác (ngoại trừ công cụ online này sử dụng một DNS server nào đó có vấn đề). Nếu em muốn lấy thông tin cụ thể hơn và các hosts trong một mạng mà thông tin này không được công bố trên DNS công cộng thì phải vận dụng đến cách thăm dò 'active'. Nói tổng quát thì có những loại thông tin đòi hỏi dùng dạng 'active' thì mới lấy được. Cho nên, 'active' thì thường chính xác hơn nhưng ít kín đáo hơn, 'passive' thì kín đáo hơn nhưng những thông tin này mang tính tổng quát hơn.

Xin xem phần mục lục của series này ở bài giới thiệu.

 

Công tác của người làm bảo mật là tạo nên sự cân bằng giữa tiện dụng và bảo mật. Trong khi đó, vai trò của kẻ tấn công là tìm ra những điểm yếu của sự thiếu cân bằng giữa tiện dụng và bảo mật để thâm nhập.

[..] Vậy, tiện dụng là gì? Là những tính năng giúp cho việc sử dụng dễ dàng, đỡ mất công và nhanh chóng. Bảo mật là gì? Là những tính năng 'làm khó', làm cản trở sự thâm nhập. Những cái 'làm khó' này dẫn đến sự mất tiện dụng cho người dùng bình thường." 

[..] Sự cân bằng giữa 'tiện dụng' và 'bảo mật' nằm ở chỗ: những gì không cần tiện dụng, không nên làm cho nó tiện dụng; những gì nên bảo mật, không nên làm cho nó tiện dụng. Nhu cầu tiện dụng phải có giới hạn nhất định và giới hạn này được đánh giá dựa trên cái nhìn bảo mật chớ không phải dựa trên cái nhìn tiện dụng." 

[..] Nếu người làm bảo mật có cái nhìn vững vàng về bảo mật thì anh ta sẽ thiết kế hệ thống có những điểm tiện dụng nhưng phải cân bằng với bảo mật. Nếu kẻ tấn công có cái nhìn vững vàng về thâm nhập, hiểu rõ về hệ thống thì hắn ta sẽ có khả năng xác định được hệ thống này được đặt trên tiêu chỉ 'bảo mật' hay tiêu chỉ 'tiện dụng'. Nói cho cùng, nhu cầu cụ thể phải được xác định rõ ràng và cụ thể ngay từ đầu rồi mới hình thành được mức độ tiện dụng và bảo mật.

[..] Nhu cầu cụ thể là một yếu tố quan trọng để hình thành việc bảo mật

Xin xem phần mục lục của series này ở bài giới thiệu.

Việc 'hack' để phá vỡ một hệ thống làm việc chỉ là 'một mặt của vấn đề'; 'hack' còn có mục đích chống lại hành vi phá vỡ nữa.

[..] 'Hai mặt vấn đề' ở đây quy tụ lại một điểm: cả A và B đều phải biết rõ ssh có những chức năng gì? có thể 'hở' ở những điểm nào? Kẻ công thì khai thác những điểm nào bị 'hở', người thủ thì lo bít những điểm có thể bị 'hở'. Nhìn từ hai phía, cả hai đều phải có kiến thức. 

[..]  Tôi đáp: "Ừa, để mình có thể bàn ở cấp độ 'công' hay 'thủ' thì phải thật sự nắm vững cấu hình của dịch vụ và biết rõ lý do tại sao mình quyết định như vậy. Anh phải đi rồi. Nếu muốn, tuần sau mình tiếp tục hả?"

Xin xem phần mục lục của series này ở bài giới thiệu.