Messages posted by: prof

rickb wrote:

...
Khúc đầu thì mình hiểu nó muốn phân biệt file server là định nghĩa 1 hardware thông dụng (như PC) chạy 1 OS như unix hay windows để share file, còn NAS là 1 thiết bị chuyên dụng chạy 1 OS chuyên dụng để share file. Nhưng mình ko hiểu sau, nó bảo file server bên unix & win là native file-level protocols, còn NAS hỗ trợ mainstream file-level protocols. Vậy "native file-level protocols" và "mainstream file-level protocols" là gì ? chúng khác nhau như thế nào ?

Ai biết thì giải thích giùm mình (hoặc có tài liệu thì share cho mình đọc cũng được), cám ơn nhiều
Thân

Hello rickb,

Ý nghĩa của đoạn cuối trong trích dẫn từ tài liệu của bạn, theo tớ hiểu một cách tổng quan, như sau:
- Về bản chất, Windows File Servers sử dụng file-level protocol là http://en.wikipedia.org/wiki/Server_Message_Block, và Unix File Servers sử dụng file-level protocol là http://en.wikipedia.org/wiki/Network_File_System_(protocol), cho các vấn đề liên quan đến file, kể cả storage solutions. Các protocols SMB/CIFS, NFS là các native file-level protocols vì chúng nguyên thủy được thiết kế nhằm mục đích phục vụ chỉ cho một loại OS đặc thù, mà ở đây là Windows hay Unix.
- NAS hỗ trợ mainstream file-level protocols đồng nghĩa với việc NAS có khả năng hỗ trợ multiple file-level protocols, bao gồm các giao thức, chẳng hạn như SMB/CIFS, NFS ở trên, hiện tại đang được sử dụng phổ biến. Đây rõ ràng là một thế mạnh của NAS.

Nhân tiện, tớ cũng vắn tắt về một số giải pháp cho vấn đề file level storage hiện nay mà có thể bạn đã tìm hiểu. Hiện tại có lẽ có 3 giải pháp phổ biến:
1. Sử dụng SANS file systems hoặc các giải pháp tương tự.
2. Sử dụng File Servers thông thường, chẳng hạn Windows FS, hoặc Linux FS.
3. Sử dụng NAS.
Tùy vào quy mô và nhu cầu của doanh nghiệp mà họ chọn giải pháp phù hợp.

Hi vọng giải đáp được thắc mắc của bạn smilie

.

Thân mến.

Mr.Khoai wrote:

...
Câu hỏi là:

1. Cơ chế ad-hoc default thì node 2 có relay các gói tin nhận được hay không.

Hello Mr.Khoai,

Trước tiên, có lẽ ta phải thống nhất ở cách dùng thuật ngữ một chút smilie

. Thực vậy, mesh network về bản chất nó đã là một trường hợp riêng của ad hoc network rồi nên nếu dùng Ad hoc mesh network thì có vẻ như hơi bị thừa từ "Ad hoc". Chút góp ý với bạn như vậy.

Về câu hỏi đầu tiên, theo mặc định của cơ chế ad hoc, node 2 phải có khả năng relay/forward các gói tin nhận được, như vậy một network mới có tính chất Ad hoc. Do đó, một mesh network chắc chắn sẽ thừa hưởng tính chất này của ad hoc network. Yên tâm nhé smilie

.

2. Khoai có tìm ra một số hack cho kernel linux để linux có thể tự build một topology cho network (self-configure và self-heal) và tiến hành route [*] các gói tin tự động để các node ở xa có thể liên lạc trực tiếp với nhau. Cho hỏi có ai biết có user space hoặc kernel module nào giúp làm việc này gọn gàng "nhẹ" hay không.

Thông tin về cấu hình của các node: Sử dụng embeded linux trên một custom hardware set. 400Mhz processor speed + 16Mb flash memory và 32 Mb Ram.
...

