Đương nhiên với sự an toàn của bản thân, tôi sẽ chọn public wireless network. Nhưng điều này không trực tiếp cho thấy phải quản lý các public wireless network.
 

Dù là "nổi" hay "chìm", bản chất vẫn là "tấn công" và theo binh pháp Tôn Tử, muốn chiến thắng một cuộc chiến, trước hết phải kiện toàn bản thân! 

Mr.Kas wrote:

Dựa vào bài viết này, tớ xin đặt ra một vấn đề là liệu việc dùng Wifi chùa hay là wifi free này để sử dụng cho các mục đích không trong sáng như "lấy cắp thông tin thể tín dụng", "điều khiển mạng botnet", "giao dịch hay là hội thảo những vấn đề nhạy cảm (chỉnh trị, phản động, ...)", ... thì có cách nào ngăn chặn hay không? Nếu ai đã có kinh nghiệm trong việc này có thể cùng tham gia thảo luận để đưa ra biện pháp khắc phục hoặc hạn chế.
 

Từ đầu topic đến giờ, em thấy mọi người tập trung vào trả lời cho câu hỏi mà chủ topic đặt ra "làm thế nào để ngăn chặn việc sử dụng free wifi cho mục đích nguy hại cho xã hội?". Từ đây em nảy ra một câu hỏi khác: "Liệu việc tìm câu trả lời cho câu hỏi trên có cần thiết không?"

Ví dụ: Một người nào đó định dùng free wifi để:
- "lấy cắp thông tin thẻ tín dụng": Một điều chắc chắn là người đó sẽ không lấy được khi mà web server administrators có ý thức và khả năng nâng cao độ bảo mật của web server do họ quản trị
- "điều khiển mạng botnet": Tương tự như trên, nếu độ bảo mật của hệ thống tốt thì họ cũng khó làm được.
- "giao dịch hay là hội thảo những vấn đề nhạy cảm (chỉnh trị, phản động, ...)": Lúc này, lại là vấn đề nhìn nhận của người nhận thông tin đó. Bởi vì, nếu thông tin phản động không truyền từ free wifi thì cũng có thể truyền từ vô số con đường khác.

Từ những ví dụ trên, em đi đến kết luận câu hỏi "làm thế nào để ngăn chặn việc sử dụng free wifi cho mục đích nguy hại cho xã hội?" không cần thiết phải trả lời mà hãy dành thời gian nâng cao bảo mật ở những hệ thống mà chúng ta quản trị

Vài ý kiến đóng góp! 

- Luật đó thì ko cụ thể, nhưng nói chung khi xảy ra chuyện, bên công an họ sẽ lần ra dấu vết của quán cafe đó, họ sẽ phỏng vấn chủ quán và nhân viên, hỏi khách hàng nào, đã ra vào ra sao, dùng máy tính thế nào, mô tả nhận dạng... Nói chung là phiền phức và có thể chủ quán sẽ bị điều tra (biết đâu anh ta chính là thủ phạm...). Trách nhiệm liên đới là thế. Cái này nhiều chủ quán Internet đã dính đòn, khi việc đó liên quan đến an ninh quốc gia, bên an ninh họ tới bê nguyên cả dàn máy tình về, kiểm tra từng ổ cứng, kiểm tra xem chủ quán có ghi lại số CMND... của khách không, chỉ mặt từng ông khách...

- Việc đó ngăn chặn được ai đó muốn tạo virtual server một cách bừa bãi, ko có pass đó thì quên việc tạo VS đi.

- Kiểu dùng ở nhà hay cơ quan khác với kiểu ở quán cafê hay là Hotel, đơn giản vì tập hợp người sử dụng là tương đối ổn định, biết mặt biết tên. Ở Hotel hay cafe, thì khách vãng lai, nhiều loại wifi client khác nhau. Do đó giải pháp áp dụng security cho 2 trường hợp này khác nhau. Bài này nói về kiểu Hotel hay cafe nên về security hiện chưa có gì nhiều để mà nói. 

Wifi chỉ là công cụ kết nối tương tự mạng LAN, chỉ khác là nó không có dây. Việc bảo mật nó là trách nhiệm của chủ cái mạng WLAN đó, họ cho phép/không cho phép, dù vô tình hay hữu ý để mạng WLAN và kết nối ADSL của họ bị lợi dụng, để làm phishing hay bất cứ thứ gì (kể cả kết nối outbound tấn công 1 site nào đó), thì họ phải chịu trách nhiệm liên đới (nếu có việc xảy ra).
Về cái việc mở Inbound hay Virtual Server, kỳ thực dễ chống lắm, chỉ cần thay đổi mật khẩu mặc định của router/gateway kết nối Internet thành 1 chuỗi khó đoán là được.

Còn bảo mật riêng cái Wifi, kiểu như để người nhà mình hay cơ quan xài thay cho LAN, thì nên nói ở một mục khác. Cái này nó tuỳ theo điều kiện, loại client mà mình phải phục vụ và mức độ an toàn cần thiết. 