Thành thực mà nói, để build một mesh network là một việc hoàn toàn không đơn giản. Theo tớ biết, không những nó liên quan tới phần kernel modification, embedded devices, mà còn liên quan tới phần routing giữa các nodes. Hiện nay, tớ thấy AODV protocol được sử dụng khá phổ biến cho việc set up routing trong ad hoc network nói chung, và mesh network nói riêng.

Ngoài ra bạn còn phải khảo sát về transmission power settings, multiple transmission rates,... để có thể setup thành công một mesh network. Số nodes càng nhiều, thì độ phức tạp khi quản lý/điều chỉnh các thông số trên càng tăng.

Về software, hiện tại, tớ thấy http://openwrt.org/ cũng được sử dụng khá phổ biến để customize các embedded devices.

Theo tớ biết, hiện nay có một số project tương tự đã và đang được triển khai:
1. http://smesh.org/ (của trường ĐH John Hopkins)
2. http://www.cuwin.net/projects/urbana (của trường ĐH UIUC)

Hi vọng bạn có thể tham khảo được điều gì đó từ các project này.

Chúc bạn thành công smilie

To hongtham & luckilac: Tôi đề nghị các bạn hãy dừng ngay việc viết các bài chửi bới, bôi nhọ nhau và người khác trên diễn đàn! Đây không phải là nơi thích nói gì thì nói, thích viết gì thì viết. Làm ơn xem lại nội quy nếu muốn tiếp tục tham gia sinh hoạt tại HVA.

Hello GirL Noob,

Trước tiên, rất cảm ơn bạn đã có loạt bài viết tỉ mỉ cho HVA. Tuy nhiên, nếu lược bỏ đi một số câu từ đả kích một vài cá nhân, hay nhóm người nào đó ít nhiều có liên quan đến bạn, thì bài viết của bạn sẽ hay hơn. Khi đó, các thảo luận sẽ tập trung vào chuyên môn, thay cho việc xuất hiện lời qua tiếng lại trên diễn đàn mà tôi nghĩ bản thân bạn cũng không muốn thế, đúng ko nhỉ? smilie

)

Mong bạn GirL Noob rút kinh nghiệm cho các bài viết sau.

Thân.

newbie_newbie wrote:

kính gửi BQT, em có 1 thắc mắc nhỏ nhờ các huynh giải đáp giúp là em thấy sao đội ngũ mod, admin bên hva lạ quá như là elite, moderartor, validating... Không như bình thường là mod, super mod... Vậy BQT có thể dành ít thời gian giải thích cho em hiểu về vấn đề này ko ? Cộng với quyền hành riệng đối với từng cấp.
À, em nhớ là hình như trước năm 2005 thì phải, diễn đàn vẫn giữ cơ chế là mod, admin, sao bây giờ ko thấy admin mà chỉ còn moderator ?
Em Xin Cám ơn

Hi newbie_newbie,

Về câu hỏi trên, bạn tham khảo thêm ở đây: hxxp://hvaforum.net/hvaonline/posts/list/3278.html

Các bài liên quan khác, bạn có thể tìm thấy trong box Thông báo từ HVA. Nên tìm kiếm trước khi đặt câu hỏi nhé.

Thân.

Ke Kho wrote:

nếu dùng lệnh fdisk /mbr thì dữ liệu ko hề bị sao và vẫn sẽ boot vô win đc chứ ? em hỏi cho ăn chắc kẻo hư hết bột đường !
thanks !

Hello Ke Kho,

Một cách *nôm na*, lệnh fdisk /mbr chỉ đơn thuần khôi phục lại Windows Loader mà thôi. Nói cách khác, lệnh này sẽ nạp trình Windows Loader vào MBR.

Bản chất của MBR chỉ đơn thuần tìm active (bootable) partition trong partition table của nó để trao quyền khởi động cho partition đó. Vì vậy, bạn có thể yên tâm sử dụng lệnh này mà không sợ hư hết bột đường đâu. smilie

)

Chúc thành công smilie

)

ghost_net wrote:

Em bi dính một con virus an het các file .exe. Em biết cách diệt nhưng khi diệt lại mất các file của em (vô cùng quan trọng)
Các bác có cách nào cứu chưa hộ em với ạ!

Hi ghost_net,

Bạn muốn được trợ giúp mà chỉ cung cấp vẻn vẹn có một vài dòng thông tin như thế này thì tôi nghĩ đến "thánh", dù rất muốn giúp bạn, cũng đành bó tay mà thôi!

Làm ơn trình bày, mô tả cụ thể hơn. Chẳng hạn, bạn bị nhiễm virus nào, đã dùng phần mềm diệt virus nào, đã diệt như thế nào mà lại mất hết các file, đã thử những cách gì, v..v... Có như thế, người muốn giúp bạn mới có thể hỗ trợ bạn được.

Một điều nữa, nên đọc nội quy để đặt tiêu đề cho rõ ràng & phù hợp hơn.

Thân.

Chào cả nhà,
Chào alice,

Prof rất vui khi nhận được comments từ alice, father_nghia_den, và thangdiablo. Mấy ngày qua mình khá bận nên việc reply có phần chậm trễ. Mong các bạn thông cảm. Bây giờ ta tiếp tục thảo luận nhé. smilie

)

alice wrote:

Bài bổ sung của prof rất tốt, alice chỉ nghĩ có thể bài viết sẽ dễ hiểu hơn nếu thay đổi vài điểm về thuật ngữ. )

Uhm, mục đích của bài viết bổ sung cho loạt bài của bạn thangdiablo là nhằm đào sâu hơn một chút về những thứ mà thangdiablo chưa có dịp đề cập đến. Rõ ràng, bài viết sẽ không thành công nếu như tạo thêm sự khó hiểu cho người đọc. Vì vậy, trong quá trình thảo luận, mình sẵn sàng "thay đổi vài điểm về thuật ngữ" nhằm giúp độc giả *tiêu hóa* tốt hơn. Cũng cần nói thêm là bài bổ sung trên được viết khá gấp rút, nên không thể tránh khỏi thiếu sót. Góp ý của các bạn sẽ giúp bài viết thêm phần hoàn thiện. smilie

)

prof wrote:

Lý do AH có khả năng cung cấp cơ chế xác thực và bảo đảm tính toàn vẹn (integrity) của dữ liệu là vì AH Header chứa một chữ ký số (Digital Signature - DS) được gọi là giá trị kiểm tra tính toàn vẹn (Integrity Check Value-ICV). Thực chất nó là một giá trị băm được dùng để kiểm tra xem liệu gói tin có bị thay đổi trên đường truyền hay không. Vì AH sử dụng IP header để tính toán DS nên chúng ta có thể chắc chắn rằng địa chỉ nguồn của gói tin là xác thực và gói tin này xuất phát từ đúng nơi gửi.
Dùng từ ICV là đủ, tránh dùng từ DS. ICV nói chung không phải là DS và thực tế không phải là DS.

Trước tiên, hoàn toàn đồng ý với alice ở điểm ICV không phải là DS. smilie

) Tuy nhiên, khi viết đoạn này, ý đồ của mình không nhằm so sánh DS và ICV. Mình tuy là kẻ *ngâm cứu* không chuyên về applied crypto. & its related stuffs nhưng cũng may mắn hiểu được sự khác biệt về phạm vi ứng dụng, và về bản chất của DS. Trong phạm vi bài này, mình sử dụng DS với mục đích giúp người đọc hiểu được những lợi điểm do ICV đem lại, kiểu như dùng một thuật ngữ đã quen thuộc để giải thích cho một thuật ngữ mới hơn. Có lẽ chúng ta đều biết DS có khả năng cung cấp tính xác thực (Authentication), tính toàn vẹn (Integrity), và tính chống phủ nhận (Non-repudiation). ICV trong AH Header cũng hội đủ các điều kiện để cung cấp 2 trong 3 khả năng này. Vì vậy, ở một khía cạnh hẹp & trực quan nào đó, ICV mang đặc điểm của DS.