theo e hiểu thì Load Banlancing đối với server là cân bằng tải giữa 2 server, vd HVA có 1 server bên Mỹ và 1 bên Nhật, khi có 100 người truy cập thì Load Banlancing có nhiệm vụ chuyển 50 người truy cập qua bên server Mỹ, 50 người qua server bên Nhật. (cái này theo ý hiểu cá nhân có j sai mong các bác chỉ bảo)
nhưng mục đích của e ở đây muốn hỏi là em dùng 2 line adsl cho client thì có cách gộp tốc độ download của 2 line adsl ko? vd line VNN là 3MB, line viettel là 2MB thì tổng download có đc 5MB ko?
nếu có thể làm đc thì dùng phần mềm nào, hay phần cứng nào? 

Phần mềm này mang đúng nghĩa "phần mềm". Nghĩa là k0 dùng bất kỳ 1 phần cứng của hãng nào khác cả. Chỉ cần n line DSL + n DSL Modem. Vậy thôi smilie. 

Có cả web rao vặt chắc bồ làm ăn khá nắm nhỉ.
Bồ gởi cho tui vài trăm USD rùi tui hướng dẫn cho.
Đùa vậy thui, nếu bồ mún phòng chống thực sự thì lên thuê chuyên gia bảo mật hoặc lên hệ với ISP để được hỗ trợ.
Còn không thì nên học bảo mật đi, dân CNTT VN chán ở chỗ được cái nọ hỏng cái kia.
Mình góp ý vậy thôi.
Bây giờ trăm ngàn loại Server rùi cả Web ai mà biết hết được để hướng dẫn cho bồ.
Vậy nha. 

Theo mình thấy, nếu làm về mạng Cisco chỉ cần hiểu cơ bản TCP/IP, rồi đọc tài liệu Cisco là đủ rồi. Không biết ý bạn SG chạy nhanh chạy chậm hiểu như thế nào nhỉ?  

2 điểm này cần nói thêm là:
- MTA và MUA của 1 tổ chức mới xác thực với nhau, hoặc là của ISP với khách hàng của ISP đó. Chứ còn của 2 công ty partner với nhau để xác thực user+password với nhau thì trao đổi "pass" hơi mệt đấy.
- MUA với MTA chỉ cần sử dụng SMTP with START-TLS hoặc là SMTP over SSL là đảm bảo toàn vẹn, bí mật và MUA xác thực được MTA là ai qua SSL cert. Còn MTA xác thực MUA là ai thì bằng user+pass. Như thế đã được coi là trusted rồi, không cần thêm VPN làm gì cho rắc rối. Telnet chỉ là demo thôi, nếu muốn tớ ... telnet over stunnel là được chứ gì?  

Trong trường hợp này đó là mối liên quan giữa "sending MTA" và "receiving MTA" (như mô hình bên dưới) chớ không phải giữa "sending MUA" và "receiving MTA" hoặc "sending MTA".

sending MUA ---> MSA ---> sending MTA ---> receiving MTA ---> MDA ---> receiving MUA. 

Qmail + RBL không phân biệt được MUA với MTA trong trường hợp này, dù cả MUA lẫn MTA đều dùng SMTP nhưng MUA có AUTH LOGIN trước mọi cái khác.  

Nếu Alice đang dùng một máy có network không thuộc network "white list" mà access MTA này thì nó phải reject bởi vì đây là nguyên tắc không cho phép open relay. Cách duy nhất và tạm gọi là "reliable" là cách cho phép Alice "pop before smtp", đây là một cách buộc Alice phải authenticate xuyên qua pop3 (nhận mail) trước khi tạm thời open relay để Alice có thể gởi mail (xuyên qua smtp) vào qmail (rồi qmail mới gởi mail của Alice đến một MTA khác là đích).  

- Xét điểm 3 và 4: user của em là thuê bao ADSL, Dynamic IP, mà dải đó bị RBL.
Họ gửi mail cho 1 ai đó. MUA sẽ kết nối đến mail server, sau chuỗi lệnh: EHLO xxx, AUTH LOGIN .... bị reject luôn vì RBL (giống như cái telnet em paste trước đó).
Thế là họ khỏi gửi luôn => complaint. Đúng ra thì sau khi AUTH LOGIN, user của em được relay thoải mái.

Qmail + RBL không phân biệt được MUA với MTA trong trường hợp này, dù cả MUA lẫn MTA đều dùng SMTP nhưng MUA có AUTH LOGIN trước mọi cái khác.
Tại sao Qmail lại thế thì các post trước của em đã nói. Em dùng Postfix thì xử lý được vấn đề trên.
 

nxthao wrote:

@quanta : Bonding : combine multiple network ports into a single group, effectively aggregating the bandwidth of multiple interfaces into a single connection 

Vậy ứng dụng trong trường hợp này là nó để làm gì? Bonding hoạt động ở layer mấy? Nói đến bonding là trong LAN hay ngoài WAN nhỉ?
 