Mình cũng đã từng gặp ở một số tài liệu khác, khi đề cập đến một intemediate device/application/middleware/..., người viết thường mượn thuật ngữ proxy server nhằm mục đích nói lên tính trung gian của đối tượng đang xét, mặc dù nếu khắt khe hơn, thì proxy server không thể là đối tượng mà họ đang bàn. Đó chỉ là một ví dụ khá *thô* về cách dùng thuật ngữ mà thôi. smilie

)

Anyway, có lẽ mình đã lạm dụng thuật ngữ DS này nên dẫn đến hiểu lầm. Prof sẽ chỉnh sửa lại đoạn này bằng việc bỏ đi thuật ngữ DS. smilie

prof wrote:

Cách thức hoạt động của ESP có khác biệt đôi chút phụ thuộc vào chế độ làm việc của IPSec. Trong chế độ Transport, ESP chỉ đơn thuần thêm phần header của bản thân nó vào sau phần IP header và mã hoá toàn bộ phần còn lại của gói tin từ tầng 4 trở lên. Nếu trong quá trình thương lượng khởi tạo một IPSec connection có chỉ định sử dụng dịch vụ xác thực của ESP, khi đó ESP sẽ thêm một phần (trailer) chứa thông tin ICV để đảm bảo tính toàn vẹn và tính xác thực. Không giống với AH, ESP ICV không tính toán dựa trên các thông tin về IP header.

ESP thường được xem như là sự kết hợp của IPSec với NAT. ESP thường được sử dụng trong chế độ tunnel. Tuy nhiên trong chế độ transport, ESP và NAT không tương thích với nhau vì các thông tin của phần header của gói tin đã bị NAT thay đổi. Khi NAT thực hiện thay đổi phần thông tin về IP, nó cũng sẽ tính lại giá trị checksum trong TCP header. Và bởi vì TCP checksum được tính toán không chỉ dựa vào TCP header, mà nó còn dựa vào các thông tin từ IP header, như địa chỉ nguồn/đích của gói tin nên NAT đã phá vỡ tính toàn vẹn của gói tin. Trong chế độ Transport ESP, toàn bộ TCP header đã được mã hoá, NAT box sẽ không thể tính toán lại TCP checksum. (Vấn đề tương tự đối với UDP packets khi UDP checksum được tính đến). Kết quả là trước khi giải mã, gói tin sẽ bị hủy vì không bảo đảm tính toàn vẹn. Vấn đề này có thể được giải quyết nếu như không đụng đến TCP checksum trong mọi trường hợp.
Chỗ IPSec màu vàng có vẻ khó hiểu. Đối tượng đang được giải thích là IPSEC. ESP là một phần của IPSEC. Sẽ không hợp lý lắm khi đem IPSEC để giải thích ESP.

Khi đưa TCP/UDP vào cuộc, cũng nên nói rõ hoàn cảnh sử dụng là ESP bao bọc TCP/UDP. Để phân biệt với hoàn cảnh UDP bao bọc ESP (NAT-T) mà loạt bài sẽ nói đến về sau.

Yep! Câu trên đúng là gây khó hiểu. Rất may mắn, bạn father_nghia_den đã giải thích lại giúp một cách hợp lý. Thanks father_nghia_den. smilie

)

Đoạn này có thể xem như có 2 phần:

Phần NAT màu vàng thứ nhất nói về tính tương thích của NAT với ESP. Ở đây nên làm rõ thêm từ NAT bởi một từ khác (thí dụ, basic NAT theo tự điển wikipedia), ngụ ý rằng ở đây chỉ có dịch địa chỉ mà thôi. Cũng nên nói rõ thêm NAT trong trường hợp chung (bao hàm PAT) với ESP trong chế độ tunnel là không tương thích bởi vì khác với TCP/UDP, ESP không có khái niệm "cổng". Như thế người đọc sẽ không phải thắc mắc đại loại như nếu ESP tunnel và NAT đã tương thích với nhau, tại sao phải dùng UDP bao bọc ESP để có NAT-T?

Thanks alice. Mình quả thật đã thiếu xót khi không đề cập đến khía cạnh NAT-T trong IKE.

Phần NAT màu vàng thứ hai nói về tính tương thích của NAT với IKE, cũng nên nói rõ hơn một chút (nhưng chính alice cũng chưa biết nói thế nào cho rõ ), tránh cho người đọc những thắc mắc kiểu như tại sao khác với nhiều giao thức trên nền TCP/UDP, IKE phải cố định cổng nguồn?.

Chà, xem ra "người đọc" muốn mở rộng thêm vấn đề về tính tương thích giữa NAT và việc cố định cổng nguồn của IKE đây. smilie

Trường hợp này, có lẽ phải mời người tham khảo thêm RFC 3715 để biết chi tiết. smilie

) Phải thừa nhận một điều là còn khá nhiều vấn đề giữa NAT và IPSec mà prof chưa thể nói hết. Bởi vậy, ngay từ đầu, mình chỉ dám đi sâu một chút, vì biết sẽ không đủ sức. Nếu alice hay bạn nào đó có thời gian, các bạn có thể bổ sung thêm những vấn đề mà mình chưa đề cập đến. smilie

Theo alice, cụm từ payload của ESP có lẽ sửa thành IP payload hoặc cụ thể hơn 1 chút thì ESP header mới đúng. Như chính prof đã nói, authentication trailer xác thực không những ESP payload mà còn cả ESP header, trong đó có SPI (security parameter index), từ đó dựa theo SAD (security association database) tra được địa chỉ IP của người gửi. Nói cách khác, với một chi phí tính toán thích đáng, cài đặt không cần phải xác thực IP header vẫn xác thực được địa chỉ IP nguồn của gói tin.

Đồng ý!

)

Hello thangdiablo,

Bài viết của bạn rất hay. Tuy nhiên, có một số điểm, prof nghĩ, nếu được đào sâu thêm một chút, sẽ hoàn thiện hơn.

- Nếu sử dụng giao thức ESP :
Thì giao thức ESP sẽ làm công việc là mã hóa ( encryption ) , xác thực ( authentication ) , bảo đảm tính trọn vẹn của dữ liệu ( Securing of data ) . Sau khi đóng gói xong bằng ESP mọi thông tin về mã hóa và giải mã sẽ nằm trong ESP Header .
Các thuật toán mã hóa bao gồm DES , 3DES , AES
Các thuật toán để xác thực bao gồm MD5 hoặc SHA-1
ESP còn cung cấp tính năng anti-relay để bảo vệ các gói tin bị ghi đè lên nó.

- Nếu sử dụng giao thức AH
Thì giao thức AH chỉ làm công việc xác thực ( authentication ) và bảo đảm tính trọn vẹn dự liệu . Giao thức AH không có chức năng mã hóa dự liệu . Do đó AH ít được dùng trong IPSec vì nó không đãm bảo tính an ninh .

Lý do AH có khả năng cung cấp cơ chế xác thực và bảo đảm tính toàn vẹn (integrity) của dữ liệu là vì AH Header chứa một "chữ ký số" -1- được gọi là giá trị kiểm tra tính toàn vẹn (Integrity Check Value-ICV). Thực chất nó là một giá trị băm được dùng để kiểm tra xem liệu gói tin có bị thay đổi trên đường truyền hay không. Vì AH sử dụng IP header để tính toán ICV nên chúng ta có thể chắc chắn rằng địa chỉ nguồn của gói tin là xác thực và gói tin này xuất phát từ đúng nơi gửi.

Hơn nữa, AH cũng sử dụng các giá trị sequence number hỗ trợ việc chống lại kiểu tấn công phát lại (replay attack). Vì các thiết bị truyền thông sử dụng giá trị này để theo dõi dòng dữ liệu trao đổi, một kẻ tấn công với ý định chiếm quyền truy cập vào VPN không thể gửi lại gói tin mà hắn "bắt" được.

Ngoài ra, một vấn đề cần lưu tâm ở đây, đó là AH xác thực gói tin dựa vào thông tin IP header. Do vậy, nó sẽ không tương thích với các thay đổi do cơ chế NAT mang lại. Vì giá trị ICV của AH đã được tính toán trước NAT nên khi gói tin được gửi tới đích, việc kiểm tra tính toàn vẹn sẽ thất bại(!)