Có nhiều người cũng giải ra được mà anh, em ko dám múa rìu đâu hehe
Hơn nữa sau khi share cái file HTML cho một vài bạn làm thì thấy các bạn dùng debugger khá nhiều, em chủ yếu viết code để decode nên cách làm dài dòng lắm. Ví dụ như bước đầu tiên, em viết 1 đoạn script để đọc được mã us-ascii thì bạn em nó dùng IE, open + save as là xong. 

Phá và ngăn chặn : khóa mã bảo mật WEP trên định tuyến không dây. 

lạc hướng ở chỗ nó đâu có implement việc gửi lại TCP Segments trực tiếp cho receiver. Mỗi đầu đều phải có 1 WAE đóng vai trò làm TCP Proxy.

--0 

StarGhost wrote:

Ồ, cái này thì đơn giản thôi: có một điều chắc chắn rằng intermediate systems không thể biết được TCP congestion control được sử dụng ở endpoints ra sao, thế nên việc tự ý retransmission sẽ dẫn đến packet duplications. Packet duplications sẽ dẫn đến duplicate acknowledgements. Nếu nhiều duplicate acknowledgements sẽ dẫn đến việc TCP thắt chặt sliding windows, và cuối cùng là dẫn đến giảm tốc độ truyền dữ liệu. Ngoài ra, packet duplications còn dẫn đến các vấn đề về pricing.

Trên thực tế thì không phải lúc nào cũng như vậy, và tùy vào môi trường lẫn configuration, nhưng không có nghĩa là nó không thể xảy ra.

Duy có một ngoại lệ của việc retransmission ở intermediate systems là trong Wireless LAN, do BER và FER là tương đối lớn. Tuy nhiên, việc retransmission này không có vấn đề là vì: thường không có vấn đề về pricing, retransmission diễn ra ở data link layer, retransmission diễn ra trong local loop nên không tạo ra nhiều ảnh hưởng đến network. 

Nếu như packet từ Endpoint khi được gửi xuyên qua intermediate systems ( trong trường hợp cụ thể này là thiết bị Cisco có gắn module WASS ). Thiết bị WAAS này sẽ có trách nhiệm lưu giữ tạm thời và đánh dấu những gói này trên NVRAM.
Sau 1 khoảng thời gian nếu không thấy phía bên kia báo thiếu thì những gói lưu giữ tạm thời này sẽ bị hủy.
Còn nếu thiếu nó sẽ tự động gửi lại thay vì chờ Endpoint.

Theo StarGhost thế có ổn không?


 

StarGhost wrote:

@thangdiablo: việc IP address có bị thay đổi hay không đâu có phụ thuộc vào thiết bị của Cisco hay là công nghệ gì gì đó. Vì vậy mình nghĩ quanh đi quẩn lại vẫn là VPN thôi.
 

Hi StarGhost: Bạn đọc kỹ lại bài mình viết.
Mình đâu có nói việc IP bị thay đổi do thiết bị Cisco. Để mình giải thích lại thế này.

Giả sử mình có 2 Peer HN và SG.
Trên 2 peer này mình sử dụng Cisco Router có module WAAS.
Giữa 2 peer này là của nhà cung cấp. Họ dùng gì ở giữa thì tùy ( có thể là Cisco, có thể là Nortel, có thể là Dlink ... )

Bây giờ 1 gói tin đi ra từ trong LAN của HN tới LAN của SG. Trên Router của 2 peer này tất nhiên là có apply các chính sách mã hóa và toàn vẹn dữ liệu cho gói tin.

Vậy nếu gói tin đi từ LAN của HN được giữ nguyên cho tới khi chuyển ra khỏi cái Router HN và đi tới nhà cung cấp đường truyền, tới đây nhà cung cấp thực hiện NAT cái gói tin và chuyển tới peer SG. Vậy thì khi Router SG, gói tin gửi đi từ A sẽ bị drop vì không còn đảm bảo tính toàn vẹn.

Còn tại sao mình lấy ví dụ 2 peer HN & SG lại là Router Cisco vì cái topic này đang đi vào vấn đề WAAS của Cisco. 

StarGhost wrote:

Còn về cái trò "Tự động lưu và phát lại gói tin của giao thức TCP bị mất trên đường truyền thay vì đợi source host gửi lại", mình cho rằng khá là mạo hiểm.
 

Bạn có thể phân tích thêm lí do mạo hiểm được không? Mình cũng đang muốn hiểu thêm về vấn đề này.

End-to-end argument là một trong những vấn đề cốt lõi của networking. Việc sử dụng đặc điểm trên đòi hỏi sự hiểu biết sâu sắc về network operation theo một cách khoa học (scientifically). Nếu không sẽ dẫn đến các hậu quả thảm hại. Mình không nghĩ là nhiều network admin hoặc engineer có khả năng này, nên việc Cisco đưa cái này vào mình cho là không phù hợp.  

Mình thì lại không đồng ý với quan điểm này. Việc Cisco đưa ra các Module tối ưu hóa dữ liệu đi từ mạng nội bộ xuyên qua nó trước khi ra bên ngoài một cách tự động và có thể cấu hình 1 cách trực quan là điều tốt.
Tuy nhiên mình vẫn muốn nghe bạn giải thích những trường hợp có thể gây ra hậu quả thảm hại.