Mặt khác, vì AH không hỗ trợ bảo vệ tính mật (confidentiality) của dữ liệu trong các gói tin, nên nó sẽ không phải thực hiện tính toán nhiều để mã hoá các gói tin, do đó công việc xử lý và đóng gói các gói tin sẽ dễ dàng và nhanh chóng hơn. Đây là những đặc điểm góp phần làm cho AH trở thành một giải pháp hợp lý cho những nơi chỉ cần bảo toàn và xác thực thông tin địa chỉ IP và cần hiệu năng cao. smilie

Để có thể xem thông tin chi tiết về một AH packet, bạn có thể dùng tcpdump để thu bắt thông tin về AH traffic. Khi đó, bạn sẽ thấy phần payload của gói tin sẽ không được mã hoá vì AH không hỗ trợ cơ chế này. smilie

....
4 . Giao thức ESP
Phía dưới đây là cơ chế mã hóa gói dữ liệu bằng giao thức ESP

Esp là giao thức hỗ trợ cả xác thực và mã hóa .

Phía trên là gói dự liệu ban đầu và ESP sẽ dùng 1 cái key để mã hóa toàn bộ dữ liệu ban đầu . Và trường hợp trên là Ipsec đang chạy ở chế độ Tunel mode nên ngoài ESP header ra nó sẽ sinh ra 1 Ip Header mới không bị mã hóa để có thể truyền đi trong mạng Internet .

....

Cách thức hoạt động của ESP có khác biệt đôi chút phụ thuộc vào chế độ làm việc của IPSec. Trong chế độ Transport, ESP chỉ đơn thuần thêm phần header của bản thân nó vào sau phần IP header và mã hoá toàn bộ phần còn lại của gói tin từ tầng 4 trở lên. Nếu trong quá trình thương lượng khởi tạo một IPSec connection có chỉ định sử dụng dịch vụ xác thực của ESP, khi đó ESP sẽ thêm một phần (trailer) chứa thông tin ICV để đảm bảo tính toàn vẹn và tính xác thực. Không giống với AH, ESP ICV không tính toán dựa trên các thông tin về IP header.

ESP là giải pháp cho phép IPSec chạy trên hệ thống có xảy ra quá trình NAT với điều kiện IPSEC được thiết lập ở chế độ tunnel -2-. Tuy nhiên trong chế độ transport, ESP và NAT không tương thích với nhau vì các thông tin của phần header của gói tin đã bị NAT thay đổi. Khi NAT thực hiện thay đổi phần thông tin về IP, nó cũng sẽ tính lại giá trị checksum trong TCP header. Và bởi vì TCP checksum được tính toán không chỉ dựa vào TCP header, mà nó còn dựa vào các thông tin từ IP header, như địa chỉ nguồn/đích của gói tin nên NAT đã phá vỡ tính toàn vẹn của gói tin. Trong chế độ Transport ESP, toàn bộ TCP header đã được mã hoá, NAT box sẽ không thể tính toán lại TCP checksum. (Vấn đề tương tự đối với UDP packets khi UDP checksum được tính đến). Kết quả là trước khi giải mã, gói tin sẽ bị hủy vì không bảo đảm tính toàn vẹn. Vấn đề này có thể được giải quyết nếu như không đụng đến TCP checksum trong mọi trường hợp. smilie

Trong chế độ Tunnel ESP, NAT hoàn toàn được tương thích vì toàn bộ gói tin nguồn bao gồm các thông tin về IP và thông tin ở tầng 4 được đóng gói và do đó không bị xử lý bởi NAT. Vì thông tin về IP, TCP header, TCP checksum không bị thay đổi trong chế độ Tunnel ESP nên gói tin sẽ được giải mã và thoả mãn tính toàn vẹn. Tuy nhiên, mặc dù ESP traffic trong chế độ Tunnel có thể tương thích với NAT, bạn sẽ gặp phải các vấn đề liên quan đến NAT khi thương lượng các tham số cho IPSec connection. Chẳng hạn, one-to-many NAT (thường được hiểu là PAT) sẽ sửa đổi tham số cổng nguồn của một outbound IKE packet, dẫn đến giá trị cổng UDP 500 dành cho IKE bị thay đổi, từ đó dẫn đến việc thất bại khi phân phối khoá cho các tham số của IPSec session.

Một vấn đề còn đang tranh cãi nữa là khả năng xác thực của ESP. Như ta đã biết, ESP có khả năng cung cấp cơ chế xác thực, nhưng giá trị băm mà nó sử dụng được sinh ra dựa trên toàn bộ gói tin ngoại trừ phần IP header và phần authentication trailer. Điều này giúp cho ESP authentication tương thích với NAT, nhưng việc thiếu xác thực của IP header sẽ không đảm bảo được nguồn gốc của gói tin. May thay, trong hầu hết các cài đặt, việc kiểm tra tính xác thực cho phần IP payload -3- cũng đủ để nói lên nguồn gốc của gói tin này! smilie

Chúc vui.

-------------
-1- và -3-: chỉnh sửa theo góp ý của alice.
-2-: chỉnh sửa theo góp ý của father_nghia_den.

Mr.Khoai wrote:

Gửi prof: Ettercap quả là một tool có rất nhiều chức năng. Nó vẫn đóng vai trò Man In the Middle khi tiến hành sniff dữ liệu giữa 2 đầu của một ssh hoặc ssl connection? Vậy các certificate mà ettercap tạo ra sẽ được thông báo cho user! Sau đó thì mọi dữ liệu đi que đều bị ettercap bắt được.
...

khoai

Hello Mr.Khoai,

Một cách *nôm na*, có thể xem máy cài đặt Ettercap đóng vai trò như một proxy chắn giữa 1 client A và 1 server B nào đó. Rõ ràng bằng cách này, Ettercap sẽ thu được toàn bộ thông tin về keys, certificates trong quá trình SSL handshake chẳng hạn. Theo như prof hiểu, khi client's certificate được gửi từ A -> B, nó sẽ bị sniff bởi Ettercap, và sau đó Ettercap sẽ sinh một fake certificate để gửi tới B. Quá trình này xảy ra tương tự cho chiều từ B -> A. Do đó, một khi thông tin về keys, certificates đều bị lọt vào tay của Ettercap, nó hoàn toàn có thể giải mã, mã hoá dữ liệu truyền thông giữa A & B.

Vậy có cách nào khắc phục triệt để tình trạng này? Hay phải thông báo cho từng user cẩn thận hơn với các message về certificate như vậy?

Thiết nghĩ bên cạnh các giải pháp áp dụng chung như prof đã đề nghị ở trên, đ/v các trường hợp riêng như thế này, giải pháp có thể phụ thêm như:
- Sử dụng Certificate của một 3rd-party đáng tin cậy (VeriSign chẳng hạn)
- Khuyến cáo end-users nhận thức rõ sự tồn tại của các fake certificates. Bởi vì thông thường người sử dụng không mấy khi để ý hoặc không mấy khi phân biệt đâu là một cert. giả mạo, đâu là cert. mà anh ta quen thuộc.

Thân mến. smilie

Chào cả nhà,

Hôm nay mới để ý thấy topic này đang bàn luận sôi nổi quá, tôi cũng xin được góp vài lời. smilie

Về bản chất, kiểu tấn công “ARP poisoning” là một trường hợp riêng của ARP spoofing attack. Cách hoạt động ARP Table poisoning như thế nào thì các bạn đã thảo luận rất rõ rồi.

Thanks anh em !
Tớ thấy một vấn đề nữa .
Mặc dù Web Server Cty tớ có hỗ trợ SSL .
Email Server thì có hỗ trợ SSL và SPA . Vậy mà khi tớ sniff thử thì vẫn thấy password toàn cleartext .
Tất nhiên tool của tớ có hỗ trợ ARP-HTTPS . Không lẽ SSL cũng thiếu an toàn đến vậy cơ à ?

Không chỉ SSL mà còn SSH, PPTP đều có thể bị sniff và bị giải mã (tham khảo thêm trong Ettercap).

gamma95 wrote:

...
tôi xin vd, tui là 1 thằng Admin trong LAN xài switch, tui nghi ngờ máy A nó dính Virus hay spyware gì đấy khiến A có thể biến thành Zombie, lúc đó tôi không có đk để đến trực tiếp máy A để quét virus chảng hạn, lúc đó tôi ngồi máy C và bắt đầu sử dụng ARP poisoning máy A để sau đó Sniff các gói packet từ máy A và phân tích xem các gói Packet đó có dấu hiệu của Zombie ko?? lúc đó máy tôi là máy C ko nhất thiết phải forward các gói tin từ máy A --> gateway thực vì ko cần thiết, làm thế khác nào tiếp tay cho spyware ?? Mục đích của tui lúc bấy giờ chỉ là "sniff một chiều" (theo các bạn định nghĩa :lol ) để khẳng định là máy A bị dính virus. Chỉ có vậy thôi, các bác cứ nghĩ sniff là phải hack hiếc là sao chời ?
ps: các bác cứ bàn về phương pháp chống đi, nhất là cách phát hiện ARP reply ko hợp lệ

Về cách sử dụng ARP Poisoning mà bạn gamma95 đề nghị để kiểm tra xem máy nào trong LAN bị nhiễm virus cũng rất thú vị. Thật sự cho đến nay tôi cũng chưa thấy ai dùng cách này để troubleshoot bao giờ! Theo tôi biết, hiện tại trên hầu hết các CISCO Switch đều hỗ trợ SPAN port để thực hiện việc sniff toàn bộ các gói tin cần thiết ra/vào một port nào đó, thậm chỉ cả trunk port (cho mục đích sniff VLANs). Nếu muốn sử dụng chức năng SPAN này, các bạn hoàn toàn có thể tham khảo các tài liệu đi kèm trên các Catalyst Switch tương ứng để cấu hình cho phù hợp.

Về cách chống ARP spoofing nói chung và ARP poisoning nói riêng, cho đến nay thật sự chưa có một giải pháp hoàn hảo nào. Các cách phòng chống theo như tôi được biết đều phải kết hợp nhiều biện pháp khác nhau. Nếu chỉ áp dụng cách nhập ARP entries “bằng tay” thì tôi e rằng sẽ quá sức đối với một admin quản lý một hệ thống mạng tầm trung. Thông thường trước đây tôi cũng chỉ áp dụng cách này đối với routers & servers trên các mạng LAN qui mô nhỏ mà thôi.

Tôi cũng xin giới thiệu công cụ http://www.securityfocus.com/tools/3517 cho môi trường Windows, bên cạnh Arpwatch (cho *NIX) mà bạn vietwow đã đề nghị. Tuy nhiên, Arpwatch thường không thích hợp đ/v mạng sử dụng DHCP. Nguyên nhân vì sao thì các bạn có thể tự tìm hiểu thêm nếu có hứng thú. smilie

Gần đây có https://www.arp-guard.com/index.epl.en?set=1 và http://sguil.sourceforge.net/index.php?page=download cho *nix. Cơ chế hoạt động của Arp-Guard có phần dựa trên cách thức hoạt động của các hệ thống IDS. Đó là dựa trên các LAN sensors để kiểm soát các thông tin lien quan đến ARP. Thực sự thì tôi cũng chưa có dịp sử dụng công cụ này. Bạn có thể dùng nó nếu thấy hiệu quả. smilie

Hiện nay, theo tôi được biết thì có một nhóm phát triển S-ARP (Secure ARP). Nếu các bạn quan tâm, các bạn có thể tìm đọc tài liệu: http://www.acsac.org/2003/papers/111.pdf. Biết đâu lại giúp ích được gì đó cho bạn. smilie

Chúc vui.